It’s occurred to me that in aggregate these articles would a great little book or pamphlet on enterprise scale agile transition. I’ve been greatly impressed with the work Wordclay did on the Lean & Kanban 2009 proceedings book, so I’ll have a discussion with them about publishing these in a book format. Technorati tag: David+Anderson, Agile+Management, Agile, Borland

CMMI Model Level 4 is often thought of like Nebraska or Kansas - it’s the flyover territory of CMMI. The big offshore outsource companies often think of Level 4 as something that they can skip - jumping from level 3 to level 5. After all, there are only 4 process areas. Two in Level 4 and two in Level 5.

When I was at Microsoft, working on MSF for CMMI Process Improvement, we talked about the future prospect of an enhanced edition that provided full coverage of Level 4 and 5. [The current release has about 80% coverage of Levels 2 and 3, and 20% coverage of Levels 4 and 5.] There was no market demand for a Level 4 solution. Our market research was telling us that there was a market for a Level 3 solution - the one we produced - aimed at the government contracting market in North America and the ISO 9000 compliance market in South America. We also knew that there was a market for a Level 5 template for TFS - mostly aimed at the offshore outsourcing companies. Level 4 just didn’t come in to our plans. It was flyover territory. It seemed no one does Level 4. If you look at the list of CMMI appraised firms, there are very few at Level 4. So why am I suddenly a big advocate of Level 4?

Well, it seems from discussions with clients and potential clients in America and Europe, our clients need to have the equivalent of Level 4 organizational maturity in order to meet their business goals and strategic objectives. They don’t need to be an optimizing organization at Level 5 - that would be icing on the cake. But they do need to be predictable. They want to have strong delivery with low variability. The want to be proactive and drive down cycle times using objective quantitative management. They need all of this to deliver on business goals within the tight financial controls and corporate governance that they now find themselves under. They need to be the equivalent of Level 4.

The real problem is that typical Agile methods can only take them to Level 3. So Agile isn’t enough. That’s where we come in. Our experience in creating cultures that drive towards high maturity (Levels 4 and 5) while implementing Lean and Agile techniques is still fairly unique. We help clients reconfigure their organizational culture to enable a high maturity organization to emerge while still gaining all the benefits of Agile and Lean methods.

The aim is to generate a clutch of Level 4 equivalent organizations. Clients who can estimate projects and iterations and deliver results with a low degree of variation from the original estimate. Firms who use predictive methods and leading indicators to learn and adapt quicker than those simply using retrospective methods and lagging indicators. And businesses who are led by objectivity and have left superstition and subjectivity behind in their organizational past.

CMMI Model Level 4 has real business relevance. Business that achieve it will achieve their business goals, hit their numbers and delight customers, shareholders and employees. Getting to Level 5 will allow a firm to become ever more competitive and to dominate their market. But for many firms the need to achieve the equivalent of Level 4 maturity is a business imperative, now! Anything less will leave all stakeholders dissatisfied. Technorati tag: David+Anderson, agile+management, CMMI

Dan has his own alternative to my Recipe for Success. I thought it might be interesting to list Dan’s four hot points and then add some commentary.

1. Break work down in to small fine-grained similarly sized elements
2. Prioritize
3. Emphasize quality throughout the lifecycle
4. Make frequent incremental releases to production

Number 1 requires that each work item is independently testable and preferably independently deployable

Number 4 requires the use of latent code patterns (assuming a single code line is being maintained in a continuous integration fashion) to prevent code that isn’t ready for release from escaping in to the wild accidentally. It also requires that latency is added to the test suite as a standard part of testing prior to release. Test the functionality being released and test the latency of the functionality that is complete but not being released.[Why does this happen? Well completed functionality may belong to a different project with a different release schedule but may be living in the same code base and environment. This is more likely to occur in an enterprise environment than a product or service company.]

Comparison and Commentary

Breaking work down to small fine-grained similarly sized elements has been a core part of Feature-Driven Development (FDD) since the days when it was still known as the The Coad Method (circa 1995). I made this a key tenet of the message in my book. So why did I drop it from the Recipe for Success? The recipe was originally called “low hanging fruit” and was supposed to highlight 4 things that a new manager could do to quickly generate improvement in a dysfunctional team or project. I’ve been under pressure (from commentators on this blog) to add a fifth element to my recipe, stating that reducing variability in the process is also important. The notion that we break work down to small fine-grained similarly sized elements is precisely the same idea. It’s a low variability play.

I didn’t include reducing variation in the Recipe because in my opinion it is hard to do and meets with a huge resistance. It asks people to heavily change their behavior in such a way that they don’t comprehend the benefit. My belief is that while a team gets on with the 4 steps in my recipe, they will eventually realize that they have to reduce variability. In other words, reduction of variability is a higher maturity activity. No coincidence, in my opinion, that the same idea appears at CMMI level 4. A High Maturity level in CMMI.

Dan’s view can be made to work through strong management and enforcement through positional power. The team can acquiesce or move elsewhere. While this can have tactical advantages, I’m on record several times since August 2006 stating why I don’t believe in using position power like this. Acquiescence is not conducive to institutionalization and long term adoption of an approach. Hence, I believe that you fix other things first and let variability reduce over time.

Dan includes prioritization and he puts it at number 2 while I had it at number 4. Again, my reason for this is that it is hard and it requires the collaboration of people from other departments outside engineering. Of the low hanging fruit, it is the highest placed and hardest to obtain. Hence, while Dan and I are in agreement, I feel that some basic organizational maturity is required before prioritization can be done successfully.

We’re in complete agreement over quality. As Robert C. Martin said in his after dinner speech at Agile 2008, “The jury is in on this one!”

Finally, Dan suggests that frequent incremental releases to production are key. And yes they are! So why doesn’t it appear in my recipe? Well I like Dan making it explicit. The notion that your reduce (or limit) work-in-progress appears at number 2 in my list. You can’t achieve this without being capable of making frequent incremental releases to production. However, as I said, I like that Dan makes it explicit. It was explicit in the Principles Behind the Manifesto and it still should be.

So Dan’s recipe and mine are not so different. The order and emphasis is a little different. Dan wants to focus on reducing variability. If it were in my recipe, it would be number 5. We agree on quality, small amounts of work-in-progress released to production often and prioritization. The one thing Dan misses from my recipe is balancing demand against throughput. This is the mechanism I use to achieve sustainable pace and to implement a pull system which provides a nice mechanism for simple prioritization. Prioritizing becomes easier when you have demand balanced against throughput of work items.

Combing Ideas

So if we combine Dan’s recipe with mine, we’d get something like this…

1. Focus on Quality Throughout the Lifecycle
2. Reduce (or limit) Work-in-Progress and Release it to Production Frequently
3. Balance Demand against Throughput
4. Prioritize
5. Reduce Variability in the Process by analyzing work items in to small, fine-grained, similarly sized elements that are independently testable and deployable

:-D It won’t fit on a T-Shirt quite so readily Technorati tag: Agile, Agile+Management, David+Anderson, Daniel+Vacanti

My big take-away from the session was that several of the folks in my small group and at least one of the main presenters, gave a summary of their transition to agile that went something like this…

One of our execs met some guy sitting in First Class, who persuaded him that if we weren’t agile we were being left behind. So when he got back from his trip, he sought me out as a known change agent and asked me to lead a transition to agile development. So I assembled a small team and we learned all their was to know about agile. [Perhaps we hired a consultant to help us.] Then we made a plan of how to take our teams from the traditional waterfall style development method we’d been using to an agile/Scrum approach. Over the next 9 months we executed on that plan, and gradually we saw all the agile practices adopted across all of our teams. We completed that process 3 months ago and now we are agile!

Does anything strike you as ironic about this?

The way to enterprise agility was to make a big plan up front, based on a top-down, management led initiative, and to command and control the team to change to an agile style of working. Then to execute against the plan, and when every task on the plan was completed to declare that the change was done!

As I stated in my previous post, I’d been there before and struggled to achieve both scale and longevity with the changes. My fear with many of the enterprise scale transitions now taking place is that they will suffer the same fate. When the management that led the change is gone, the teams will gradually atrophy back to a traditional way of working. Unless a fundamental change in the organizational culture is achieved and the new culture is institutionalized from top to bottom in the organization, then I fear that the benefits of agility - even they are recognized as hyper-productivity in some teams - will be short-lived. An agile may get labeled as just another management fad. [Check out Sanjiv Augustine answering the 5Qs at PM Boulevard and his scenario #2 that Agile may indeed be just the management “fad of the year.”] Technorati tag: Agile, Software+Engineering, David+Anderson, Pete+Behrens, Sanjiv+Augustine

I blogged before that I took a different approach on joining Corbis. I went after the culture rather than leading change to a specific prescriptive method, such as Feature Driven Development. I did this because I wanted to achieve organization level change and institutionalization of the results. Previously, I had enjoyed localized success with my immediate development team or project but had not managed an enterprise level adoption, nor had the changed survived my departure by more than a year - at both Sprint PCS and Motorola. As I also stated I was afraid of the J-curve effect that driving home a specific prescribed process change might have at Corbis. So I opted for the long game of cultural change.

While I’m delighted with the results and the cultural change, while hard to measure objectively, appears to be widely recognized anecdotally, I am frustrated by some of the results. I’ve seen a lot of code released and a lot of successful releases. I’ve seen some very high quality and very few defects escaping in to our production environments, but I haven’t yet seen hyper-productivity.

Jeff Sutherland has been talking a lot about how difficult it is to achieve hyper-productivity. He talks about how few Scrum teams have ever achieved it. [He defines this as performance at least four times higher than might be normal.] He holds up the team that created Borland Quattro Pro as one of the highest performing teams of all time. A team that produced at least a 10x productivity gain. At Agile 2007, I spent some time with Jeff and shared with him the data from the Device Management project that Daniel Vacanti and I led at Motorola in 2004. The data compares favorably with the Borland Quattro Pro project. Even data from lesser performing FDD projects (the Singapore project - though it was a much larger project) and others from my team at Sprint and some others from FDD teams I’ve met along the way, tends to indicate hyper-productive results, and often with incredibly high quality data. Hence, over the years I’ve been used to achieving hyper-productivity with my teams.

So what’s up at 710 2nd Ave in Seattle? Why no hyper-productivity?

My guess on this is that cultural change and institutionalization and what goes with it - a high degree of autonomy, delegation, empowerment and self-organization - takes a lot longer to achieve hyper-productive results. The advantage is that change is achieved with a much lower degree of resistance, with very low attrition and change-driven churn and the change will stick and survive management changes and the general churn of projects and personnel over the coming years.

In the past, I’ve been an aggressive change agent. The CMO at Sprint PCS described me as “hard driving.” That approach achieved some localized results but equally it made me unpopular with some and probably left a residue of resentment towards management led change amongst the skeptical individual contributors. Folks acquiesced and played along with the rules of FDD and they enjoyed the success of projects delivered, but when the management wasn’t there to enforce the rules any more, they fell back in to the same old ways of working. The right way is to let the team make change its own. Through ownership the seeds of long term support and advocacy are born.

So while I wait for hyper-productivity to emerge or evolve through a series of kaizen events, I’m not unhappy. I set out to change a culture and to achieve an institutionalization of those changes that will eventually survive me and the rest of the management team. I’ve delivered on that goal, but darn it I miss the kick out of seeing some hyper-productivity. Technorati tag: Agile, Software+Engineering, David+Anderson,