Posts Tagged ‘Agile’
Observations from Houston
The Houston chapter of APLN arranged an Agile track in the April 30-May 1, 2009 PMI Houston Conference. I had the pleasure of participating during much of the the first day. Following are my major observations from the conference in chronological order:
General: Agile awareness was quite broad amongst participants irrespective of whether they do or do not do software. Just about every project/program manager I had the opportunity to speak with was aware of Agile and anxious to learn more. Many questions to the panel were about Agile. Some asked specifically about applying Agile beyond software. For example, one of the questions posed was:
What does Agile have to offer to a major oil company?
Metaphor for the Agile PMO: Jochen Krebs compares the functioning of the PMO to that of the information booth in Grand Central Terminal in NYC. Hundreds of thousands of people go through the station every day on their own – they are motivated to reach their train and they generally do find their way. If they need help they ask for it, trusting the information booth to give them pertinent and reliable data.
Motivation for adopting Agile: AOL’s transition from a single brand to multiple brands (e.g. AOL Food, AOL Music) was a major factor in their going Agile. Pretty much every brand has its own Agile project team now. (Click here for details on AOL’s branding strategy).
Going live: The product owner at AOL makes the final call whether to deploy (or to hold off on deploying) new functionality or contents.
Agile training: AOL invests 5 days of training/consulting/coaching in each team converting from waterfall to Agile. Training is given in the organic project teams (as distinct from open courses to which anyone can enroll). Newly converted teams are expected to operate on their own (i.e. without consultants) after three iterations.
View from the panel on primary reasons for project failure:
- Lack of alignment.
- Folks do no tell the truth. To succeed, one must be brutally honest.
- Poor expectation management.
View from the panel on ingredients in the ‘secret sauce’ for project success:
- The project/program manager has to be both humble and willful.
- Acting on insights gained in the retrospectives is critical.
- Must know the real status at any point in time. For example, what do the employees think on the subject? What do customers say?
Visualization: Deemed absolutely critical to requirements management in any project of scale. It is the antidote to explosion of requirements data and confusion about requirements (Tony Chen, Seilevel).
Reconfiguring the Business: Readers of this blog are already familiar with many threads in the Reconfiguring the Business presentation I delivered. Click here to read it in entirety. Needless to say, comments on the presentation will be much appreciated.
Scaling Agility: From 0 to 1000
Walter Bodwell delivered an excellent presentation on the subject in Agile Austin last night. The presentation is quite unique in seeing both the “forest” and the “trees”. Walter addresses the operational day-to-day aspects of Scrum in the trenches in parallel with providing insights on the roll-out at the executive level. Highly recommended!
Allocating Your Agile $$
“50-50” is the rule of a thumb many audiophiles use for configuring a good stereo system. 50% of the budget goes toward the speakers; the other 50% toward everything else in the stereo system. The reason is quite simple: stereo systems succeed or fail on the merits of the speakers.
Whatever your Agile budget might be, a good starting point is to spend about 50% of the budget on training, consulting and coaching during the first year of Agile rollout. This figure will probably go down to about 25% during the second year; precious little thereafter. Such budget allocation was used at BMC Software in its Agile rollout and operation between 2004 and 2008: about 50% of the total Agile budget in 2005; 25% in 2006; single digit percentages in 2007 and 2008.
First Year Agile Budget
Starting with 50% for consulting, training and coaching during the first year is rooted in the software engineer being a craftsman. A craftsman learns and develops through apprenticeship. He learns from the masters. The popular Program With the Stars sessions in various software development conferences recognize the power of the apprecnticeship paradigm. A good review of the power of such a session in the Agile 2008 conference can be found in the Working Together… with Technology post by Andrew Shafer.
If you accept the premise of the software engineer as a craftsman, you need to invest in consulting and coaching more than in training. A two or three day Scrum Training class for numerous product managers, developers and testers in your company is, of course, a good start. However, it is the day-in day-out consulting and coaching that will make the training applicable. There is no substitute to a competent Agile coach saying in the middle of a stand-up meeting “Folks, what happened to our collaboration? We are not getting the benefits of the wisdom of teams.”
In addition to the coaching needs of the teams, you as an Agile executive will probably need some coaching by a sure-footed Agile executive coach. Topics should include the following:
- Your role in the Agile roll-out
- Deliverable you own in the Agile roll-out
- Behaviors that are supportive of Agile
- Identification of promising indicators for Agile roll-out
- Identification of early warning sign for Agile roll-out going the wrong way
- Synchronizing release trains across multiple software development methods
- Impact of Agile on downstream functions
Don’t think about these coaching items as luxury you can’t afford. Rather, it is money well spent. It is the cost you as an executive need to pay for being on the Agile train. The train might leave the station without you if you do not invest in your Agile education.
Second and Third Year Agile Budgets
The rationale for reducing the investment in consulting, training and coaching in the second and third year is simple. Various Agilists in your company would become experts themselves. Needless to say you will continue to invest in their skills by sending them to a conference such as Agile 2009. Much of the consulting and coaching, however, should over time be done by your home-grown Agilists.
Consider it an early warning sign if the assimilation of expertise in your company has not generated Agile experts in your teams within a couple of years. You could, of course, allocate your Agile $$ in the second and third year on the 50-50 basis recommended above for the first year. But, chances are something is not working well with your Agile roll-out. The norm in successful Agile roll-outs is to harvest a whole bunch of quotes like the following quip made in 2006 by a QA Director with BMC Software:
There had never been a thought towards returning to Waterfall. We only think about how to be more Agile, how to do this better. No one wants to go back!
Your Battle of the Somme
The 1916 Battle of the Somme is considered to be a disaster of the first order in the annals of British military history. By the end of the first day on the Somme, the butcher’s bill amounted to 60,000 British casualties. When the offensive tapered off after four and a half months of repeated attacks, the bill grew to 420,000 British casualties. “The thing is terrible”, said Lloyd George – Britain’s prime minister at the time – “and beyond human nature to bear, and I feel I can’t go on any longer with the bloody business.”
The contrast between the meticulously prepared battle plan on the one hand, and the meager results the offensive achieved on the other hand, has been the subject of numerous studies since WWI. One of the most important factors that emerged in years and years of research is the lack of timely feedback. Front line troops did not have the means to report their situation to the immense military machine behind that was supposed to support them. As a result, combined arm tactics collapsed. For example, the rigid fire-plan for the rolling artillery fire dictated moving the barrage forward at a predetermined pace. The pace, arguably, had taken into account a realistic rate of progress by the infantry. As the British infantry in most cases got bogged down fairly quickly, after a short while it lost the benefit of close artillery support. Highly inspired that the British infantry was, courage under fire only led to astronomical casualties.
It is easy to attribute the blame to inadequate communication technology. After all, a few cell phones would have made quite a difference. Tempting that such attribution is, it ignores a deeper truth – the people over process truth.
The vast majority of British troops in 1916 consisted of “Kitchener armies” – citizen soldiers who came to the flag to replace the regular British army that got decimated in the first few months of the war. Though trained for battle during 1915 and the first half of 1916, the inexperienced troops were not trusted by the general staff that toiled to prepare a magnificent battle to end the war. The battle plan mandated moving forward upright and in straight line, wave after wave. The perceived “danger” of the troops taking cover and not restarting the advance once they had laid down precluded any tactical initiative and flexibility.
Fast forward to software engineering today. I can certainly appreciate the complexities and risks involved in moving from Waterfall model to Agile software development. For example, your teams might not be sufficiently trained and coached in Agile methods. Naturally, you do not want to change the software process before a certain level of competence using Agile processes has been attained. At Digital Equipment Corporation we used to call it the monkey on the tree phenomenon. Tempting that a new branch on the tree might be, a monkey does not hop over from one branch to another if the prospect of falling down between the two branches is high.
Various obstacles to starting an Agile roll-out, let alone an enterprise level Agile roll-out, could indeed be standing in your way. I would, however, encourage you to pay special attention to your deeper feelings with respect to your “troops”. In your heart of hearts, do you really trust your troops? Do you believe requirements should be dynamically moved between release and backlog in response to the latest insights gained in the trenches? Do you expect product innovation to come from repeated experimentation at the individual team level? Is it acceptable to you to follow the technical intuition of a young and talented developer?
If you have not yet started training some of your product management, development and test resources in Agile methods, I suspect trust, and her twin brother control, might be the core issues you or your company are wrestling with.
The Agile Executive 