Agile (With a Capital-A)

02/21/2012

Late last year, I had the opportunity to attend Agile/Scrum training led by one of the experts in the field, Kenny Rubin.

Like many developers and software shops, I’ve done “agile [lowercase 'a'] software development” in the past, but had never had a rigorous explanation of the details of Agile, so the day-long training offering a proper treatment of the topic was both long overdue for me and welcomed.

Rubin’s training starts with a walk through of the common problems we’ve all faced as developers. As he catalogs these problems, the group begins to make the case to themselves that waterfall and other classic methods no longer serve the creation of software product very well1. This helps to frame the entire day, as Rubin returns to the conclusion the group brought itself to whenever discussions arise about whether Agile will really work2

It turns out a day is only enough to cover the highlights of Agile, so in addition to the treatment of why, Rubin’s training focused on the who—the makeup of the scrum team—and the what—the sprint process—with multiple minor forays into the various hows, with a healthy dose of gotchas.

Having had a few weeks now to absorb the material, as well as look back on various ways I’ve practiced it myself, the day of training raised some interesting issues for me:

  1. As a release engineer, how do you effectively integrate build/release engineering and processes into the Agile framework? This may seem like a stupid question, but I have yet to see it entirely effectively integrated into an agile-shop, a fact Rubin was nice enough to discuss with a colleague and myself over lunch.

    Rubin suggested that release engineers be made part of the scrum team, so they’re integrated into the Agile process. This is an obvious solution, but it presents an issue for larger teams: if you have 8-10 scrum teams, then assigning a release engineer to each team’s daily scrum processes is likely to mean your release engineer will spend large parts of his days running between scrum meetings. It also doesn’t leave much resourcing for handling the interrupt-driven nature of release engineering. Rubin also describes one aspect of the scrum team being its self-organizing nature; most developers won’t normally involve release engineers3

    Having said that, I don’t mean to imply that Rubin is incorrect in his suggestion, merely that given the levels at which I’ve seen most release engineering teams staffed, it would be difficult to support that model.

    “Hire more release engineers” may be implicit in his suggestion, a notion I will seldom argue with.
  2. In all the ways I’ve seen agile practiced, there is one aspect that Rubin discussed at length, which I’ve never really see play out the way he says it’s supposed to: as a balance to engineering committing to finishing a set of work in a particular sprint, the product owner commits to not introducing change in a sprint, and does not question or “game” the costing of tasks or the filling of the sprint work-item list. It would be great it worked like this (and I’m sure that Agile works much better when all sides agree to this), but I can conjure up example after example where requirements where changed inside the sprint, and engineers were either pushed to revise the estimate of a backlog item5 or add more to the sprint than they felt comfortable6.

    Without these checks and balances, it’s obviously difficult to realize the full benefits of capital-a Agile, but 50+ years of software development has positioned product owners to not expect any checks, balances, or limitations placed upon their requests7
  3. With Agile, it’s easy to fall into the trap of bastardizing Agile to a point where it’s no longer a viable software development methodology, to say nothing of “Agile”. An aspect of the extreme programming/agile “fad” that became very popular years ago was something I called “cafeteria software development process”: take whatever tenets of Agile work for you, and leave the rest.

    The problem with this trap is we tend to take the aspects that work for certain parts of the organization—costing, breaking work down into sprints, etc.—but ignore the parts that are harder to sell and implement (no change after sprint starts, for instance).

    Probably the most important thing I learned from Rubin is that Agile actually means something. It’s a set of values about software development that are embodied in a set of activities and processes that seeks to make software development more successful. It has aspects that are flexible (length of sprints, for instance), but other aspects aren’t fungible (the check and balance between engineering and product owner). When you remove those aspects, what you’re doing isn’t Agile anymore and, in fact, may not even be agile. All too many software shops have a product back log, do sprints, and maybe even use an Agile tracking tool. But not all parts of the organization have committed to Agile, so they really aren’t an Agile shop.

Having seen a lot of software shops that “do agile” (and being a part of a few myself), Rubin’s training was not only clear and eminently understandable, but refreshing and has provided a lot of food for thought.

He cut through a lot of the hype about what Agile is, what it is not, and what organizations, from individuals to teams, need to do to structure their interactions and work to create an Agile environment, and succeed using it.

My only complaint about the training was that it was only a day long.

_______________
1 If they ever did
2 As a trainer, I’m willing to bet it also has the great side effect of giving Rubin insight into what notions line-engineers have about Agile, and what topics he may need to address more directly. It’s a great training technique.
3 My professional experience has been this failure to do so is generally due to omission rather than, say, maliciousness4
4 Though, I have experienced the latter from time to time, unfortunately
5 “You don’t reallythink it’s going to take that long, do you?,” with the associated performance review implication such a question implies
6 “You can do more than that in two weeks. I know it!”
7 A fact a software engineering Robert Glass also explores