back to article So you're 'agile', huh? I do not think it means what you think it means

What if I were to tell you that we knew all the best practices for software development? That they've been proven by actual industry use over the past 25 years? But that, oddly, these practices are not widely done? Well, if you read these pages, you'd probably say: "Sound about right." Agile is much spoken of, but not as …


  1. Zog_but_not_the_first Silver badge

    Look to history...

    At various points in history we "gave" the bean counters the keys to the car, and the keys to just about everything else. In the current cycle this occurred about 35 years ago. Until this imbalance is, er, rebalanced, such counter-productive nonsense will continue.

  2. Valeyard



    Even when development teams have nailed agile, pumping out builds weekly gleefully (or, monthly for the languid), as Oti points out above, they often are not able to actually deploy their code to production.

    yep! everything's agile after management pushed for it. After great effort we now pump out regular code... management themselves however weren't prepared for it to actually work* and the code ships with the same schedule as when it was waterfall

    *3 years and counting

    1. Anonymous Coward
      Anonymous Coward

      Re: wagile

      There can be good reasons for this

      Ac obv..

      Some customers of ours are happy to always have the "latest & greatest" new release

      Others (lets call them type C, for cautious) have a rigorous deploy to a test environment, try that for many weeks / months to check OK, then deploy it to live

      The Type C customers explicitly do not want to receive every release (as releases can come more frequently than their slow test acceptance process can cope with - no point them having weekly builds when their testing takes months).

      The Type C customers usually only want to try a new release if It has new / improved functionality they specifically requested or it deals with a critical security bug, as the test process is a PITA and cost for them

      Thus we have customers on a wide variety of releases, depending on their internal acceptance processes, so there can be cases when infrequent releases make sense for a particular subset of customers.

      1. EarthDog

        Re: wagile

        I find type C is often with true mission critical needs, as opposed to "mission critical" needs, and so want reaffirmation of the software quality. If (collective ) you haven't done so show them the stage by stage testing from unit test levels to acceptance level. That might help.

      2. Anonymous Coward
        Anonymous Coward

        Re: Type C customers

        Oh yes.

        And further... when they come across a bug 4 months down the line, they want *only* that fix on top of the code line they are currently on. Not all the stuff that has been added since, in 4 different releases.

        1. Missing Semicolon Silver badge

          Re: Type C customers

          Well, yeah! I want *this* bug fixed. I don't want all the process changes, missing functionality and new bugs in your latest cruft!

          I bought the product you sold me. Now make it work properly then go away.

      3. Andy 73

        Re: wagile

        "their slow test acceptance process"

        The argument is to move their test acceptance process into your continuous deployment process. Easier said than done, but what you're describing is the usual impedance mismatch that comes from a product being used in a situation that itself is not agile.

        Sometimes that's a technical problem (how do you test against a client's third party tools), but just as much is a cultural problem (they're just not ready to re-build their test processes). Of course, without solving those problems, 50% of the benefit of agile is immediately lost - which is a cost to them, albeit a hidden one.

        1. yoganmahew

          Re: wagile

          @Andy 73

          So not only are developers resistant to change, but customers are too? Well, if they don't want to adopt our agile framework, I think we should tell them to take their business elsewhere.

          1. Andy 73

            Re: wagile

            @yoganmahew I'll take that as tongue in cheek :)

            It is worth questioning some of the value of agile if your client wants one thoroughly tested release per year and the nature of the testing is not open to change. That doesn't mean you can't adopt it internally, but some of the reassurance of continuously tested increments are lost. That means ultimately your product still suffers from some of the biggest issues with waterfall, regardless of how agile you are.

            That impedance mismatch can lead to developers and project managers coming away from a project thinking agile is a failure because it failed to deliver in hostile conditions. I've worked with people who claimed to be working in a 'post agile' way, because they'd tried and failed to get agile to work for them. It took them over two years to deliver a six month product change, but they'd never under any circumstances 'go back to agile'.

            1. JohnFen Silver badge

              Re: wagile

              "That doesn't mean you can't adopt it internally, but some of the reassurance of continuously tested increments are lost."

              How so? A customer wanting fewer releases doesn't mean you can't develop in continuously tested increments. Why does the release schedule impact that?

    2. TJ930

      Re: wagile

      In my experience, about 5% of Agile-Adoption problems are with Developers (most of whom just want to type code) and about 95% are with Management...

      Management often likes to think the rules, practices and beliefs somehow don't apply to them, just the serfs beneath... Management sets the culture.

      1. EarthDog

        Re: wagile

        like the SAFe garbage see this diagram and see what you think it says.

        1. TJ930

          Re: SAFe is uglyyyyyyy

          Mate, I appreciate that everybody's first response to SAFe might, "WTF?!" But once you understand it, things make sense. A bit like x8086 Assembler, or .NET Intermediate Language, or Swedish, or whatever...

          If you understand how to do Scrum, then you understand how to Scale Scrum (i.e. multiple Teams working from the same Product Backlog), and then you start to realize that the rest of the organization needs to get in step with this Lean-Agile think, Jemba (walk those 'value streams', etc).. It all checks out.

          Or you could just rejoice in your ignorance and hope that this Agile Alligator eats you and your company last?...

    3. JohnFen Silver badge

      Re: wagile

      " the code ships with the same schedule as when it was waterfall"

      That's a good thing. This "continuous release" thing that too many software shops are into has caused me nothing but pain and trouble. I long for the day when I didn't have to engage in the hassle of upgrades more often than once or twice a year.

  3. Locky Silver badge


    Project Management shister-speak for "Make it up as you go along"

    1. Phil O'Sophical Silver badge

      Re: Agile

      Indeed, I've seen maybe 2 or 3 projects that really do Agile correctly. They don't actually seem to turn out code that's any better, or any cheaper to do, than waterfall. Much of what I see described as "Agile" translates to "Don't do specifications or design docs, just hack up a prototype and let the end users do the testing. Look at all the money we can save", with predictable results.

      1. zebthecat

        Re: Agile

        That is not Agile at all, just laziness

        1. JohnFen Silver badge

          Re: Agile

          It seems that every time someone mentions their negative experiences with Agile (I have experienced it five times on five different projects with three different companies, and my experience has been uniformly negative), the response is "they're doing Agile wrong".

          That may or may not be true, but if it is, it points to a critical flaw with Agile: it's apparently so complex or difficult to understand as to be essentially impossible to "do right". Even the most ideal system in the world is effectively worthless if it's too hard to implement "properly".

          1. Anonymous Coward
            Anonymous Coward

            Re: Agile

            'it points to a critical flaw with Agile: it's apparently so complex or difficult to understand as to be essentially impossible to "do right"'

            Like homeopathy or dowsing, or seeing the emperor's new clothes?

            1. TJ930

              Re: Agile

              Nope. Not at all.

              I can send you a simple 'Scrum checklist' from Henrik Kniberg, or a James Shore 'XP Radar Chart checklist', if you'd like.

              Should be more than apposite for somebody at your level.


            2. TJ930

              Re: Agile

              And the alternative is?,,,,

              Bearing in mind that, like an ON-OFF switch, an alternative has only one other state. (Poor English speakers tend to confuse "options" with "alternatives".)

          2. pcgeorge45

            Re: Agile

            Too hard or complex, no. It just has some assumptions or prerequisites that aren't often seen in the wild, so ends up being a buzz word meaning 'good' or 'modern'. E.g. A 5-10 person development team with full control of the product requirements, development, testing, and releases. No external certification or qualification testing. Works well for small web-apps, but doesn't scale well and runs into issues with customer, saftey, or health critical systems. There are attempts to make it work in such things as SAFe, but in practice the focus on a program office or portfolio level backlog development process.

            DevOps runs into similar issues since it depends upon real test or behavior driven development and automated testing. Deploying garbage fast is easy.

      2. Zippy's Sausage Factory

        Re: Agile

        Indeed, I've seen maybe 2 or 3 projects that really do Agile correctly.

        I came here to say mainly that, actually. Most of the development methodologies out there actually work if you follow them - some better than others, and most only in particular kinds of projects.

        I've seen so many people who say "we use x metholodology" and then they don't. They say "ah well yes we improved it to match our corporate culture". No, no you didn't. You just decided to cherry pick the bits you like instead of using it. Kind of a bit like putting a racing car engine into a Lada. It'll work, but the results you get will be, shall we say, sub-optimal?

        1. John Lilburne Silver badge

          Re: Agile

          See none of the Agile twonks can actually say what is optimal. It is all hand waving and bluster. They didn't even know what issues we had with our old system, waxed on about no late nights or weekend working, when the 200 devies haven't done late nights or weekend working for over 20 years.

          All the issues that we have Agile doesn't solve, it just gives us a bunch of extra shite. So instead of having 1 person work on something for 12 weeks we now have 4 people working on the same thing for 6 weeks. each of them finding the same issues and coding up a separate solution, each of them making changes which are incompatible with some other changes, all running about fixing up the fallout.

          Then we have multiple teams finding an issue and solving it for their specific use case. Code gets copied from one place modified and siloed into another place, and all because they are running about with some false deadline being the end of sprint and the subsequent review.

          And according to the Agile trainers we are meant to be fecking awesome, TWATS.

          1. TJ930

            Re: Agile

            How many miles on that odometer, Johnny Boy? I don't want to say that "you aren't doing it properly", but "you sure as hell ain't doing it right." And that is your problem.

            XP bods would have an apoplectic fit if you talked about code duplication as if it were passe or 'business as usual.'

            You seem to be complaining about the symptoms without first understanding the underlying problems.

            1. John Lilburne Silver badge

              Re: Agile

              I have 30+ developers working on an 25yo legacy app, split into 4 scrum teams, then there another 15-20 teams reusing part of our apps codebase. Now I know for certain that chunks of the code, written over the last 25 years, wasn't written to be used outside of the app. So if some outside team is reusing they will have had to refactor it, removing some of the dependencies on the app. That refactored code aint going back into the app's repository, they've cloned and modified it for their own purposes.

              If I go and look at what other teams are putting back I see methods with comments that don't reflect what the code does, I see code that is redundant in its new form, that was necessary in its old form. With a bunch of teams self-organising to sling code into the their particular silo of the app in order to meet a sprint deadline the process of cargo cult programming takes on a life of its own.

              I wrote some code a year ago and a couple of weeks later found a bug in it. Meanwhile I'd attended a sprint review of some other team that had reused the code. The demo should have triggered the bug, but it didn't they'd copied the code found the bug and fixed it in their specific app.

              C'est la vie

              1. TJ930

                25yo legacy app

                Hmmm.. Michael Feathers’ famous definition of Legacy Code: “Code without tests.”

                Seriously, I mean to help.

                So are you Scaling with ‘Scrum of Scrums’? Or something a little more structured like Nexus, LeSS or SAFe, etc.? (Or is it rather more like ‘The Wild West’?)

                But why are the Teams under a lot of time pressure? They are meant to be able to maintain this pace indefinitely – are they very poor at estimation? Are they doing sufficient Backlog Refinement? Which technique do they use to estimate – Relative Sizing or Capacity Planning (i.e. Time)? Or is somebody else from outside just “pushing” the work onto them?

                Why not take a look at Henrik Kniberg’s checklist and – be honest – count how many your aren’t ticking?

                Scrum should be bringing Transparency through its Principles, Practises, Events and Artefacts:

                Potentially Shippable Increment = Fully merged, fully tested.

                Continuous Integration = Merge to trunk (i.e. no branching).

                Sustainable Pace.

                Definition of Done. (Basic one that all the Teams agree to, with more exacting and tighter definitions for the better Teams, once they have started the Continuous Improvement process).

                Continuous Improvement of processes, tools and techniques.

                Who is the Teams' Scrum Master? The phrase, “Where Scrum isn’t fully adopted and fully understood,” is used as a caveat to give Scrum Master’s a bit of elbow room to correct errant behavior… Maybe time to have a word with the SM?

                25 years ago = circa 1992 code, and so I’m guessing primarily C/C++? (If not Pascal or COBOL or something?)

                Now I’ve used .NET static-analysis tools before to help identify redundant, legacy code. (But I'm sure there’s C++ stuff out there - have you checked into this?)

                Does sounds like you’re already aware of your problem – a lack of Technical Excellence and Discipline (probably brought about by a lack of Transparency) – what can you do to hold them to account? (Are they Pairing?) Maybe you could work on their Teams for a Sprint and check that each Story has a Code Review Task? Or how about Martin Fowler’s “StranglerVine”? (Pay down that Technical Debt?)

      3. EarthDog

        Re: Agile

        You forgot "QA, We don't need no stinkin' QA. We have Agile."

      4. bombastic bob Silver badge

        Re: Agile

        "I've seen maybe 2 or 3 projects that really do Agile correctly. They don't actually seem to turn out code that's any better, or any cheaper to do, than waterfall"

        that would be my prediction just from reading ABOUT 'Agile', and not actually participating in it.

        Although, at a used-to-company, I developed a prototype in 3 weeks for a potential product, doing it by myself [it involved a linux netfilter kernel module]. I spent another week (or so) tweeking it over a short period of time, because my proof of concept code was being used to DEMONSTRATE IT FOR POTENTIAL CUSTOMERS. Meawhile, 3 people (one manager, one senior guy, one junior guy) proceeded to 'start from scratch' using Agile-style principles for managing the project. A YEAR LATER [they were still demo-ing with my prototype] I'm brought back in to "help finish up" in a couple of weeks of 3-way programming effort (and then the junior guy was laid off) followed by nearly a MONTH of paired-up programming effort.

        That's right, fixing the "Agile" code took LONGER than WRITING! THE! PROTOTYPE! FROM! THE! BEGINNING!!!

        At that point, I had some cash stowed away, and I saw the writing on the wall, and left [after the project was 'working", that is]. Back to business for myself [no more commuting+wageslave].

        Needless to say, I have a very *LOW* opinion of "Agile" and things like it. BUZZ-WORD of the day, market-speak and manager-incompetent-speak [manager hears a new word, MUST implement!].

        Let's just call "waterfall" something else, in case the term has been POISONED too much by Agile-fanbois, and get people to go back to determining what the specs are FIRST, like is SUPPOSED to be done. Build a prototype, work out the bugs, and then SPEC UP THE PRODUCT, like is SUPPOSED to be done, and make it work according to the spec, as is SUPPOSED to be done.

        We could call it: "Common Sense"®©™

      5. Andy 73

        Re: Agile

        I've seen agile work, and in those situations it has delivered truly remarkable results - projects delivered faster, to spec with minimal staff and a team that overcame technical and personal issues along the way.

        In those cases, the project manager has been the key. Not only have they managed the huge information flow that comes with a team running at full chat, but they have acted as the customer for continuous testing and validation (it's rare indeed that a customer actually looks at software until two weeks after they were meant to go into production with it).

        Agile isn't complex. It isn't rocket science. But people baulk at some of the implications of what it asks of a team and decide to skip the 'difficult bits', as though only doing the easy work is going to get the whole job done. As often as not, the difficult bits are the social and managerial stuff that goes around producing code, and in a project under pressure to deliver, they're the first to go.

        Paying lip service to parts that you don't see the value of means they'll never have any value - yet Agile does all it can to reduce the requirements down to *the bits that matter*. So if you've killed one of those parts, you've already broken the process.

        1. Anonymous Coward
          Anonymous Coward

          Re: Agile

          In those cases, the project manager has been the key.

          To me this is perhaps the biggest flaw with Agile, it only works when you have really good people. Good PMs to manage it, good developers who can be trusted to turn out good quality code under pressure, etc. Unsurprisingly, the people who champion Agile tend to be those sort of people.

          Realistically, though, most companies only have a few of them, and they can sometimes be prima donnas that no-one wants to work with, which also encourages them to work in a little antisocial bubble. Companies are more likely to have a large group of competent plodders who get a decent job done when well managed in a structured framework. Agile does not work for such people, but the prima donnas tend to "go Torvalds" when faced with them, instead of accepting them as necessary components of a team.

          1. TJ930

            Re: Agile

            Have you ever watched a group of 6-year-olds play Football? All chasing after the ball, all getting in each other's way?.. Have you ever watched a well-disciplined, lower-league, FA Cup 'Team' destroy a 'Group' of galactico, individualists on an 'off day'?

            In short, it's the Team ethic...

            There are various techniques for forming Agile Teams, but the very best - perhaps unsurprisingly - is to allow Self-Organizing, Cross-Functional Teams to pick themselves.

            1. Anonymous Coward
              Anonymous Coward

              Re: Agile

              allow Self-Organizing, Cross-Functional Teams to pick themselves.

              And then how do you use the remaining 90% of the developers?

              1. TJ930

                And then how do you use the remaining 90% of the developers?

                Although "compost" might be a glib reply, I'll try to give you a serious answer. Let's say we have a department with 100 Developers and the company's decision is to use the most popular 'de facto' Agile Framework, Scrum.

                The 3 Approaches are:

                1) ALL AT ONCE - i.e. Spell out to the Developers what a successful Scrum Team looks like:

                i) 3-9 Members.

                ii) Optimum of around 5 Developers. (No split-Team membership.)

                iii) Cross-Functional (i.e. all the necessary skills required to produce a working Product from a Product Backlog Item)

                iv) Self-Organizing

                Then allow the Developers to choose their friends, however they want, provided their Teams meet these acceptance criteria. (This may take several goes - i.e. iterations - and expect a lot of girlie whining for the first couple of weeks.)

                2) CULTIVATE FROM EXCELLENCE - i.e. "one volunteer is worth 10 pressed men", as the saying goes. So start small with a Team of Volunteers, then once this Team starts trouncing the White-Water-Rafting and Big-Bang Boys - which will happen (these Teams are easily x4 times quicker) - create an air of mystique for this Team based upon Great Results and well-earned bigger bonuses, etc. Then 'take clippings' and form a new Team around each of these individual winners, who've done it before and now know what it takes to succeed. Keep spreading the love.

                3) BUILD A SHINY NEW BUILDING with security on the door to keep out the riff raff / rotting vegetation. Recruitment Policy: Only competent people who know how to do Agile.

                Then start winding down the old place, giving the less skilled less and less to do, hoping that they get bored and leave of their own volition... Saving on the number of redundancies when 'push ultimately comes to shove.'

          2. Andy 73

            Re: Agile

            > To me this is perhaps the biggest flaw with Agile, it only works when you have really good people.

            I've yet to discover a methodology that protects you against dumb shmucks. Sure, the dumb can come out in different ways, but it will always come out.

            Waterfall tends to mean that you only find out somewhere around the end of the project, rather than near the beginning. Of course, with Agile, the temptation when dumb starts dribbling out is to 'bend the process' rather than fix the problem. Yes, I've joined a daily stand up which had 120 people in it. We were each restricted to three words so it wouldn't take up too much time.

        2. JohnFen Silver badge

          Re: Agile

          "As often as not, the difficult bits are the social and managerial stuff that goes around producing code"

          Which is precisely the same if you're doing waterfall. Agile isn't unique in terms of the requirement for communication. If a team can't communicate adequately doing waterfall, they can't communicate adequately doing agile. I don't think the development methodology impacts this that much.

          1. TJ930

            Re: Agile

            You're a nice guy. I can see that. But this is "scary unknown" speaking, isn't it?

            Imagine if you had much greater visibility of what you were doing; imagine if your assumptions got tested in the real world much more frequently; imagine if you could replace vague guess-work with knowledge...

            Communication in Agile is 'bolted in' - I don't want to sound like the "No True Scotsman fallacy" - but the number of people who claim to have done some form of Agile, Software Development but don't have the first clue about what they're doing... Well we've got to use binary and everybody in the room to count it on our 10 fingers!...

          2. TJ930

            If a team can't communicate adequately doing waterfall, they can't communicate doing agile.

            No, you're just showing your ignorance off again, aren't you?

            What size is the average Waterfall team?.. What size is the average Scrum, XP or Kanban Team?

            The fact there are far fewer people in Agile Teams and there is far more transparency means there is nowhere to hide. It's pretty obvious in a Daily Stand-Up when a Team Member isn't pulling their weight and needs a talking to! Or when somebody has a blocker, they can more easily ask for help.

            The fact that we are dealing with smaller chunks of work means that the shared understanding of the work in progress improves.

            Also the fact that the team wins and loses together, sets its own targets, improves its own processes, is its own boss, de-emphasises job titles, typically co-locates teams and communicates with each other face-to-face, rather than through hefty documents, phase gates and sign-offs.

            The cross-functional nature of teams also improves communication, reduces bottlenecks and reduces delay.

            Yeah, you don't know what you're talking about, do you?

        3. Robert D Bank

          Re: Agile

          I think you have nailed this really well, the PM's are absolutely CRITICAL, but on their own are not enough. You still need Devs and supporting areas right through testing to implementation that are CAPABLE and willing. Reducing things to 'bits that matter' actually takes skill to identify, not just by the PM but from the techies right through to business. And this often (usually) requires a greater understanding that these 'bits that matter' may mean fuck all to someone else whose 'bits that matter', matter more to them, and then onward to the support or operations people who may or may not see either of these being 'bits that matter'. And then the management at multiple levels, and then the business at various levels then have another view of 'what matters'. It's a case of understanding connections and being able to prioritise, and make an entire organisation dynamically move behind that. Bringing all this into line is incredibly difficult in a large 'business' of whatever form (less so much with small business). So the underlying issue is it becomes what the business wants to deliver to meet a customer requirement, which the customer may not even know they require, if it's a new thing. Will it deliver value? It may in the case where some very specific customer gripes have been identified and these can be addressed. It may not if things have moved on (as they inevitably do) and some other company has come up with something even 'better' and taken fickle customers with them.

          So thinking this through I can see the value of the Agile approach, with supporting DevOps. But, it needs to be kept in mind very strongly that this approach does NOT apply to everything an organisation does. Identifying where it does needs some real honesty and clear understanding by everyone in the delivery chain. And if that can be done you can build an Agile infrastructure and process around just that, in a properly focussed way without this nonsense of trying to make the whole organisation try and find Agile process where it might actually be dangerous and damaging and delivering nothing but a tick box for a managers bonus

    2. TJ930

      "Make it up as you go along"

      Yes, far better that we make up a piece of fiction right before we start, plan everything in microscopic detail as to the precise way things are going to occur for the next 2 years... Then just deny observable reality, blame and scapegoat the poor souls tasked with achieving the impossible, and watch as the 'final deadlines' keep flying by like miles on the odometer of a speeding car, as the Bugs in the Bug Backlog start to number in the thousands, as the customers grow more and more disgruntled, and the £ notes burn right before your eyes...

      Way better? Or maybe not?...

    3. TJ930

      Project Management shister-speak for "Make it up as you go along"

      I thought that was "Big Bang" (or "Silent But Deadly", as it's also known)?

  4. Oengus Silver badge

    Still more importantly...

    More importantly: please, let the T-bone rest for a while before cooking it.

    Please, Let the T-bone rest after cooking it.

    Beer because it is an essential accompaniment to any good steak...

    1. Anonymous Coward
      Anonymous Coward

      Re: Still more importantly...

      Actually, BOTH is needed.

      Letting the meat come up to room temperature before cooking and resting it afterwards.

      The same can be said for Software Development. Let the design sit for a while before starting development. When you come back to it you may find some glaring errors that were just not that visible beforehande. Then afterwards, and when all the testing is done go back to the spec and see if what you are about to deliver meets it.

      Most of the time you will find that what you are delivering does not meet the approved and signed off spec.

      "Don't worry," we are told.

      "We are using Agile. The Spec will get corrected later..." as it is added to the Technical Debt.

      The only problem is, that it never does get fixed (the spec or the software).

      Sad fact of life.

      In my last job, most of the 'Agile' team I was working with were away on 2-3 weeks holiday over Christmas. I was the only team member at work. I resolved most of the technical debt that we'd built up over the previous nine months. When the PM came back from holiday, I was heavily criticised for not 'doing new stuff'. Said it all really. Technical Debt seems to mean 'Do Not Fix' these days.

      Yes, I'm cynical. 40 years writing code and much of it safety critical code at that has taught me to be very cynical.

      Agile to me means always going onto the next thing and never going back.

      My current employer went all Agile and actually saw a large drop in productivity of usable code/product.

      Now they use bits of this and bits of that and you know, it all seems to work.

      1. Solmyr ibn Wali Barad

        Re: Still more importantly...

        "Let the design sit for a while before starting development"

        Indeed. As one seasoned developer told to younglings: "There's no need to rush. If a change request comes in, wait until tomorrow. There's probably going to be another request, either amending or even superseding the previous one.".

        Then he had a sip of coffee and added with a diabolical grin: "But if you stall for several days, then there's a solid chance that the whole idea will be canned and you'll get a request to revert your code back to original."

  5. HmmmYes Silver badge

    Agile fucks me off more than most stuff I have to deal at work.

    The original Agile might have some merit, at least in the early stages of development where teams are struggling to work out what and how to do a project.

    Its a fucking disaster for everything else. The term is so pointless that any piss poor products gets classified as Agile to overcome the vast number of shortcomings.

    1. LDS Silver badge

      The main issue are those who turned it into a sort of religion...

      with the Scrum Certified High Priesthood and all the related dogmas. And like religions, pragmatism is banned, and reality must fit ideology, and not viceversa. And like religions, it became a source of revenues for preachers and churchesconsultants and training companies.

      Take Scrum stubbornness a sprint must be shorter than a month. Sorry, for some complex projects where the team is not so large, and the code can't be easily broken in smaller pieces to be coded separately, it could take more, especially in the early phases of a project when you need to establish the foundations.

      You can have a great developer who can write outstanding code, but may not be the quickest on the planet (maybe exactly because they think about what they write).

      Being forced to release earlier, can lead to bad designs, and hurried code.

      And because you don't always (re)code the same stuff, there are also often unknowns to be tackled - not everybody can perform extensive research and prototypes before starting a project.

      Sure, if all you do is churning out the same websites with some customization, or essentially maintain some legacy project, it's all OK - when you work on more complex and innovative projects, being forced to abide to some strict rules just for the sake of them often just gets in the way.

      1. TJ930

        Re: The main issue are those who turned it into a sort of religion...

        To be fair, I can understand why you would proffer such an opinion... By definition, a Belief is something that can't be proven - otherwise it's just a fact!

        But, to understand your complaint, it's Lean-Agile Values and Beliefs that guide those Lean-Agile Principles, these Principles are then applied to form their own specific Practices (by the people doing the actual work - NOT top-down Management, far removed from "what's what"). So it's the Beliefs, Values and Principles that can make things seem quasi religious.

        To explain why they're needed, a Practice which works very well for one Team / Department / Company / Organization / Hospital / whatever, might not work at all - due to local reasons - when attempts are made to apply the specific practices directly elsewhere. This is why an understanding of the basic Principles is required, because the Principles CAN ALWAYS be applied.

        For example, the whole point of a "Daily Scrum" is NOT to answer 3 questions when standing up; the point is for the Team to gain a Shared Understanding of the current state, to formulate a Plan for the next 24 hours, to check things are on track, and make changes if they aren't... How you do this (the Practices you employ) is entirely up to you... So, if your processes aren't working, change them!

        Given that "working software is the only real measure of progress.." and that Empiricism is based upon Feedback loops (i.e. checking your assumptions) ; if your Sprints last longer than 4 weeks, are you increasing or decreasing the number of Feedback opportunities you will have in a given year?

        "Scrum is a framework for creating complex products in complex environments..." People always make excuses about complexity; why not try breaking the complexity down into smaller problems?

        "Oh, no.. Couldn't possible do that!..."

        Oh, yes, you can.

        1. LDS Silver badge

          "are you increasing or decreasing the number of Feedback opportunities"

          Religions use a lot of capitals. Common people avoid them because the emphasis is useless.

          That implies that "feedback" can come just at the end of a Sprint. and that need to come on something working because you have to show it to "stakeholders" outside the development team.

          Actually, reality is different and "feedback" can come on unfinished artifacts not yet working. Sure, you may have nothing to show outside code to people who can't understand code, but sometimes all you need is the feedback from people who understand code and a debugger.

          Forcing shortcuts may be just as bad when management press to have "something to show".

          I'm not against the principles of Agile - actually most people followed agile principles well before it was documented, because very few software outside bit gov/mil projects could design everything in the beginning, set it into stone requirements, and expect code monkeys implement it without changes arising, and wait for the project final deadline to check if everything works.

          What became wrong with Agile is when they exactly followed the same path - they put into stone the *P*rinciples, the *P*ractices, *E*tc. *E*tc. and invented *R*ituals to be folllowed, with *P*retentious *T*itles like *S*crum *M*aster.

          People shared understanding and planned what to do even without formal stand up meetings. Sometimes you don't make plan for the next 24h, sometimes you make plans for some days because the task is much more complex than what you can accomplish in one day. Sure, you can break a complex problem in smaller one, but not always the "smallest" one are enough small you can do everything in little time.

          And isn't one of the principles "Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done"? Giving to short targets and schedules just because a methodology says so could be the best way to achieve the opposite. When you have distributed teams, and varying skills, it's also more difficult.

          1. TJ930

            *P*rinciples, the *P*ractices, *E*tc. *E*tc

            *A*d hominem *A*ssertion *A*d hominem *A*ssertion.

            Okay, I'll "rip you a new one" on each of these points... Yes, don’t bother challenging the argument; challenge instead the style or character of the person who made the argument. Far easier ;) (Though those with even only a cursory understanding of logical fallacies might consider this tactic to be rather less effective.)

            I was explaining to you the underlying need for principles, and why they can seem a little abstract.

            Just read some of the other postings on here. In the same breath as accusing the concepts, principles, beliefs and values as being too abstract, hazy, opaque or imprecise, someone will seemingly then go on to describe the practises as too concrete, over-exacting, silly and/or unnecessary.

            No, “put the Principles into Stone”, not the Practises. Here the principle of Self-Organisation is the one that’s important – the Team should have the power to override “pointless rituals.”

            Ipso facto. I think you have rather proven my point.

          2. TJ930

            “That implies that ‘feedback’ can come just at the end of a Sprint[?]”

            No. You imputed that. Now, where possible, I personally consider basic TDD/CI to be far superior to Debugging, but each to their own....

            You’ve specifically used the word “Sprint”, rather than “Iteration”, so we’re talking Scrum – am I right?..

            So what are the 5 Scrum Events?.. Do you know?.. No?.. Read on..

            - The Sprint

            - Sprint Planning

            - Daily Scrum

            - Sprint Retrospective

            - Sprint Review

            The first is a “time-boxed” container for the other 4, and each of those is an “inspect-and-adapt” (i.e. a “Feedback”) opportunity for each of the different aspects of the development processes. (NB: Feedback is not strictly limited to these Scrum Events!)

            In my experience, whatever Sprint length the Team chooses, when Scrum Teams are very inexperienced, the Programmers (despite protestations from the QAs) typically pull in far too much work. (Usually ~150+% of what the Team can actually finish in the time-box: so a 2-week-Sprint Team will pull in 3 weeks’ worth of work; a 4-week pulls in 6 weeks’, etc.) This usually originates from “I’ve-done-MY-bit” and “quality-&-testing-are-someone-else’s-concern” thinking; the Sprint Time-Box and Sprint Review force errant, lazy programmers to ‘face the music.’

            “Hardening Sprints” and “Bug-Fix Sprints” are not part of Scrum; they are a managerial dysfunction/anti-pattern caused by not finding and fixing bugs (i.e. inspecting & adapting) early enough in the Development. This reduces the transparency of how much work actually remains, destroying Scrum’s empiricism, and with it the ability to predict the finish date with any kind of accuracy…

            I’m guessing that this sort of failure thing sounds quite familiar to you, right?

            Now, splitting Stories is a skill to be acquired with practise. Yes, Product Owners and Developers need teaching, coaching and advising to that end. But look up “Walking Skeletons”, “MVP” and “Story Mapping” to help you understand the basics… In your Sprint Reviews, you’ll want to have a ‘working Prototype’ – so stub out/fake the bits that aren’t finished yet – but proudly show the bits that are, and then let the Customer glean whether what they requested is what they actually want (i.e. a “validation error”, as it’s known) – whilst we can still easily do something about it!

            All of these Agile Methodologies are based upon transparency and feedback loops. So, yes, in summary: Feedback. Feedback. Feedback. Ad infinitum.


POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Biting the hand that feeds IT © 1998–2019