q3) What were the (say) 3 biggest obstacles to conversion and how did you overcome them?
Is Agile another good-for-nothing management consulting fad? We did not start from square zero trying to implement Agile. Rather, having been exposed in the past to various methodical and management consulting experiments which were carried out half-heartedly, people in the trenches wondered at the beginning whether Agile was another one of “this too shall pass” initiatives. Will Israel and his staff walk the talk was an open question when we started rolling.
The defining moment for our sincerity and commitment happened at the conclusion of one of the release planning days. Paul Beaver, the senior director in charge of PATROL and the BMC Performance Manager, asked for a thumb-of-five vote1. One of the teams came back with an average of 2 as their confidence level. Upon enquiring, the team members sort of said “Well, we do not really believe we can deliver, but we thought this is the plan management wanted…”
Paul, to his great credit, sent the team back to the drawing board, held another release planning day at a later date, and ultimately accepted a revised plan for which the team confidence level was 3.5. Since this episode, nobody ever doubted our total commitment to Agile.
Always-releasable: I can’t convey in words how difficult this intuitively simple principle was to implement. There is nothing extraordinary that I can point out to as the reason for always-releasable being so difficult to attain. The grand total of “infinite” number of trivial deltas/incompatibilities between components of the product suite, their containers (i.e. the SCM’s), and the engineering practices across five development sites proved to be almost insurmountable. We overcame the challenge by simply putting in an incredible amount of hard and tedious work, eliminating the obstacles one by one over a period of time that felt like ages.
Once we reached the always- releasable state, the improvement in productivity, velocity, quality and predictability was dramatic. The code became reasonably stable on an on-going basis rather than rarely stable till the very end of the release. The effects of various bugs in our code were not accumulated nor compounded. Rather, most of the bugs got knocked out “real time.”
While in general I believe Agile practices should be reasonably flexible – i.e. tailor the practices to the situation at hand – always-releasable is for me a non-negotiable.
I feel so strongly about it I would go as far as saying one does not really practice Agile until the always-releasable state has been achieved.
When the magic fails to work: Towards the delivery of a major release I had a layover in NYC on the way back from Tel Aviv, Israel to Austin. TX. I called my good friend Roy Ritthaler who was in charge of product management for the business unit. To my friendly question “How are you doing, Roy?” I got the authentic, maybe too authentic, answer “Better than you, Israel”…. Turned out the release was in fairly deep sneakers. The number one reason for the difficult situation we were facing was me being overly aggressive on the release, betting that our velocity would rise to the level required to produce a very complicated suite of products. The fact of the matter was our velocity at this point in time was not yet high enough (thought it became incredibly fast later). I lost in the critical race between Scrum methodical progress and the need to introduce a “big bang” product suite in our market.
The crisis around the release being in trouble revealed I had not done a good enough job educating Marketing, Sales, Software Consultants and Customer Support on the nature of Agile. Things that are standard operating procedure for Agile in R&D - e.g. ship the features you can and catch up on the features you missed in the next release – became highly controversial. In particular, the spirit of Agile, as distinct from the mechanics, was extremely difficult to explain amidst the crisis.
Bill Miller, who was my boss at the time, saved the day. He grasped that the fundamental problem had nothing to do with Agile – we would have faced the very same crisis had we been playing Tin-ker-toy instead of Scrumming. The furor we were facing was about our go-to-market machine being thrown out of balance as a result of the release problems. The challenge was to align R&D with the business, not about Agile.
Painful that the crisis was at the time, it was the trigger for our transition from Waterfall optimized organization to Agile organization. This transition eventually led to our pioneering work in the area of Agile-Based-Market-Of-One. While it certainly did not feel so at the time, the release crisis actually was a blessing in disguise – it forced us to thoroughly revisi our approach to Agile. We ultimately gained much deeper mastery of the subtle issues of end-to-end Agile within the corporate fabric.
1 A 1-5 confidence voting scale based on the number of fingers one displays: 1=this project is heading towards total disaster and I am updating my resume as soon as the meeting ends; 5=we will deliver even if a hydrogen bomb explodes in 10431 Morado Circle, Austin, TX (one of the BMC site where we were Scrumming).
Comments