At Rally, we are always working on both maturing and growing our use of Agile. We started with a single development team and over the past 6 years have been through the process of splitting, growing, partnering, and acquiring.
We did this while continuing to inspect and adapt our development and our strategy execution processes. We have teams in various stages of maturity using Scrum and Kanban to run all parts of our company. As the CTO, I have my focus on our strategic planning and execution process.
In 2008, I started to focus on maturing our annual and quarterly planning. To do that, I used Pascal Dennis’ book titled “Getting the Right Things Done” to structure those efforts. (See related post about Learning from A3′s a story of 2009 Quarterly Planning at Rally.)
As part of that effort, we worked to change our quarterly and annual planning process to specifically follow a Plan-Do-Check-Adjust model. (Note that I like Pascal’s use of Adjust, not Act which is typically quoted in the Toyota models.)
Prior to 2009, we were simply using an inspect and adapt process to determine annual and quarterly priorities, aka quarterly rocks, based on feedback from last quarter’s results and the corporate roadmap.
This process worked well, but we had some issues including:
- A moving definition of done based on different standards of work (research, implementation, campaigns..)
- A delay in the feedback loop on strategic efforts made it hard to check and close well
- Too many efforts in a quarter lead to poor quality (We found 5 rocks to be too many for us during a quarter)
None of these are different than what most teams experience with going Agile. So we (1) adjusted and moved to limit our WIP to three rocks, (2) focused on inspecting the definition of done in the meeting, (3) used company wide survey’s to keep from developing group think and (4) chose to do company celebration based on quarterly metrics and not the completion of quarterly rocks.
These all helped make the current process work, but the process was still frustratingly unpredictable, semi-random and always left something to be desired. Many of the reasons for this are explained in Alan Shalloway’s and Don Reinertsen’s posts on PDCA and types of process The Difference Between “Inspect and Adapt” and Plan-Do-Check-Act (PDCA). Unlike Alan, I do not see or perceive a big issue with Scrum. Based on my previous post around the roots of agile; Dean Leffingwell and I are in the same camp; Scrum is Lean.
As a result of moving to PDCA approach, we created a single “True-North” goal for the year and drove our quarterly rocks towards that goal.
Now in Q4 of the year, we had some new changes to our process. By following the PDCA cycle for the year, we put a fine point on CHECK in this final quarter; Subsequently, we have a Q4 quarterly rock focused solely on checking our Q3 and annual work to fine tune it based on real output. This is an example of where PDCA cycle is more intentional than basic inspect and adapt at forcing the discipline of checking.
We focused a quarterly rock on checking to make sure that we are done-done-done with our True North goal for the year. We also have another Q4, cross-functional rock team focused on preparing for Q1 and 2010 annual planning. This PDCA-driven rock is a major milestone for me personally. It moves annual planning solely from my shoulders to a team effort; this pushes ownership of strategy down to the extended management team. As a result, I am very happy with the move to PDCA for our 2009 strategy execution process. In Don Rienertsen’s terms, our PDCA-driven process is more defined, while still with un-predictable output and governed with lots of feedback. This was simply an increase in process maturity that was mandated by our continuing growth.
To do this, we create a team, called the Mountain team, to help the company transition our strategy execution process. This team steered the transition and proposed our quarterly rocks based on the PDCA process. And thanks to the ego-less and steady hand of our CEO, we have a very collaborative culture that quickly converge on these changes and quickly put them into action.
I hope this was helpful for you to learn about our experiences with continuous process improvement and our step-function transition processes. Please note that we are not a perfect comparison to larger organizations trying to transition to large scale agility. In addition to doing lots of growing, we have another difference that started when we began back in 2003. We built Agile and Lean principles into our core values. You can see the difference this might make in my comments to Israel Gat’s post More on Agile Social Contracts.
Specifically our core values are:
- Create your own reality
- Make and meet commitments
- Theory-driven decision making
- Treat people with respect
- Support our community and give back
- Maintain a healthy work/life balance
This is the social contract that we keep with employees. During transitions like this you need culture or a social contract to reinforce your moves toward Agile and Lean behaviors.
About the Author: Ryan Martens is a telemark skier, founding board member of the Entrepreneurs Foundation of Colorado, and Founder and CTO at Rally Software Development. Subscribe today to get free updates by email or RSS.