Entries tagged with “PDCA”.


This week both Jean and I delivered talks on the Agile organization at Agile 2010 in Orlando. Whether you were able to attend one, both or neither, this post shares the handouts and materials that we used in the talks.

If you attended, please provide comments on what you liked, were puzzled by and might change in the future.

Jean’s work was a three-hour tutorial on learning models for managing the Agile organization.   She ran three exercises and provided a bibliography of books/resources that we have used here at Rally:

Jean in action at Agile 2010

Jean in action at Agile 2010

In addition to Jean’s talk, I presented an experience report on our use of Plan-Do-Check-Act (PDCA) at Rally.  This report tells a story of our evolution of strategy execution from Gazelles/Scrum to Lean/Agile.

We hope these resources provide you with ideas for scaling your own Agile efforts beyond their current levels.  Again, please comment on the blog with what you got from the materials or the talks.  We want to hear from you on this topic.

Ryan Martens is a tomato grower, founding board member of the Entrepreneurs Foundation of Colorado, and CTO at Rally Software Development.

Jean Tabaka is a wine enthusiast, author and Agile Fellow at Rally Software Development.

There are other conferences that cover Agile software development, but the Agile 20xx show reigns supreme. At nearly 2000 attendees from around the world, this year’s show is happening at Walt Disney World in Orlando.  (It was moved there after the flood in Nashville.) For the first time, three of the major analyst firms (and as a result 5 of  the key analysts who cover Agile and ALM) are attending the conference – Forrester, Gartner and IDC.

Rally coaches, sales and marketing folk at booth setup

Rally coaches, sales and marketing folk at booth setup

As a result of the show’s success, it has become the most significant market rhythm in our industry.  So this week, we announced a few things:

I am speaking tomorrow on PDCA: Moving Beyond Simple Inspect and Adapt. (Thurs 9:00 a.m. in A-1). Other Rally speakers remaining this week are:

Get your Rally cap

Get your Rally cap

  • Former Rally developer turned Rally technical account manager turned Rally coach Chris Browne speaks Wednesday on The Art of the Hackathon (Weds 15:30 – 17:00 in Asia 3).
  • Rally coaches Alan Atlas and John Martin speak Thursday on “Your Team, Your Freedom, Your Responsibility” (Thurs 15:30-17:00 in Asia 3).

Follow the news from the show on Twitter at #Agile2010. Come see us at the booth and get a Rally and Deliver ballcap. Or let us know if you’re not at the show and want us to send you one (send name and address to kcaraway@rallydev.com).

Ryan Martens is an organic farmer, founding board member of the Entrepreneurs Foundation of Colorado, and CTO at Rally Software Development.

On April 21 in Atlanta, the Lean Software and Systems Consortium will come together for its second US conference.  Last year’s event in Miami was “amazing” according to Jean.  So this year, Rally is exhibiting, I am speaking while Jean and Aaron are running the open space on Friday.  The price per attendee goes up by $250 on March 31st, so if you do intend to go, REGISTER now.

At our booth, Rally will be demonstrating its product support for highly-visible Kanban, WIP/Cumulative Flow reports, and cycle-time  metrics. Join Alan Atlas, Jean Tabaka, Aaron Sanders and Craig Langenfeld in our booth.

I will be presenting an experience report titled: PDCA: Beyond Simple Inspect and Adapt. On spring break this week, I’ve been thinking more about the details of my talk. Here is my abstract and outline for those of you who might consider attending:

Lean and Kanban focus on practices of continuous flow of product delivery. Plan-Do-Check-Act (PDCA) is a Lean discipline that moves beyond inspect and adapt of Agile team-level processes.  At a corporate level, PDCA provides guidance for strategy as well as problem-solving work. In 2009, I led Rally’s move to PDCA for the company’s strategy process at both the annual and quarterly levels.  My primary guide was Pascal Dennis’ “Getting the Right Things Done”. In this experience report, I share Rally’s PDCA first year of adoption: where we started, how this impacted our corporate behaviors, and where we are now. I want to share Rally’s story to compel participants to embrace PDCA and get good at it. I ask each participant to come with its organization’s #1 goal and success criteria. I will close with a planning A3 exercise from Pascal’s book .

Outline

  1. What brought me here—background on why I am passionate about sharing my organization’s overall Lean story including the addition of PDCA, A3’s and concurrent set-based development.  This talk focuses on PDCA as the critical step in increasing structure and discipline in strategy execution.
  2. Point of View – Use PDCA to move your planning horizon out and as the principle governing mechanism for organizations in continuous flow.
  3. Benefits — Mature your strategic planning and execution environment to handle the complexity of increasing speed, agility and scale and to gain alignment, pull and innovation.
  4. Where we were and what was not working
    1. The context at Rally was based on a couple of key concepts:
      1. Core Values, Core Purpose, Sandbox and BHAG from Jim Collins
      2. 3 to 5 Quarterly Rocks, success criteria and Scoreboards from Gazelles
      3. Rock team structures  – cross departmental and story based
      4. Facilitated, highly collaborative cross-departmental meeting of 30+ managers and above
    2. What we noticed
      1. Rock work as a second or third job
      2. Wisdom of the Crowds to help fix over-reaction and group think
      3. Too much on the fly, not enough backlog grooming
      4. Highly critical, non-cross departmental initiatives were de-prioritized
      5. ORID process added to keep from jumping too solutions, but the data was not visible enough
  5. What we decided to do about this:
    1. Explanation of PDCA — A brief overview of PDCA in general and then specifically what I used as guidance from the Pascal Dennis book, “Getting the Right Things Done: A Leader’s Guide to Planning and Execution”.
    2. Our initial experiments with A3 process the year prior — Working with our Ops team and product marketing teams on problem solving using real data
    3. First quarter — How we kick-started Rally’s company-wide adoption of PDCA . I describe our “Mountain Team” and their transitional role.
      1. Defining Rally’s True North
      2. Creating our second level tree with current and needed metrics
      3. Socializing these throughout the company seeking feedback in anticipation of our annual and quarterly planning
      4. Started new experiments based on quarterly planning decisions
    4. Next Quarter – Review new experiments, discussed learning and drive A3’s into the planning process
    5. Mid-course adjustment by Mountain team, in middle of the quarter – What we discovered working and not working
      1. The rocks were all dependent on each other.
      2. Had to run Rock of Rock team meetings to steer to a final solution
      3. Coordinated release planning would have
    6. Final quarter – We worked to expand the plan. We took the Mountain team’s True North and feedback to drive our PDCA for Rally’s Annual Corporate planning by:
        1. Taking company-wide feedback into our Annual planning to collaboratively drive cross-department A3 creation around each branch of the tree
        2. Mountain Team retrospective over the course of year 1 that helped create a planning rock team.  The Mountain team’s role as a transition team ended.
    7. Year 2 – Doubling down our efforts to go from amateurs to intermediates —Changing our process to institutionalize A3’s and PDCA as our strategy execution approach:
      1. Quarterly rocks moved to a world of pre-defined from developed on the fly
      2. Quarterly planning moved from ad-hoc based on yesterday’s weather to more programmed based on True North and meeting the target metrics
      3. Strategic planning worked to validate annual True North in the context of long-term planning, shared vision development, cross-boundary collaboration and larger systems
  6. What we learned and what you should do about it
    1. The cycle of adoption is a year, quarterly cycles work to improve the process, but it is hard to make leaps on a quarterly basis.
      1. Year 0 – Introduce Lean thinking (A3 in our case)
      2. Year 1 – Introduce PDCA (Novice)
      3. Year 2 – Invest or abandon (Your choice)
        1. A3 is now the language for problem solving
        2. Making sure we are solving the right problem (aka slowing down to speed up)
    2. Do not have a overall guidance team steering the continued PDCA process – it is owned by the “team”
    3. Putting pressure on the organization to get more clear about our economic models to mature from “Theory-based decision making toward the right solution,” Now “Data-driven decision making toward the right problem”
    4. Where to start – The Strategy A3 an exercise
    5. What is next? – We call it the Innovative or Lean Organization. Seeing large systems, collaborating across boundaries and creating your reality.
  7. Point of View – Use PDCA to move your planning horizon out and as the principle governing mechanism for organizations in continuous flow.
  8. Call to Action – Introduce the language of A3’s through problem solving or Strategy A3’s
  9. Benefits — Help build a company of problem solvers to focus your efforts on the critical few things.
  10. Where I hope you go with this: Great companies build great software, great experiences and work on creating win/win scenarios.
Are there other questions you’d like to see answered in Rally’s experience report on Plan-Do-Check-Act? I look forward to seeing you at Lean SSC.
Ryan Martens is telemark skier,  father,  founding board member of the Entrepreneurs Foundation of Colorado, and Founder and CTO at Rally Software Development.

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.

Slide10Now 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.