Q2 - Israel Gat

q2) Can you describe the scale of your Agile conversion, the time frame and how you went about it?

By the end of the first year (2005) of Agile operations we had 350 product managers, testers and developers furiously “Scrumming”. Today (summer 2008) BMC has close to 1000 Scrum users/seats. Details of growth as function of time during the first year are given in the chart at the bottom of this answer.  [clarke: click the image below to get the full size view]

Three “ingredients” were at the heart of our Agile/Scrum implementation:

1. Intentionality: We were crystal clear about converting to Agile no matter what. Becky Strauss, who managed the Scrum assimilation program, summarized it so very eloquently, as follows: 

“There has 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!”

2. Trust: We fully trusted the teams to do the right thing(s) within the boundaries of the methodical rigor prescribed by the Rally Software consultants. The fundamental tenet we held was very simple: we hired the team members for their creativity and motivation; both go down the drain without trust. 

Our trust was amply rewarded in multiple ways: A) it was reciprocated - we, as the management team - were trusted by employees in the trenches; B) the trust instilled confidence in the teams; and, C) the trust, compounded by the first few visible accomplishments, built enormous pride.

3. Risk taking: Doing Agile is like learning to ride a bike – you had better be ready to fall, fall and fall again until you master the art. The risks of falling are nicely compensated by the velocity – on the bike and in doing Agile - one ultimately attains. The important thing is to be able to learn the lessons from calculated risks that were not well calculated.

My philosophy of risk-taking in the Agile context is deeply rooted in my view of the art of programming being craftsmanship that one best learns through apprenticeship. An apprentice does not become a good craftsman, let alone a great craftsman, by minimizing risks. Rather. It is the willingness to accept failure as the sometimes inevitable twin brother of aspiring to always do better that makes a craftsman.

To my way of thinking, the three elements listed above form a cohesive philosophy of Agile transformation:

• Trust is a derivative of intentionality. One cannot transform an organization single handedly. Trust “recruits” partners for carrying out the transformation.
• Unless one is willing to takes risks, many of the benefits of trust are lost. Trust leads to empowerment; and, empowerment and risk-taking are inextricably linked. One needs to manage empowerment and risk-taking in tandem as the foundation on which successful Agile projects evolve.

I will discuss various details of BMC’s Agile transformation in my forthcoming answers. However, if you are starting an Agile program today, you do not need to burden yourself with the myriads of details that need to be figured out along the way. If you genuinely adhere to them, the three principles discussed here – intentionality, trust and risk-taking – will get your Agile program going.