Agile Development Blog

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

• True North Example

• True North Exercise

• Strategy A3 Template

• ORID Exercise

• Personal and Corporate Visioning Exercise

• Sample Quarterly Agenda

• Bibliography

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.

Yesterday, the Agile Journal posted their May edition of the online publication with the above focus.  To support their release, they asked us to share our opinion on the topic.  Here is our response:

Ryan Martens: Age of Reconsideration, Reform and Regeneration

The last decade marshaled in a new empirical way of working with increasingly complex, interconnected and highly-critical software-based systems – Agile.  We are entering a period of reconsideration, reform, and regeneration in software, systems engineering and project management.  Agile is working, Lean Software and System is working, and the combination is starting to prove very powerful with regard to throughput and workers.  The benefits of autonomous work, engagement and mastery are driving systemic improvements in our way of working and growing to meet complex challenges of our world.

These results illuminate a future vision that has the potential to expand our current notions of Lean and Agile from software teams and into real organizational agility.  As a result, there is a chance to unite and unify many communities under the guiding ideas of flow, pull, and value.  All of these communities are being drawn in and starting to play well.  These are beautiful days with all the implications to CMM/SEI, Agile, Scrum, Lean/LEI, and PMI/PMBok communities yet to be determined.

In the first half of this decade, look for collaborating across boundaries, seeing larger systems and groups working hard to create their future realities.  Following that period, look for messy consolidation as the winners of this new platform emerge for a new golden age of networked, software product and system development. Together we’ll be focused on the problem domain of global scale difficulties in governance, cyber-warfare, energy, water, communication, commerce, medicine, climate, transportation and nano-technology.

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

Jean Tabaka: Let the System Talk

Thinking about our path with Lean, I’m compelled to draw upon research I’ve been doing in Systems Thinking and, more recently, what I’ve been learning in Systems Engineering.

In Systems Thinking, we recognize a world of system archetypes based on the dance of balancing loops, reinforcing loops and the outside agents that may cause them to transition. Lean, as a system of thinking, has certainly responded to systems that rely too much on take-make-waste. A set of negative reinforcing loops: the more you waste the less you have to take and make. Outside agents, the scarcity versus abundance of materials, has led us to Lean. Lean principles and practices create a positive system wherein the more we reduce waste the more value we get which in turn reinforces more waste reduction. It is a reinforcing loop propelled by continuous improvement.

Recently, I attended the Lean Software and Systems Consortium’s 2010 conference in Atlanta. What a revelation. From James Sutton’s talk on Lean Systems Engineering, I added new vocabulary that I think will become critical to Lean’s future.

Will Lean be our best source of practices and principles in the future? That depends on what will be guiding our systems:

• Scarcity
• Abundance
• Desperation
• Conformity

Once we have clarity about what guides our system, we can understand more about the system in which we are operating:

• Simple
• Complicated
• Complex
• Chaotic

Lean has steadfastly addressed pressures of scarcity and hence a system of complexity. That brings me to Dave Snowden’s work captured in Cynefin, a Welsh word he has used to describe a framework of problems, situations and behaviors in these four systems. For our world of complex systems, Lean provides the perfect high-level thinking for what we must embrace: emergent practices informed by, as Snowden puts it, “sense-making”

As we move into the next 10 years of Lean, I fervently believe that our sense-making must inform us about what supports emergence that responds to complexity. The practices will follow. For now, let us concentrate on the systems in which we operate, what outside agents or pressures are guiding our systems, and how we can best continue to formulate and hold dear the practices that will naturally emerge.

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

Last week, 10 of us from Rally product development, sales and coaching attended the Lean Software and Systems Consortium’s 2010 conference in Atlanta.  For me, the learning highlights of the conference were in the Systems Engineering track  led by James Sutton. To kick-off his talk on Lean Systems Engineering, James used a number of compelling stories around different systems and what guide them.  As part of his introduction to systems, he played this hilarious Dave Snowden video about how you plan or act based on one of 3 systems in which you might find yourself -- Chaotic, Ordered and Complex.

David Snowden -- Cognitive-Edge -- Ways to Plan a Party

James, a Systems Engineer, Principal with Lockheed Martin, is an invested member of the Lean SSC board as well as a technical advisory member.  He is the deepest expert that I have ever met in the field of systems engineering. And he has a wonderful gift for bringing multiple resources to bear in helping people understand and care about systems. For a Civil Engineer and Computer Science major like myself his talk and track were the definition of a prop-spinning geek nirvana.

Systems are guided by the pressures that form them

The point of view that James imparted on us was to understand that there are fundamental systems in which we operate. They are not value-based; one is not better than the other. They just help us set context and inform us about the world around us. Why should we care about this? How you approach your product and project development depends on which system  you find yourself in. And, as it turns out, the system you find yourself in is largely guided by one of four compelling pressures. That is, you will recognize the system in which you operate based on what is driving you to act.

There are four fundamental pressures that guide us: abundance, scarcity, desperation, or conformity. And each leads to a different system context. To illustrate this, James led us through the story of four different nations following the second World War.  Each nation, responding to different drivers, led to advances in different types of systems management approaches in use today.

• United States -- Abundance -- Systems Engineering

• Japan -- Scarcity -- Lean

• England -- Desperation -- Chaos Theory

• USSR -- Creativity and Conformity -- Patterns of Inventiveness
  

The Four Systems

Given this sense of what guides particular systems, James explained that we live in a world of four fundamental systems: Simple, Complicated, Complex, Chaos.

Cynefin

Once you recognize what system you are in, you discover what principles and practices will best serve you in that system. But systems tend to not be static. So, James presented what agent or pressure might cause you to move to a different system and therefore what tools and practices would guide your thinking and actions for transition.

For instance,  if you are in a Simple system and are moving into a Complicated system, Lean Manufacturing and Analytical Systems Engineering are your best tools and guides. If, however, you are in a Complex system verging on Chaos, you’ll work best relying on the perspective originated by Dave Snowden: Cynefin, the Welsh word for “the place where you hold multiple things.” Cynefin serves Complex systems well as it emphasizes emergent behaviors and, what Snowden refers to as “sense-making.”

The history and vision from this talk became almost a grand unifying theory for me. It all made great sense. If you are a  systems engineering fan, do not miss the recorded version of this talk when it becomes available.

Thanks Lean SSC

While 6 speakers and several attendees from Europe were prevented from attending the conference due to the Icelandic volcanic ash cloud, the Lean SSC rolled with the punches and pulled off an excellent event. The folks able to attend and the over 40 sessions offered created an electric buzz both in the air and on Twitter. Given the caliber of sessions, hallway discussions, and Open Space,  I am sure there will be many posts that emanate from attendees. And no doubt new ideas will be growing that were nurtured by the conference. Kudo’s to the Lean SSC board for creating a space for this excitement and emergence.

About the Authors:

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

I just wanted to take this opportunity to thank each and every one of you who follow the Agile Blog.

Jean and I have had a great time writing these posts over the last year, and we are humbled by the way you’ve responded.  After a few years of casual, intermittent posting in our Agile Commons community, we jumped off the deep end into blogging this year by hatching out this site and our Engineering Blog.

We are truly grateful for how you have helped us learn and grow: for every comment, every tweet, everything that you have shared with us.

And we are hopeful that the learning has been a two way street. That is, whatever topics or ideas we posted in the blog that particularly resonated with you, we are honored that you invited us into your 2009 professional journey. In fact, we’d like to see your comments on what you found particularly useful or engaging in this past year. And we welcome your suggestions for topics in 2010.

We look forward to continuing this great conversation in 2010.

Thanks and Happy Holidays!

For 2010, lets find ways to focus on teaching our craft and growing the world of skilled software development professionals instead of trying to figure out who is “right.”

I believe much of the “Escalation” that Jean is seeing was correctly titled by Regina Mullen as a battle to be “right.” (see and read Escalation is Killing Agile – Can We Please Stop It? and Escalation is Killing our Healthy Conflict in Agile). That behavior focuses on carving up the pie instead of growing the pie.   There has been so much added to the field of software development methods, tools and techniques from the guiding ideas of Agile.  Now is not the time to stop and eat.

For me, 2010 is about continuing to grow the Agile software development pie’s reach and innovations.

I believe one of the key fixes to the problem of escalation can be found through increased professionalism and certification in Agile. By raising the bar through “difficult and skills-based certification,” as Brian Marick and the board at the Agile Alliance described, we can advance the Agile discourse through :

• a defined a bar that is deep in skill, knowledge and practice
• a significant enough bar to engage College and University study and examination
• research and curriculum that explore the tough questions in a scientific method
• development of more flexible or “T” shaped individuals that can see and work beyond silo roles.

With this back-drop, I am motivated by the notion of creating a  A Community of Thinkers,:

I am a member of a community of thinkers and I believe that communities exist as homes for professionals to learn, teach, and reflect on their work.

A Community of Thinkers creates more leadership in our profession. I see the expanding certification efforts in 2010 as great steps in these directions:

• Lean Software and System Professional – new certification emerging
• Agile Developer Certification – that is also emerging
• Certified Scrum Practitioner – especially as it intertwines with the PMI’s Agile Community of Practice

I encourage everyone in our community to figure out how to put energy toward one or more of these efforts.  The benefit of actively learning, teaching and reflecting on our work should lead us all to expanding civil dialogue that works to understand all points of view and keep expanding our thinking.  Thus broader education and difficult certification helps create a “Community of Thinkers.”  And, a Community of Thinkers will create a virtuous cycle of win/win and thus a larger pie for all.

That is my hope for 2010 in our profession.

About the Author: Ryan Martens is a happy father,  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.

Last week at Agile 2009, I attended a great panel discussion with previous winners of the Gordon Pask Award.

For those unaware, the Agile Alliance states that “The Gordon Pask Award recognizes two people whose recent contributions to Agile Practice make them, in the opinion of the Award Committee, people others in the field should emulate.”

Rally’s newest Coach Aaron Sanders facilitated this 90 minute sessions in three blocks: (1) Q&A with the award winners, (2) Q&A with the audience and (3) reflections by the award winners.

Here are some of my favorite insights shared by the panel:

Laurent Bossavit

• “Situational Learning concepts are important as people move beyond agile-by-the-book”
• Here to drive more innovations in “Diffusing agile into the organizations quickly”
  

Jeff Patton

• I am focused on coaching as agile has moved beyond selling into “How to do it.”
• Next up – practices for the product/business side to help them build “just enough”
  

J. B.  Rainsberger

• “I am interested in complex selling concepts as agile is trying to spread up.”
• BDD is just TDD done right (unit and acceptance/story test driven development) – pushes the focus to design and drops the word TEST – this is good.
  

Bob Payne

• Chicken’s and Pigs hurts when trying to create “One Team.”
• What’s Next – Create an “Agile Philanthropy revolution”

Arlo Belshee

• Us versus them – beat them is a human fear response
• Middle managers are often scared
• People who are advocating more then asking – are hard to build trust with
• Next for me is “Whole Company” and Governance strategies
  

  
  

  (Last year’s winner Kenji was not at the conference, but you can read a great interview with him on Aaron’s blog -  Interview with Kenji Hiranabe – 2008 Pask Award Winner – it gives you more of the flavor of the actual session)

It was great to see that they all had meaningful answers to the question regarding how the award had affected them.  Three cheers to Brian Marick for idea and Three Cheers to the awardees for making something out of it!  The highly interested members of the audience included Jean Tabaka, Esther Derby, Rachel Davies and about 20 other folks.

If you have not been to an Agile Conference, this kind of intimate gathering is common and why so many people come back year over year. It’s sessions like this that have helped Agile 2009 become such a wonderful mix of new and old, small and large as well as academic and professional.

I look forward to seeing Simon Baker & Gus Power from the UK and David Hussman, the newest Gordon Pask award winners, using their award to extend their influence on the industry.  Congratulations gentlemen and Congratulations to the team of volunteers that put on another strong Agile Conference.  See you in 2010!

I’ve written previously about my allergic reaction to process maturity models for Agile development. Based on 5 years of empirical feedback being a part of or watching what  succeeds versus falls back, I do not believe their is a “cookbook” for Agile adoption. Of course, the question then becomes:

If there is no cookbook, then what is the best approach to succeed with my Agile adoption?

Enter the crib sheet for Flow-Pull-Innovate, which is a guidepost for the key transitions in Agile organizations based on proven bottom-up success. Because the hurdles and challenges are unique for each organization and code base, this is not a prescriptive approach. It’s a framework to thinking about how to approach Agile adoption incrementally and iteratively and is essential to establishing quick wins that create a virtuous cycle of success to keep the ball rolling.

The three phases of Agile maturity are based on work by Jim Womack in his book Lean Thinking.  However,  Jean and I thought it was appropriate to substitute “Innovate” for “Perfect” in Agile organizations.  In IT/high-tech, it seems more about continuous innovation than the ultimate pursuit to “resource” efficiency.

Getting Over the Hump - Critical Step #3

Over the past 5 years, our focus at Rally has been getting our customer’s successful at Step 3, which we call Multi-Team Program Pull. (See our whitepaper on Leaning IT and moving to Program Pull.)

We focused on this step because at Program Pull, whole software products or major IT systems come to market typically 50% faster, according to the QSMA studies included in the Agile Impact Report. However, in this tough market and with mainstream Agile adoption, more and more organizations are adopting Agile at scale, making it important to light the path beyond Program Pull and into Organizational Pull and Organizational Innovate.

What do think of the crib sheet for Flow-Pull-Innovate? Do you agree with the key metrics? Are these failure signs you’ve experienced? Would your organization be willing to stand behind items in the commitment needed column?

About the Author: Ryan Martens is a trail runner,  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.

In the last couple of months, IBM (via Scott Ambler) has blogged, hosted webinars and talked to the media about an Agile process maturity model (APMM).  I am sure this will hit a new height today with the start of the Rational Users Conference and the release of the e-book.  I have been asked to comment on this work by a number of press and analysts.  Since my perspective will be published shortly, I thought I would go on record.

IBM splashes its way into Agile development

As the Agile market grows and takes hold in truly mainstream audiences, everyone is looking for easy, step-by-step guides to smooth Agile adoption. IBM is proposing one option under the name “Agile Process Maturity Model.”  I think it is a nice marketing strategy for selling IBM’s Rational Team Concert products to companies that want to adopt the Jazz platform, copying their 90’s success with RUP.  But I don’t believe it is actually an Agile process maturity model, and further, Agile doesn’t need one.

IBM’s proposal for an Agile Process Maturity Model

Scott says, “The goal of the APMM is to help categorize and understand agile processes, not to rate your adoption level (the CMMI Defined approach can address that need).”

He continues, “Unfortunately, the term ‘maturity’ is a loaded one within the software process realm, not the least because of the Software Engineering Institute (SEI)’s Capability Maturity Model Integration (CMMI). A lot of good work has been done to show that agile and CMMI can be applied together, and I look forward to seeing that strategy come to fruition. However, where the goal of the CMMI is to provide a framework for software process improvement the goal of the APMM is much more modest – it merely strives to define a framework which can be used to put the myriad agile processes into context. In short, the APMM and CMMI are orthogonal to one another…” 

I am confused by the title and the orthogonality, so let’s peel the onion on this one.

What is a process maturity model?

The origins of process maturity models come from the manufacturing industry, but the software version was created in the 1990’s by Carnegie Mellon’s Software Engineering Institute (SEI). It is well known as three Capability Maturity Models – CMM for software, CMM for people and CMMI.

If you read Watts Humphrey’s work, you will see this is a management framework that measures the level of discipline of  your organization. In essence, organizations that are certified Level 5 have implemented continuous improvement and have the disciplines and practices in place to effectively manage large complex projects with effective controls.  The framework does not say anything about how the software should be developed.  I make no claims to being a CMMI expert, but you can read a few of the “CMMI agile” search results to see how they work together.

Though not the stated intent of the framework, it has been closely associated with waterfall development and used to defend heavy process approaches. I disagree with that belief and prescribe to Jim Collin’s model of blending  discipline and agility together to move from good to great. I think the CMM framework is a great checklist for organizations measuring their level of discipline… and we don’t need another one.

The 3 levels of IBM’s APMM

Scott’s APMM post describes three levels:

1. Core Agile Development
2. Disciplined Agile Delivery
3. Agility at Scale

I struggle to see how these three labels or the supporting details provide a framework that helps categorize and understand Agile processes.  These titles grow in scope and scale, but do not speak to increasing agility.  (Faster cycles, less waste, less work-in-progress, more value.) When you look deeper, it smells of a cookbook of when to apply processes and tools from IBM.  That is fine, and I agree customers need this. However, I would argue this should not be used to guide companies in their Agile adoption.

By mashing size, scope, increased agility and disciplines on one scale, the APMM does none well.  In addition, it will lead to amateur implementations where continuous improvement mentality never sets in. Where adopting scaling software agility is thought to be just a transition from A to B.  To me that thinking is very limiting and will lead to gains followed by declines.

IBM in the Agile space – all good

I am thrilled with IBM’s entrance into the Agile space with their Jazz platform and related products – really. When I was at BEA/Weblogic, I can tell you that we did not have a market for Java Application servers until the industry’s gorillas, IBM and Oracle, entered for real.

During this year, Jazz and its supporting products will actually manage the workflow of projects in a way that works with Agile development instead of against it. This is huge change from the ALM 1.0 point products that actually reinforced the silos and phased approaches that created queues, caused hand-off delays and kept quality as an after-thought.

The IBM gorilla in the software development space will make the Agile sea rise and help break down major organizational barriers to bringing the benefits of Agile practices and tools to the mainstream development community.

There is no cookbook for adopting Agile

I believe that enterprises need an adoption model that helps them balance discipline and agility in an incremental fashion that creates incremental success and fuels continued investment and improvement. The enterprise Agile adoption model Jean Tabaka and I have synthesized is based on Lean concepts and is rooted in Deming’s work, just like Watts Humphrey and CMM. What Jean and I present in our whitepaper titled “Leaning IT: Moving to Program Pull” is how to move up the adoption curve of Agile by learning quickly,  maturing before scaling and working incrementally. 

This transition planning framework focuses on attaining benefits of agility by moving to lean states of flow, pull and ultimately the perfection of continuous innovation before adding the disciplines necessary to scale.  It discusses the general steps, but does not prescribe a change approach to organizational, technological, process or strategy transitions.   Your approach is dependent upon your corporate and technological situation.  We recommend an iterative approach, facilitated by experienced coaches and peer support.

What does the Agile community need from IBM?

Mary and Tom Poppendieck’s new book called “Leading Lean Software Development” (out soon) has tremendously strong stories, models and insights from bringing lean concepts to software. In chapter six,  they highlight a success story from working on lean with Sue McKinney at IBM.  This success story, along with the Eclipse success stories, are critical for IBM to be telling the market regarding the impact of Agile and Lean in the large inside IBM.

In 2008 and four years after IBM started developing Jazz, we talked to IBM about integrating Rally’s award winning Agile Lifecycle Management solution onto IBM’s collaborative development platform, called Jazz Foundation.  They said no, you have to wait until the GA release of Jazz. This would be a similar integration that we provide to Microsoft Team Foundation Server for managing code check-in’s and automated builds with a slick interface into the IDE.  I am hopeful that IBM will GA the 1.0 version of the Jazz Foundation for partners to actually integrate with.  They are saying all the right things on the Jazz.net site, here is hoping for some positive news at this week’s Rational User’s Conference.  Finally, I am very excited about IBM’s global dialogue on Building a Smarter Planet. IBM needs to do a better job telling the story about how software agility is a critical component to building that sustainable planet. (It was nice to see the smarter planet splash at the front of the ebook, but it still represents a huge missed opportunity.)

What do you think? Does Agile need its own process maturity model?

Again, I was surprised by the title of IBM’s Agile Process Maturity Model and hope they will consider changing it before more marketing dollars are spent.  It does not improve on the CMM, nor in my opinion does it help CMM certified companies adopt Agile.  I assume IBM has a huge role to play in helping those CMM certified companies add agility and innovation to their highly disciplined organizations. If they don’t, we are glad to help today.

About the Author: Ryan Martens is a happy father,  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.

As geeky as it sounds, I love learning. When I was first exposed to the world of organizational learning back in the 90’s, I picked up a couple of handy phrases that I chant on weekly basis:

• Learn – Teach – Learn
  
• No Theory, No Learn
  

These phrases capture two of my mental models on organizational learning. Mainly that it is an iterative cycle, only comes through sharing, and requires reflection and measurement on your theory to learn. With that in mind, we frequently open our doors to our customers to Learn and Teach.  They observe our stand-ups and planning meetings and we discuss how Agile development has infiltrated not just our development team, but our entire business.  I always try to ask them – “What is your Theory?” before they come.

Creative Commons Kathy Sierra - Click to view her blog post on the topic

What’s Your Theory?

Many organizations are simply happy to take the first step toward the smooth and continuous flow of Agile development. But what I love about working with many of our customers like Pinnacol Assurance is their desire to go beyond amateurism, what Kathy Sierra shows as the road to becoming an expert.  Amateurism is not enough; they want to become experts by fully adopting Agile throughout their organization and through a continuous improvement process.

At our last release planning session in April, members of the Pinnacol’s IT team participated right alongside our internal team. Wednesday of this week, members of Pinnacol’s leadership team shared in our company-wide rhythm of daily  stand-up meetings, rotating through a variety of stand-ups from the dev team to IT to marketing.

How about a Learning Journey?

The goal of their trip was bringing mental models from outside of Pinnacol into their organization. I love that approach and it’s one we use ourselves at Rally. If we see a company doing something particularly well – whether it’s supporting their customers or hosting an out-of-this-world event – we ask to visit their company, shadow them for a day or two, and get first-hand knowledge of their success. It’s one of the best ways I know to quickly learn a model in a very hands-on way and almost immediately translate that into success at your own company – all without reinventing the wheel.  Otto Scharmer who developed Theory U calls these trips – Learning Journeys.  They are the first step to help you see what you do not know and getting you to open up and learn as a team.

Pinnacol has been very successful at attaining the benefits of Agile in flow inside of IT, but they are already looking above and beyond. They brought business representatives and operations leaders to share and learn about increasing agility in a larger, enterprise-wide context. I am really looking forward to hearing more about Pinnacol’s path to fast learning. You can read about Pinnacol’s adoption of Agile and Rally in the case study.