TIEKE Brief #10 on Agile

Last Tuesday, on 4th of May, I was participating the TIEKE Brief #10 “Scrum – ketterästi” as a speaker. I was closing the brief with a title “Reality Check”. There is much hype and unfounded optimism on Scrum and Agility that I felt it was appropriate to try to ground some of that. Scrum and Agile is hard. Change is hard. It’s easy to write bad software expensively; it’s very hard to try to do as good software as you only can with as little waste as possible. It is known that most Agile transitions fail to meet the expectations.

While the presentation should be appearing also on the TIEKE site, I’ll post it to my presentations page (also linked to this post). It’s in Finnish and in a very much simple format. Should I expand in text? Okay, will do quickly…

Agile isn’t a silver bullet. It doesn’t solve most of the problems typical organizations have. It will expose them. It’s up to the organizations to fix their bad habits or poor operation. Scrum is pretty quiet on “how” (purposefully, because it isn’t a methodology), so we must turn our attention to other sources. Lean Software Development gives a pretty good overview on the kind of product development Agile environments should foster. An upcoming book by Stephen Denning, labeled Radical Management, takes a more comprehensive look at how businesses can become radically better. Dan Pink made a great case in his TED talk about how rewards are actually damaging our businesses and our innovation. Etc. There’s lots to learn for us.

One reason Agile transitions go awry is that many managers perceive it as “yet another methodology” and fail to grasp at the ideological change behind Agility. THEY have to change, too. THEY have to understand that the whole organization must rethink how it works and what it values (not all in one swoop, but eventually). THEY need to get the whole organization excited and energized, and steer the whole organization to a new direction. Nothing will change, if nothing is changed.

On a more general note, I reminded that responsibility cannot be outsourced. The organization is ultimately responsible for its own business, because if shit hits the fan, no-one will bail them out (unless they are banks or the Greek government). Contracts may be used to also hurt the other party grievously, but doing so will not remove the fact that the project is failed and the time spent on it is already gone (along with a possible window of opportunity or significant business value). Traditional approach is trusting a lot on agreements, whereas Agile approach rests the responsibility and opportunity to steer the project to the customer, as it should be. The organization can, in concrete terms, keep responsibility in their own hands. Of course, that doesn’t magically remove problems and mistakes from projects, but the organization remains in the best possible position to act on them.

As a second general note, I claimed that a project without a solid vision and a good understanding of constraints fails even before it has started. How do you steer a project to its destination if you don’t know what it is? Or how much you can spend time or money on it? You don’t, of course, so it’s imperative to understand them. Don’t start development until you do.

A lot of the focus in Agile processes is on having the right people on board and by having them communicate openly. And that doesn’t mean well designed reporting (although that may be part of it). It means talking to each other, within the project and to people outside the project. Face-to-face, if you can. Avoid information bottlenecks (like the traditional project manager) and promote many-to-many discussions and information radiators. Get users involved as much as you can. And so on.

Lastly I emphasized that Agile isn’t a cost savings scheme but a value increasing scheme. As a consequence of generating value more effectively most Agile projects also save costs, but if cost savings are the main focus, organizations very easily save in the wrong places (i.e. in the beginning and from communication) and therefore ruin (or at least damage) their success chances. Based on personal experiences, I’d say that Agile projects cost more in the early phases of the project than the traditional approach. But so would the traditional project if it tried to make sure people know each other and talk about important things together. Many problems traditional projects have are because they don’t.

I’m not sure that was quickly, but let’s hope you got this far. If you did, please leave comments on what you think of my points and opinions. Do you think I’m going the right way?