Dr. Dobb's Digest November 2009
Ryan is founder and CTO of Rally Software. He can be contacted at www.rallydev.com.
Are you preparing your organization to "go Agile"? Have you personally committed yourself to an Agile initiative? Or are you planning to have the teams figure it out and report their successes to you?
Agile software development has been around for a while. It is probably fair to say that it has crossed the chasm and is truly mainstream, at least as far as being accepted in the IT lexicon. That may be why you are now cautiously ready to make your move. But what does it really mean to "go Agile"? What books have you read? Which case studies gave you the guidance to move forward with your initiative? Do you really understand what your teams will be doing? Do you, in turn, know what YOU will be doing? What are the most important actions to take in adopting Agile? In fact, do you have anything at all to do in the adoption since you've heard it is just a development group activity with engineering practices?
Through Rally's work over the years helping organizations large and small adopt Agile, we've come to figure out some fundamental components of what success looks like. Yes, there are roadblocks and challenges. And Agile is not a silver bullet. Yet we believe Agile can bring increased productivity, higher quality, increased ROI, faster customer feedback, and higher morale. How does this happen? What is at the core of this success? Two simple tenets: commitment and a disciplined path for Agile rollout.
We can understand how commitment works at the team level. Agile teams commit to delivering a set of features from a prioritized backlog every timeboxed iteration. They then make a daily commitment on what they will do toward the successful completion of their iteration commitment. At the end of the iteration, the team demos what it was able to complete of its commitment. After review and retrospection, the Agile team then moves to its next iteration, planning what its commitment will be for the next timebox. This team commitment is at the heart of Agile
Where do you fit in with this Agile work? You too must have an Agile commitment. At a high level, transition commitment is often called "executive championship," a "funded business case" or "executive buy-in." To me, these are soft commitments; they are pushed down the organization where the real commitment is enforced. In Agile, the opposite is true. What is really required for Agile success is a commitment I call "The Agile Social Contract." As the lead of an Agile rollout, you create this Agile social contract with the stakeholders and the teams, to answer the question "What is in if for us, and what is your commitment to us?"
This notion of a Social Contract is not mine. Isreal Gat is my mentor on the topic and forms the background of its use. It was a pleasure of mine to meet and work for Israel Gat at BMC back in 2005. I learned about his Social Contract in his office at BMC, but you can read about it on his blog in two posts "A Social Contract for Agile" and "Addition to the Social Contract." What you notice quickly about his contract is that it addresses the true elephant in the room. "If I do this for you, am I going to lose my job?" To me, this declarion of commitment hits at the source of much of the fear, uncertainty and doubt that accompanies any organizational initiative. And, as in Israel's case, it is all the more important to offer this commitment given the economic challenges occurring right now. The Agile Social Contract can't answer the employment question directly, but it does spell out the issues and commitment with empathy and consequences.
To paraphrase Israel:
We have to become more competitive, and Agile is the approach that does this by increasing value delivery, quality and reducing costs. It cuts cost by making the operations cheaper. If we do not do this, none of us will have a job. You might still lose your job to a cheaper labor source. But the chances are lower with good Agile skills. So, I am going to invest in you with training and professional development to increase your skills in an area that is very marketable. In return, I want you to support this effort with everything you have.
This economic imperative may not be the setting that everyone is facing with their Agile rollout. But this type of contract is one that gets everyone rowing together. As Israel noted, this is leading from within. What if your organization is doing well and not feeling this type of economic downturn pressure to adopt Agile? I would suggest that you either find a strategic imperative that you enable through Agile. Or resign yourself to a long boat ride of trying to gain true commitment and real Agile adoption. With the commitment you offer via an Agile Social Contract such as Israel's executive level one, your teams can offer their commitment at the team level. One level of commitment sustains the other. This is key to your Agile success
With a clear Agile social contract, the entire organization can follow a very simple, step-wise adoption process to successfully adopting agility beyond the team level. This process and its success are in your hands. Your Agile Social Contract binds you to commit to all it entails. In return, you will reap the benefits of Agile you had contracted to your organization, the stakeholders, and the teams.
Jean Tabaka and I have written and spoken at the Agile conference about Flow-Pull-Innovate, as a Lean model for successful Agile rollout. It is a simple structure that guides your scaling and maturing of Agile team to teams of teams, to the entire organization. Our five-step process works incrementally and iteratively to mature your organization's level of agility, level of discipline and realization of benefits. These steps are discrete transition states for any team, program or organization. Organizations that understand these steps are very effective at developing strategies to move states quickly and efficiently. That is, they inspect and adapt without wasteful thrashing and churn. These firms plan and experiment with changes in the tools, techniques, methods and infrastructures that prove and enable these states at a small scale before moving to the entire organization.
Realistically assessing the current capabilities for leading teams and programs is the first step in creating a roadmap of priorities for your organziation. For instance, without a clear rollout plan, groups of distributed teams can quickly start running in all directions. That equates to waste of thrashing. An effective Agile rollout map such as our five-step model provides critical focus and scope control for the entire adoption process; one step at time!
What is your role in all of this? You have created and communicated your Agile Social Contract. You are ready to follow the Flow Pull Innovate model for Agile maturing and scaling. Now what?
First, hold an Agile Rollout Planning meeting where you drive for the highest level of commitment to move to the next transition step within an agreed upon timebox. This meeting aligns with other standard Agile meetings, such as an Iteration Planning meeting, in that it drives and is driven by:
In this meeting, you first declare your vision for the organization, re-stating your Agile Social Contract for the entire organization. You and your stakeholders as the Steering Committee determine what your specific goals are for the Agile rollout given the vision. You gain consensus around these Agile adoption goals. You also gain commitment to use the Flow Pull Innovate model for your rollout. In addition, you define your roles in the overall rollout and you select the initial teams, the pilot teams, that you will support in the rollout. Finally, in this kick-off of the Agile rollout, you and your stakeholders commit to what you will complete in the Organizational Implementation backlog before the next meeting.
The Organizational Implementation Backlog is a clear indication of your commitment to the Agile rollout. This backlog prioritizes the work that you and the stakeholders vouch to do in order to support the teams as stated in your Agile Social Contract. The items, also referred to as stories, have a rough costing and a sense of benefit/value that helps guide its ranking and the effort of estimate to drive the item to acceptance/completion. This means that each item must also have clearly articulated success criteria. In the Agile Rollout meeting, or prior to it, the backlog items need to be groomed. That means that they have been roughly prototyped, roughly costed and presented with clear acceptance criteria.
In each subsequent meeting with the Steering committee (or Rollout Team), you will follow the same set of similar steps as the initial meeting:
A Steering Committee that is prepared for this meeting and that has engaged a meeting facilitator can complete this work in two to four hours. In addition to the work stated above, you may need to revisit your Agile Social Contract. It might take a few cycles before you have enough experiences and data to complete your final draft the Agile Social Contract. Once you have it however, it becomes a simple step of commitment along the Agile transition path.
Can you see the simplicity of Agile Adoption when you apply appropriate commitment and structure? A truly effective Agile Social Contract that creates true trust and commitment requires clarity and discipline. With the transparency of a clearly communicated Agile Social Contract, you will establish a strong leadership mechanism that aligns all the stakeholders and teams within your Agile adoption. Of course Enterprise-scale agile adoptions take place in a larger context of the business and market. As Israel Gat stated in his personal Agile Social Contract, we cannot guarantee lifetime employment in this globally competitive world. But, by making a clear commitment to win-win agreements, we can change the conversation into a motivating one versus a de-motivating one. Don't try to scale Agile without a real and personal commitment or without a clear rollout structure. It does not work any better than an Agile team that does not have the discipline to commit.