http://www.perlmonks.org?node_id=674470

Ziff-Davis has a “publication” for just about everything. One of the ones that I do enjoy is called Baseline, and its target audience is pretty much the CIO types ... upper, i.e. executive, management. Anyhow, they had a column this month from a person who more or less overhauled the National Institute of Health (NIH) division that he was working in. It's a group that processes grant applications, to the tune of 80,000 (wow...) applications per year. “The equivalent of a billion pieces of paper.”

Anyhow, what grabbed my attention was this artfully constructed paragraph:

... I placed limits on the scope and schedule of our software releases. Until this point, my team and the NIH had boasted about their ability to release new software daily, claiming that this release rate reflected their flexibility and agility. I was convinced – and was later proved correct – that this daily rate was symptomatic of the lack of process control.
(emphases mine)

Any thoughts?

Replies are listed 'Best First'.
Re: An interesting rebuttal of "agile"
by BrowserUk (Patriarch) on Mar 16, 2008 at 18:07 UTC

    Sounds to me like an(other) example of the "Process That Would Be King"--and did. Agility is about being able to move and change course when the need arises, not dancing around on the spot waving your arms in the air like a Kung Fu movie wannabe.

    Agility in software development (prototyping and RAD as well as TDD & Agile methods), like a Kung Fu adept, is about economy of motion, not motion for its own sake. Set-in-stone, everything pre-planned methodologies can change direction, it just costs a lot. Time and (therefore) money. Being agile is about being able to recognise the need for a change of direction early, and so minimising the effects of the enevitable need for change. And again, like the Kung Fu adept, it's as much about antisipating the need for change as it is about reacting to it.

    Anything can be done badly, and allowing the process to become king is symptomiatic of that. As with all requirements, the need should precede the ability. If any organisation has reached the need to release daily, it's not just a lack of process control, but a process that is out of control.


    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.
Re: An interesting rebuttal of "agile"
by chromatic (Archbishop) on Mar 16, 2008 at 20:36 UTC

    Having so much confidence in the testing and reliability and polish of your software that you can make a release from the trunk of your SCM every day is a problem?

    If you have to release every day to fix bugs in the previous day's release, there's a problem... but the ability to release working software every day is not the root cause there.

      a release from the trunk of your SCM every day is a problem?

      My thoughts exactly, nightly builds is a known, respected, and in some cases even recommended process. Supplying the testers with a daily build is sometimes the best method of making sure the software actually works and that features are implemented correctly, bugs are actually fixed and nothing is broken in the process.

      I find Agile, as well as any other development methodology, to be like the usual adage about Best Practices, that is, use the parts that fits, discard the parts that don't, and, above all, remember that it is a suggestion rather than a rule, and means rather than a goal.

      It's a simple criteria one can apply to every Holy War, and the confusion of goal and means is what causes those Holy Wars.

      Software speaks in tongues of man.
      Stop saying 'script'. Stop saying 'line-noise'.
      We have nothing to lose but our metaphors.

Re: An interesting rebuttal of "agile"
by perrin (Chancellor) on Mar 16, 2008 at 19:44 UTC
    It doesn't sound like they were using an agile software process. Rather it sounds like they had no process at all. "Agile" does not mean no process.
      Amen, to that comment. Most objectors to agile have either never done agile, or have done it incorrectly (which, really, means that they've never done agile). Agile has very strong process controls. They're a good thing. Every big issue that has come up in my tenure as tech lead here at oversee has been a consequence of people deciding that for this issue, they could circumvent the process controls.

      Donald Hosek, Tech Lead at oversee.net
      L.A. perl people, we're hiring.
Re: An interesting rebuttal of "agile"
by Mutant (Priest) on Mar 16, 2008 at 23:30 UTC

    Most (all?) Agile methodologies are about striking a balance between allowing change, and managing the effect of those changes. As chromatic said, if you can make daily releases, it's not really a problem in and of itself. If you *have* to, because of bugs, or more to the point, business people changing their minds then it's a problem. (Believe it or not, I have seen business people try to distort the defintion of Agile to allow them to make changes in direction at least daily).

    Scrum, for example, strongly discourages the product owner from interfering with the iteration while it's in progress (they can terminiate the sprint if they really have to, but this is an action of last resort). So there's really no need for the team to release anything until the end of the iteration, which is usally at least 2 weeks long.

Re: An interesting rebuttal of "agile"
by hossman (Prior) on Mar 17, 2008 at 05:45 UTC

    A quote without context (or at the very least a complete citation) is hard to comment on. For those that want the full context...

    Turning A Mountain Into a Molehill - Baselinemag.com - 2008-02-21

      Thanks for providing the link. The context is well worth a read. This snippet had me nodding vigorously as I read it (my emphasis):

      The key to building processes the staff would endorse was to empower them to define what was important. The first procedure they drafted was how to raise an issue with any process and get it changed. The staff then followed a structured software lifecycle without over-engineering the process. The result was early acceptance and adoption of new development processes across the entire program.

      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      "Science is about questioning the status quo. Questioning authority".
      In the absence of evidence, opinion is indistinguishable from prejudice.
Re: An interesting rebuttal of "agile"
by kyle (Abbot) on Mar 16, 2008 at 19:27 UTC

    Your excerpt is light on details (as I might expect from a CIO targeted publication), so it's hard to have what I'd consider an informed opinion about this particular case. The first question I'd have to ask is, how good were their releases? If the people writing the checks were always satisfied with the results, then maybe no more "process control" was necessary. Without knowing a lot more about what was going on, I can't consider this a "rebuttal."

Re: An interesting rebuttal of "agile"
by talexb (Chancellor) on Mar 17, 2008 at 14:33 UTC
      ... I placed limits on the scope and schedule of our software releases. Until this point, my team and the NIH had boasted about their ability to release new software daily, claiming that this release rate reflected their flexibility and agility. I was convinced – and was later proved correct – that this daily rate was symptomatic of the lack of process control.

    To my mind, software goes from a development build, to a milestone build and finally to a release build.

    Each of those stages needs more rigorous QA than the previous level. I can imagine a team that would produce a development build every day. I can't imagine a milestone build every day, and a full release, every day, is ridiculous.

    For me, agile development means that you can get a framework of the application up in a few days or weeks, and that bugs can be fixed and new features can be added fairly easily. It doesn't mean daily releases.

    The only exception to this that I can imagine is if you have some kind of rolling development going on, where teams leapfrog each other, and the releases are from alternating teams. I'm not sure that's practical in the field of software development.

    This sounds like some CIO's 'idea' of what agile is -- someone who hasn't done actual development in 5-10 years, or maybe has never done software development, but 'knows' what the right approach is.

    Alex / talexb / Toronto

    "Groklaw is the open-source mentality applied to legal research" ~ Linus Torvalds

      To my mind, software goes from a development build, to a milestone build and finally to a release build.

      ...

      Each of those stages needs more rigorous QA than the previous level.

      Why?

      I prefer to move QA into the development process itself (from the design stage through implementation and to exploratory testing) in order to avoid all of the falderol around different types of builds.

        If you have the resources to constantly do user acceptance testing, all the power to you. But there are others who have to live with restrictions such as limits on available resources, yet still have to provide a process that enables them to put software releases into production.

          I prefer to move QA into the development process itself (from the design stage through implementation and to exploratory testing) in order to avoid all of the falderol around different types of builds.

        If you have the resources to do a full, soup to nuts QA run through at every step of the development process, then, in my opinion, you're either overstaffed or some people need reassignment.

        In my opinion, you need to do a development build when you've completed a significant piece of code and need to 'draw the line' somewhere; that's at the discretion of the development team. About the only QA that happens on that build is something like a) check that all the files are there; b) check that all the tests pass; c) check that it installs and runs through a few basic user acceptance tests and is usable for further development.

        A milestone build is the next level up, and requires an actual collection of features and bug fixes that may end up being a release. That's probably triggered by the project manager. All of the development testing is performed, as well as more rigorous testing of the new features and bug fixes by an internal QA person.

        A release build is a really, really clean milestone build that's been tested even more throughly. Code reviews have been done on the changes, and perhaps an outside QA team has also tried it out and liked it. This is blessed by the director of development. A release build is one that's finally released to the client.

        Alex / talexb / Toronto

        "Groklaw is the open-source mentality applied to legal research" ~ Linus Torvalds

Re: An interesting rebuttal of "agile"
by DBAugie (Beadle) on Mar 17, 2008 at 15:26 UTC
    Like everything else, there has to be a "point of balance". In this case, someone (the author of the quotation) acts as arbiter between what the end users want and what the "system" can or should provide. The ability to release new software daily does indeed reflect flexibility and agility. The question is how much flexibility and/or agility should be exercised?

    Too much of these qualities expend resources that can never be reclaimed and will kill the organization. Insufficient flexibility/agility will kill the system, because: the users simply won't use it; or the organization will die because it could not adapt to the real functional needs it was designed to satisfy.
Re: An interesting rebuttal of "agile"
by Errto (Vicar) on Mar 17, 2008 at 19:43 UTC

    I didn't read the full article, but certain points strike me off the bat. One is that more process control is not always better; it's important to find the right balance. More specifically, it's important for all stakeholders (management, developers, QA, support, and the clients, be they internal or external) to understand and be comfortable with the process (and if possible, participate in its design) in order to avoid needless bureaucracy.

    Where I work we have production releases every two weeks. Our process is pretty lean, but we follow it rigorously. Others might complain that it's not rigorous enough, but truthfully I think a lot teams I've encountered or read about have erected rigid processes to make up for the fact that they can't work in this "agile", rapid-development environment. Why not? Hard to say; lack of motivation, lack of imagination especially on the part of the team leaders, who knows.

    Not, mind you, that I'm claiming rapid development is inherently better for all applications. If I were developing embedded systems, real-time systems, safety-critical stuff or anything under a strict regulatory regime, things might be different.

        The second link didn't work, chromatic, but the paper is available in the articles directory with the first paper. Well worth sleuthing out, too, thank you very much! Our teams here at D3ll do heavy embedded Linux work, and we constantly have evolving hardware as a constraint, usually with completely different schedules.

        For example, right now I'm helping a junior engineer explain to the project core team that there's a hardware defect blocking our progress. No matter how hard you try, software can not force a pin high when there's a leakage through a bias diode that drags it below 2 vdc.

        I think my big issue with Agile is integrating Agile teams with other players in our product development game. We'll be working those issues here, because the benefits of Agile are obvious. Our company as a whole releases a phenomenal number of products, and they go out the door mostly working right. Our challenge is that we need to do even more, with less overhead, because our markets are developing and technology is changing rapidly and we're under beancounter pressure to reduce operating expenses. Agile and XP have lots of good ideas we can use, but we still have to think through (for one example) how to integrate incremental software / firmware releases with publishing Users' Guides in multiple languages. Minor little details like that need to be worked out satisfactorily, and there are a lot of them.

        Don Wilde
        "There's more than one level to any answer."
Re: An interesting rebuttal of "agile"
by ack (Deacon) on Mar 22, 2008 at 05:45 UTC

    I am reminded of a quote from Peter F. Druker, a renowned management consultant who was, several years back, reputed to have said on one of those news shows (Sunday morning's Meet-the-Press or similar):

    Never confuse motion with progress.

    As a senior (maybe that should be senile? ;-) ) Systems Engineers, I keep a little notebook of the various Axioms of Systems Engineering that I have heard or read over my 30 years in the business. These guide much of my everyday thinking about all aspects of systems engineering. The above quote from Peter Drucker is one of those Axioms.

    I was, not too long ago, asked to be the lead of an independent review team of 'greybeards' for a floundering satellite flight software effort. The flight software was woefully behind and had reached a point where it was the 'long pole in the tend' holding up the satellite launch (at a cost of about $75,000 pre day for the delay).

    The project had an independent test & evaluation team (which has proven, over the years in my business, to be a most useful strategy).

    That test & eval team, briefing the progress and their assessment of the effort stated with great pride that were finding and getting fixed...on average...about 20 to 50 bugs per day. And they had proudly sustained that rate for almost 3 months...and that the software development team could turn most of the 'fixes' on average in 2 days and, in many instances, were releasing new versions within a day.

    My reaction was one of horror...but all of the senior managers were nodding with clearly impressed feelings, that this was wondeful! After all, that clearly would get the problems cleared up in no time.

    My horror was the realization of how bad the underlying code was, how undiciplined and chaotic the development process had become, and how painfully incompetent it made the software development team look.

    Several other fine and wondeful monks have made great observations about the reported situation of the OP. I concur with virtually all of them. I am especially sensitive to and agree with the comments that emphasize the sense that such a change rate seems to be symptomatic of an undeciplined process, of the implication that such a high rate of turnarounds might be indications of seriously flawed underlying software.

    I really like this thread and everyone's comments.

    ack Albuquerque, NM