I saw this blog by David Anderson asking "Are you part of the Post-Agile Movement?".

I have no doubts that both I and my company are. This doesn't mean I am not an agilist - I greatly believe in Agility - both for businesses and software development teams (there is a difference in how agility shows up for these). But the agile movement seems to be getting bogged down by getting too caught up in agile process practices and ignoring many other things. Certain groups also seem to be trying to control what certain agile practices are instead of fostering their improvement.

Anyway, I am troubled by the current state of the agile movement. While great progress has been made, new problems are arising that we are not addressing. People continue to be confused about what agile even is. In addition, the pendulum that has swung for decades regarding process continues to swing. Too much process - not enough process - too much process - not enough process - too much process - not enough process. This has set up a division between management and development teams - neither of which are as effective as they should be. As developers we need to embrace management and process and as management we need to embrace the development teams and ensure processes work for them. Too much of the current agile methodology focuses on team, individual decisions and a way to be protected from management instead of learning how to work with them.

Merely stating that Scrum practices work at the enterprise level is not enough. We need to learn to speak to management about why this is so. I just spent a couple of days doing a Lean Software Development course with some fairly high level (e.g.., CTO, VP, GM) folks in multi-billion dollar organizations. I was very impressed with their concerns for the problems of both their organizations and how they could empower their staff. Many times I heard stories where their staff (including development teams) needed assistance because what they wanted to do was not productive. I have seen this many times myself. It's nice to say that development teams need to self organize but sometimes they really don't know what to do. They are often in unfamiliar territory themselves and need some leadership.

For Agile to work at the Enterprise level more than practices need to be addressed. Enrolling management needs to occur. Plus we need to deal with issues beyond Scrum practices. The current focus on Agile methods tends to ignore management of project portfolios at the enterprise level as well. It also somehow assumes that Management will just go along with good practices because we know Scrum is good for us. Not quite that simple. You need to enroll people at all levels (Enterprise, Project management and team) to understand why and how they need to work together. This is what we do at Net Objectives.

When Net Objectives started, we focused on design patterns as that is what I (I was it at the start) knew best from a training perspective. We quickly found out that was where the drama was, but the real problem was about the customer - developer relationship. Then we realized agile processes were necessary and expanded to that as well as the role of QA. Concurrently with this we were expanding our design patterns training to include test-driven development. At that point we were pretty much mainstream agile/scrum with technical offerings. But still not enough. In the last two years we've seen the biggest problem in big organizations was the management of product lines and how to do project portfolio management. While many in the scrum/agile community describe how Scrum practices can work at the enterprise (they can) it takes more than a prescriptive statement. With our expansion into Lean we have found ways to improve practices of teams as well as show business leaders how to improve managing projects to increase their ROI. As you can guess, there is no end in sight. We are now starting to look at an enterprise's business practices to see if they need to be improved before automating them. After all, the software is only the enabler of what we are really trying to do - add value to the business.

The purpose of my ramble here is to emphasize how important it is to work at all levels in software development:

• agile process
• agile analysis
• technical issues (writing code)
• quality assurance
• business principles (as espoused by Lean)

I guess this definitely makes us post agile.

If you find yourself at Agile 2007 next week, please come by our booth and say hi and tell me you read my blog!

Technorati Tags: Lean-Agile

tag with del.icio.us