A client at a large company with large development teams and a long history of waterfall development made a comment: “The only people who are talking about doing this project in Agile are developers who think it will allow them to avoid responsibility.” My client may have been right (that people were saying that) but the developers who were saying it were wrong. Agile increases responsibility – it doesn’t absolve it.
Taking Ownership
When the original agile proponents were creating agile – by taking the best practices they had seen from multiple companies and teams, and combining them into a methodology – they were taking the exact opposite approach. Many development teams were (and still are) faced with the challenge of wanting to create successful software, but not having the opportunity to do it.
When you’re asked (or required) to do the wrong things, you’re fighting an uphill battle to be able to do the right things. And creating software product success requires you to both do the right things, and do them right. Agile methodologies have been developed specifically to help development teams to do the right things, and to do them right. But the methodologies work because the development teams assume more responsibility, not less.
- Agile teams take ownership of testing and quality – it is not a “throw it over the wall to QA” methodology.
- Agile teams take ownership of identifying the most important requirements and prioritizing them.
A waterfall development team, in contrast, is avoiding responsibility. It may be that the team does not consciously realize that they are doing it, or even intend to do it. Intelligent people can agree to disagree about the reasons that an organization does or does not pursue agile – that’s another debate. A team may not be able to handle the additional responsibility. An organization may be unwilling to create an environment that makes this ownership possible.
Making Agile Work
So, what does it take to make it work? Here are links to two great series by Kelly Waters.
- 10 Key Principles of Agile Development (includes a presentation as well as 10 articles)
- How To Implement Scrum in 10 Easy Steps
And a series we wrote, inspired by an article by Levant Gurses in Dr. Dobb’s Journal.
If you work through these 30 articles, you will have a much better understanding of what it means to “be agile” – as will your developers.
Oops. This was supposed to go out on Monday. Must have zigged when I should have zagged. Scott
I would contrast it a little differently. I would say that the proponents of waterfall vs. Agile emphasize accountability in different ways. I would say the Agile proponents emphasize accountability by emphasizing team accountability more than individual accountability, and you seem to support that in your 2 bullets where you say, “Agile teams take ownership…” Waterfall proponents emphasize individual accountability more, and they are looking for individuals to take ownership. I’m not suggesting it’s one or the other; it’s where the emphasis lies.
Hey Bill, great to hear from you on this one. Happy new year!
Any successful team & process, agile or waterfall, will be staffed with individuals who take personal ownership. You and I have both run waterfall projects that worked (and some that didn’t, at least for me). I would agree that individual accountability is a key component in the success of those projects. The same is true with agile projects – if individual developers are not owners, they won’t do “magically better” with this different methodology.
The distinction ends up being that using an agile methodology adds some accountability at the dev-team level. There are interesting organizational challenges in either case. A waterfall project will fail if there is no one who takes ownership of the requirements. An agile process will fail if the requirement “owners” don’t share responsibility and collaborate with the developers. Some orgs are more comfortable (and more capable) in one model than the other.
“Agile increases responsibility – it doesn’t absolve it”. I see statements like this as very problematic in relation to having others adopt agile. The statement is not sensitive to context, acts as if responsibility is a given when it comes to agile development. It is NOT. It is constant education to have product owner know her responsibility (especially the part about requiring each sprint to deliver working code). It is also constant education to have the team know its responsibility to deliver working code (often developers might try to focus on finalizing “lumps” such as components, instead of walking sceletons, before moving ahead. This is NOT a trivial task, and there will be a great possibility of reaching the state feared in the point “The only people who are talking about doing this project in Agile are developers who think it will allow them to avoid responsibility”, if not this issue is taken as a management issue.