Stuck Fermentation – Converting to Agile Stalls…

In the wine making world, you can experience a lot of problems along your path to making great wine. One problem that can cause headaches for a winemaker is called “stuck fermentation”. It’s when the fermentation of the must (grape juice) stops before all the sugar converts to alcohol. Fortunately for the winemaker, the addition of a cultured yeast can generally kick start things again and ultimately the wine can turn out fine.

 

Where I work, the conversion to agility started with the acquisition of a small start-up software company. In our case, the acquiring company was a case book study on waterfall – numerous hand-offs with each hand-off generally crossing organizational boundaries. One group made a business request. Another group wrote requirements void of any hint of solution. Another group created the functional design for the solution and yet another group created the technical design. The technical design included pseudo code for all logic including DB queries. A DB group converted the word version queries to real DB queries and a separate development group coded the C++ logic. You think this is bad? It gets worse… Same approach for testing (test planners, test automators and test executers), documentation & training (planners, writers, training planners, trainers), etc…

 

It was a nightmare but for some reason, I never gave up. I continued to push the two teams I was responsible for and who were using agile to show the rest of the company that we were special. We continued to prove ourselves and over the course of two years, we were the only group that really turned heads. There were a lot of reasons for this and to be fair, they weren’t all a result of our performance. For example;

• We were developing the “new” thing – what everyone was interested in and cared about
• We didn’t have to conform to existing functionality and backwards compatibility constraints (at least not originally)
• We were considered innovators and so upper management was excited – plus they just spent a lot of money to purchase our small little company
• We were experienced in the new technologies – in our case web services, .NET, etc.
• We had the skills – we had already gone through the evolution of growing a larger number of architects vs. being bottled necked by an elite analysis team. We didn’t need one or two skilled architects telling everyone what to do. We didn’t need specialized DB administrators – everyone had the skills and we mentored people well

 

After two years of persistence, I convinced upper management that there was a better way. One that would deliver a better product and at a faster pace. The time had come and over the course of four weeks, we rolled out the implementation of an agile release train. We went from 2 small teams to 10 teams – all executing in two week iterations. About 100 practitioners in all. It was a great time and agile was the answer to everyone’s problems… It was time… October 2007… and it was fun!

It’s now August 2008 and we are about to kick-off our fourth agile release planning session. Our fourth release will follow a 3×2 cadence and we will have 10 teams working towards our vision and roadmap. There are a lot of great things occurring and we are still executing well. However, we have never had the luxury of being 100% agile.

 

Unfortunately, things are getting more difficult now. As mentioned before, we were a very waterfall driven company. The flagship product is responsible for billing and OSS functionality for large scale clients. Our software handles 12,000+ CSRs and over 40,000,000 subscribers. We operate software in a service bureau environment as well as in a client hosted model. It’s mission critical software and we have contracts and SLAs that require numerous process checks.

 

We are getting stuck – for numerous reasons. Rather than go into each situation, I am going to focus on one root problem area. Waterfall and agile. Oil and water.

 

However, rather than take a religious position on waterfall vs. agile, I am going to assume that in our case, we can’t go 100% agile. It’s just not possible – not yet at least.

 

This series of posts will highlight areas that have caused us problems and strategies we have used to eliminate the issues. In some cases, we have had to swallow our pride and turn away from true agility. In each of these situations, we hope in our hearts that it’s a temporary thing. Some of the topics we will cover include;

• Leveraging the concepts of SOA to define process and ownership boundaries
• Synchronizing a waterfall and agile release cycle
• Setting agile up for independence through higher standards of quality
• Delayed production cycles eliminating true feedback loops
• Being constrained by the current “bar” of functionality clients already have in existing deployed applications
• Understanding how system integration complexity can create gridlock
• How the cog in the wheel resource planning strategy can destroy team chemistry

 

It’s been a difficult time for us but like stuck fermentation in the wine making world, I believe a solution exists. I am determined to ensure our path towards agility is only stalling vs. stopping. Agile is for real and it’s here to stay. Why? Because it has nothing to do with software development and everything to do with team accountability and empowerment. That’s the difference!

 

This topic is a touchy one and I will be sure to offend many. However, I hope it’s a learning experience for everyone and I invite anyone and everyone to contribute to the topic.

 

For now, here’s to getting unstuck… Stay tuned…