Agile is a Great Answer to an Important Question Never Asked

Sometimes I think agile software development is a really good answer to a question that has never been asked.

There are plenty of good reasons for bottom-up agile initiatives in companies. If implemented correctly, agile is great for software developers. If software development is a company bottleneck, a bottom up agile initiative can be great for the company too.

You may feel there is a "but" coming, and there is:

But in the long run, agile initiatives are unlikely to succeed unless managers at all levels buy into it. That is unlikely to happen with a bottom-up initiative, because agile methods are practical implementations of a management paradigm that is very different from what most companies have. Bottom up agile initiatives have to fight the system. In most cases the system will win.

Agile has a much better chance of succeeding when going agile is the response to a management initiative. Top-down initiatives make agile a natural part of a new system. It is still difficult to win, but the agile effort can have support from many other similar initiatives all over the organization.

What are the questions from management that could prompt software developers to reply "we could use [insert favorite agile method]."

Let's begin by listing a few problems management might have, that an agile method might help solve:

  • Software development takes too long
  • Software maintenance costs too much
  • There are too many defects in the software
  • The software we build does not excite the users.
  • We do not see any revenue until at the end of the projects
  • Staff turnover is too high
  • Departmental silos make it difficult to work together
  • Our business strategy and what the IT department delivers don't match
  • Our budget planning is killing us. We want to switch to a budgetless financial system. (You may have to think about that one a bit.)
  • We want to democratize the company (Like Gore & Associates, or Semco)
  • We want to redesign the company into a network structure (Like Gore & Associates, Semco, BNI, VISA or Virgin.)
  • We need to reduce strategic cycle time and need to shorten software development cycles to match
  • We need to improve the quality of strategic and tactical decision making throughout the company

All are valid objectives. (Technically, they are intermediate objectives, not end goals. I'll let you reverse engineer suitable end goals yourself.) The last four are the real winners, and of course they are linked together with each other, and with the other questions. I haven't heard about  a company where management has asked one of those questions though. (If you have, please tell me about it.)

The problem with agile is that agile offers excellent solutions to problems that managers should ask, but don't. Today there is plenty of hard evidence that:

  • Democratized companies are more innovative than others. Companies like Gore and Semco have a history of leaving their competitors their wake.
  • Network organizations are faster, more innovative and more resilient than hierarchical organizations.
  • Cycle time is a key differentiator in strategic planning. Having the same strategic cycle time as your competitors because nobody thought about it is downright embarrassing.
  • Decentralized organizations can make better decisions faster than hierarchical command & control organizations.
If you use Systems Thinking (in one form or another) to design a company that does software development, agile (in one form or another) will almost inevitably pop out as the solution to several common problems, except perhaps the most common problem of all: Lack of interest in solving systemic problems.

Comments

Bob Marshall said…
Shame there's no "tweet this" button!
August 12, 2010 4:54 PM
Kallokain said…
Now there is!

Thank you for pointing it out.
August 13, 2010 12:00 AM
Post a Comment

Popular posts from this blog

Waterfall vs. Agile: Battle of the Dunces or A Race to the Bottom?

Image
The major software methodology wars since the mid 1950’s. Someone was wrong on the Internet, so here we go… In a recent HBR article, It’s Time to End the Battle Between Waterfall and Agile , the author sets up a false premise: There is a war between Waterfall methodology and Agile. The war must end. And finally, you can combine the approaches to get the best of both worlds. This sounds good, but the article is based on a misunderstanding of both Waterfall and Agile. Also, there is no war between Waterfall methodology and Agile. There can’t be, because Waterfall methodology does not exist! Waterfall is a name for large projects that failed in the 1960’s. Waterfall was never a methodology, but a failure to apply the methodologies that existed back then. As I will show towards the end of this article, at least one of the “successful” Waterfall projects mentioned in the HBR article was neither successful, nor a Waterfall project. I got invaluable help from Alistair Cockburn. He fact che
Read more

Performance Evaluations, Business Strategy, and Agile Methodologies

Image
It is performance evaluation time in many companies. This can be stressful, both to the people being evaluated, and the people doing the evaluation. In companies adopting agile software development methods, the tension can be extraordinary. Individual performance evaluations run counter to agile philosophy, which emphasizes team performance over individual performance. However, managers and corporate leaders need to take a few steps back, and consider the impact performance evaluations have on the organization as a whole. Especially now, in the midst of a recession, it is important to look at a companies current policies to see if they can be improved, or if they are actually holding the company back. So, how can a manager evaluate policy? Performance evaluation policies can serve as an excellent example. I'll confine myself to discussing the so-called ‘rank and yank’ methods. These are performance reviews were employees are ranked using a forced ranking system. It usually looks so
Read more

Agile Requirements Structures, Part 1

Image
If you have worked in large Agile projects or programs, you may have noticed that there is often quite a bit of confusion about requirements, what the requirement types are, their purpose, how to write them, how to use them, and above all, what not to do with them. There are many causes for this confusion. Here are some of the more common I have seen: Nobody in the organization has read up on the requirements model it is using, so everyone makes their own interpretation. The organization deviates from a standard requirements model, but nobody knows which standard model the organization is deviating from, and/or there is no agreement about how they deviate from it. The organization has not documented its own requirements model very well. The organization mixes two or more different requirements models, often without realizing it. The organization has documented its requirements model, but finding the documentation is an epic project in itself, on par with when Henry Sta
Read more