Coder-friendly

Agile becomes popular. The pillar of Agile approaches is the Agile Manifesto which focuses on 4 values:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

These values are important to remember : before trying to learn Scrum or XP, just read them sometimes.

Do you know who are the authors of this manifesto? Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C.Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas. You can get their biographies here.

The books phenomenon

When we investigate a new domain, read a book is one of the most efficient way to get an overview. I’ve searched for books from these authors on Amazon and the results impressed me.

In order to share my feelings with you, I put here books from these authors if they are related to Agile approaches :

• every book which has “Agile” or “Agility” in its title
• every book which presents an Agile methodoly (Scrum, Extreme Programming, etc)
• every book which presents refactoring, testing, code quality or other technical stuff that are used to “responding to change”
• every book which presents pragmatic thinking and which is not related to a specific language  (Java, Ruby, etc)

Feelings are strange

Does the number of books from these authors impress you? Really? Evangelism is often required in order to make ideas popular : books are part of the system. And it’s amazing: each book has pretty good reviews on Amazon (min 4/5). They are good references on this domain and these guys have made a tremendous job for software engineering : I encourage every developer to subscribe to their feeds (most of them have a blog, search engines are your friends).

But it’s interesting to see an opposite view. In his post, “Good Agile, bad agile“, Steve Yegge (a “googler”) criticizes methodologies:

• anything that calls itself a “Methodology” is stupid, on general principle.
• anything that requires “evangelists” and offers seminars, exists soley for the purpose of making money.
• anything that never mentions any competition or alternatives is dubiously self-serving.
• anything that does diagrams with hand-wavy math is stupid, on general principle.

And by “stupid”, I mean it’s “incredibly brilliant marketing targeted at stupid people.”

Maybe, this view is not really objective and the biggest problem of Steve’s post is that Steve considers that the Google model can be replicated in any company, and for cultural history of others companies, it’s often wrong. And I disagree that, when you listen to others ideas, you’re stupid. But I agree with Steve on one point that we can observe when evangelism is too strong:

anything that never mentions any competition

Agile approaches don’t work with any type of projects

But currently, I worry about the “agility” word because it seems that it becomes a buzzword and most of us forget sometimes that Agile approaches are not silver-bullets:

• it’s hard to become agile
• agile is not always the most appropriate approach

The first point is always the one which is addressed when we say that it’s not a silver-bullet, but the second one is often forgotten. In his best-seller “Code complete“, Steve McConnell wrote:

In software, consultants sometimes tell you to buy into certain software-development methods to the exclusion of other methods. That’s unfortunate because if you buy into any single methodology 100 percent, you’ll see the whole world in terms of that methodology. In some instances, you’ll miss opportunities to use other methods better suited to your current problem.

Most of (all?) authors of the Agile manifesto agrees with the Steve’s view about methods. So, focus on this point !

When is agile relevant?

Danc gives a spectrum of Process Complexity in his post “Managing game design risk: Part I”

• Simple Processes: When both requirements and execution are quite certain, then the projects can be managed with relatively simple processes. Often a simple checklist does the trick. The repetative steps that a single worker performs on an assembly line is a good example of a simple task.
• Complicated: When the requirements and execution get out of hand slightly, you end up with a project that can still be completed with your typical check list. However, you need to increase the number of rule and steps necessary to accomplish the task. Bridge building is a good example of a complicated task.
• Complex: Many projects fall into the dangerous middle ground where requirements and execution is somewhat defined, but rife with multiple layers of uncertainty. In these situations, high feedback, agile processes let team steer their way towards ago despite high risk and uncertainty. Software development is a good example of a complex task.
• Chaotic Processes: When both requirements and execution uncertainty is very high, projects tend to devolve into unmanageable chaos. Success arises as often from luck as it does from any real process.

Agile is adapted to complex projects. For others kinds of projects, there’s probably a better way to manage them. If your project is complicated, you may have a look at Lean approaches or other methodologies. When you have a simple project, I think that the Waterfall way is a good one: you will always be more efficient if you can specify clearly the requirements at the beginning.

Conclusion

Don’t become an evangelist yourself : look at your project and decide which methodologies is the most adapted. Sometimes, Agile is not the right one but if you see that your requirements are far from agreement or certainty, Agile approaches are probably a good choice.

Do you think that you become an evangelist sometimes?