As you saw from my last post, I’m fairly bearish when it comes to maturity models. In many cases, maturity models are just tools used by consultants and sales engineers selling expensive ‘how to’ guides to senior IT executives. But even discounting these out, maturity models are guides to help managers size up their current processes, identify gaps, and leverage ‘off the shelf’ processes to gain a new level of process maturity.Sounds great. Here’s the issue with agile – Agile, implemented as a collection of processes will only get teams slightly more efficient. It will improve speed to market, improve productivity (by cutting put wasted efforts), and help address defects. Awesome right? Now going one step further:

Agile processes in its optimal sense needs to achieve a higher goal of organizational change, efficiency and innovation.

Ok, I know what you’re saying – get off the soap box. What do you mean? Let’s go into these goals briefly:

• Organizational change – Consider processes before and after agile development. The product backlog needs upstream mechanisms to set product strategy and vision, develop high level product requirements, conduct user experience testing, and set priorities. These and other concerns need to wrap a technology department’s partnering, development, integration, and deployment processes. All of these are affected by agile.

• Efficiency – Consider what tools and processes the IT organization needs to improve its productivity? Better bug tracking? Improved functional testing? Better gathering of technical requirements?

• Innovation – Innovation touches a broad set of concerns, so here’s how I would summarize: Are you researching, prototyping, and developing solutions in the most strategic areas of your product or service and leveraging the best talent you have available? Are you identifying talent deficiencies and considering options to invest in your resources or seek new resource opportunities when needed?

Ok, so how do you use mature agile, effect organizational change…?

Two simple answers:

1) Give your teams some leeway to self organize properly and build internal processes. Processes are never fully contained within a team’s structure and by influencing those in the periphery, a larger change can start to take shape. The team has to figure out and develop its processes.

2) Use your agile process to prioritize process creation and improvement. Recognize that process is always in a state of flux and improvement, so when improvements are needed or opportunities identified use an agile / SCRUM process to schedule, commit, and measure improvements.

Next post: SCRUM for Process Maturity