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.

I’ve been thinking about leaning a lot lately, and not of the pressed-wood bookshelf nuisance variety. I talk about Lean with my colleague and President of Rally, Ryan Martens. So when I talk about a leaning bookshelf, I’m referring to my interest in Lean in all its forms. I am talking about the books I’ve been reading  that pertain to Lean. And, more specifically, how can I turn my “Leaning bookshelf” into a continuous “learning bookshelf”?  How can I think about my evolution of thought and practice with regard to Agile as influenced by Lean? What could be a good, rewarding goal?

And so, through discussions with Ryan and some of my own quiet thought, I came up with a goal of improving my notion of learning. Yes, for me, that seems to be what I am discovering more and more about Lean:

• How to learn
• How to teach others to learn
• How to encourage organizational learning
• How to avoid/eliminate re-learning

And so in this post, I thought I would share what I am reading, have read, or am about to read, and ask you for your comments and recommendations with regard to my leaning—>learning path. Some of the books may not look directly associated with Lean. I just know that they have been part of my lean learning journey.

The Contents of My Leaning Bookshelf:

1. Getting the Right Thing Done – Pascal Dennis
2. Hitotsubashi on Knowledge Management – Hirotaka Takeuchi and Ikujiro Nonaka
3. Implementing Lean Software Development: from Concept to Cash – Mary and Tom Poppendieck
4. Lean Software Development: An Agile Toolkit – Mary Poppendieck and Tom Poppendieck
5. Lean Thinking – James P. Womack amd Daniel T. Jones
6. Lean Transformation: How to Change Your Business into a Lean Enterprise – Bruce A. Henderson and Jorge L.Larco
7. Learning to See – Mike Rother and John Shook
8. Managing to Learn – John Shook
9. Product Development for the Lean Enterprise – Michael N. Kennedy
10. Ready, Set, Dominate – Michael Kennedy, Kent Harmon, Ed Minnock
11. Scaling Lean and Agile Development – Craig Larman, Bas Vodde
12. Scrumban – Corey Ladas
13. The Knowledge-Creating Company – Ikujiro Nonaka and Hirotaka Takeuchi
14. The Elegant Solution – Matthew E. May
15. The Toyota Way – Jeffrey Liker
16. Thinking Beyond Lean – Michael A. Cusumano and Kentaro Nobeoka
17. The Art of Lean Software Development – Curt Hibbs, Steve Jewett, & Mike Sullivan
18. The Goal – Eliyahu M. Goldratt

Looking at my leaning bookshelf and thinking of my focus on learning, I realize I haven’t included any Senge books or others about organizational learning. That will have to wait for another post.

What books are important to you on your leaning/learning path?