Agile (With a Capital-A)
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:
- 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. - 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 - 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
Someone wrote that one of the biggest downfalls of the Agile methodology is its name (I’d cite it if I could find it). “Agile” is a word that people know. It’s one that has meaning outside its software context, and aspects of that pre-existing definition are erroneously applied to the software-specific term. Upper management hears “agile” and expects a process that is highly adaptive and produces software more rapidly. As we know, only half of that is true, and everyone has to abide by the rules for that first half to succeed.
I have yet to see any good suggestions or case studies for incorporating a release process into an Agile team. The build portion is addressed significantly (but not entirely) by having a respected CI system in place, but no one seems to want to tackle the problem of actually shipping bits when “shipping bits” is anything much more arduous than a website update. The process is good in highlighting how much work there is to do and elevating that understanding throughout the organization, but that in itself doesn’t actually incorporate that person or function into the Agile team.
You didn’t mention the Scrum Master! The one whose purported role is to actually ensure the process is used as intended.
I bring this up because, in my experience, the role of the Scrum Master has been directly tied to your second issue and the breakdown of the wall of protection around the development team during a sprint. All too often, I see the Scrum Master viewing her job as coordinating the process, as opposed to what she should really be doing, which is enforcing the process.
If it’s so obvious to me as an engineer that a framework for helping you decide what to do when doesn’t actually help you get the what done faster, I wonder why that is so totally not obvious to management and product ownership (in my experience). I’ve seen agile tools/processes do their job exactly in terms of providing extraordinary feedback and insight into the product development process, but I’ve seen that feedback often completely ignored when it’s not convenient feedback for management to see.
At the end of the day, if you expect X features on Y date, and your expectations are completely out of line with your resourcing, there isn’t a process in the world that’s going to get you there. Too many organizations are trying to pretend that Agile is going to magically solve that problem for them.
I suppose this is true not only of software development, but of all systems. They, and the success story they’re based on are a long list of specifics, not an a la carte menu.
@Ali: That’s an interesting point about the release function. Even in my discussions with Kenny, we mostly focused our attention on build-related projects and tasks (development of makefiles, specific integrations of features in that sprint that needed build support, etc.). We didn’t touch on release-specific tasks, even though Agile’s goal is “You could ship whatever you produce at the end of the sprint.”
I’ll have to think about this some more; Rubin directed me to the Kanban-agile technique for dealing with interrupt-driven tasks. I need to research it more to see how it would apply. But even that doesn’t speak directly to release-related tasks.
Hrm… yes… E_MORE_THOUGHT_NECESSARY.
@slloyd:
I think you hit the nail on the head, and I think the problem is either a) the Scrum Master is an engineering manager, so there isn’t that clear of a separation to provide enough of a “check and balance” or b) the Scrum Master isn’t empowered to effectively enforce Agile process.
One of the things I really did like about Rubin’s training was that it seemed to me that he’s dealt with these specific issues within organizations before, and while we didn’t touch directly on these specific issues, he hinted pretty heavily that Agile is not a magic bullet to get more work to magically be produced, nor was it particularly effective if people weren’t committed to playing by the rules. (I think at one point he actually did try to point out that if you game the costing system and sprint-planning exercises, Agile-as-a-methodology is unlikely to produce different results from other methods.)
@Ron:
Indeed. I think Agile, though, is particularly misunderstood in this area because it often does get lumped in with XP and some of the “newer” software development methodologies, and many of them said “Take whichever parts work for you!” and “People over process!” and all of these other mantras that made people feel good in various ways, but when you actually tried to apply them in their gutted-form, it was a mishmash of… nothingness.
I’ve seen people start to make a distinction between “agile” and “Agile” (great article on just that here: http://blog.rodger-brown.com/2011/06/what-agile-means-to-me.html ) and I think this is a direct result of the realization that you can’t just do whatever you want, and call it “Agile.”
The refreshing part of Rubin’s training was: I’d never heard that. And he was very serious, and articulated extremely well about why you can tweak various parts of Agile to fit your environment, but “Agile” is not “pick and choose from a list of things that you think are easy to do, and start reapin’ benefits!” and I applaud him for both making that point and standing by it.
Hi there,I read your blog named “Agile (With a Capital-A) | The Sober Build Engineer” like every week.Your writing style is witty, keep it up! And you can look our website about تحميل مهرجانات.
I see you don’t monetize your website, don’t waste your traffic,
you can earn extra bucks every month because you’ve got hi quality content.
If you want to know how to make extra money, search for:
Boorfe’s tips best adsense alternative
Интернет магазин велосипедов – Запорожье цены, отзывы http://velooptom.com.ua/ – купить велопрокат Запорожье, доставка в: Симферополь