As a part of our series on Scaling Agile to the Strategic Level, I have invited our product lead on this project, Catherine Connor, to tell us about her experience in creating Project Stratus. Thank you for the great work and help on this series Catherine.
Project Stratus was conceived over a year ago from numerous customer discovery interviews geared at understanding the challenges of strategic planning with agile execution. From these interviews we started to form an idea of what an agile strategic planning tool could look like, but we also knew that we would need to do serious customer validation before getting to productize a solution.
We’d already selected a disciplined approach to customer validation based on The Four Steps to the Epiphany – Successful Strategies for Products that Win by Steven Blank. Although the book focuses on startups, many of the ideas, such as diligently conducting customer validation and creating a sales roadmap (i.e. a repeatable process to sell your product) can also be applied to new products in existing compagnies. The basic premise of Blank’s approach is that if you solve a problem for customers (called “earlyvangelists”) who are so acutely affected by that problem that they are willing to build a solution themselves, you are more likely to deliver a product that will solve that same problem for many more customers.
Project Stratus was drastically accelerated in April 2010 at the LeanSSC conference in Atlanta, when one of our customers unveiled the agile product portfolio scheduler application they’d built to solve their own strategic planning needs. Not only did the application visualize where we were heading, it also happened to be built on the Rally Platform. We’d just found our first earlyvangelist.
Four months later, at Agile2010, we privately introduced Project Stratus to a handful of industry analysts and customers to gauge their reaction. Based on their overwhelming excitement, we proceeded in identifying additional earlyvangelists from past customer interactions. An earlyvangelist is like a P1 defect, when you find one, you know right away. These customers are so excited to see a provider like Rally think up a commercially supported solution to the problem they have been trying to solve themselves, they are anxious to guide you, and some are even irritated by the fact that the product is not out yet; when all along we’ve been thinking not to deliver such a thing! I could tell when I first engaged with Paul, Dale, Nina, Christophe and others, that they would be partners in shaping Project Stratus to become a valuable product. The beauty of Blank’s technique is in its reciprocity. We, the solution provider, get to build a product that solves real needs, earlyvangelists get to shape a supported solution to replace their manual solution, and customers get to benefit from their peers’ expertise.
With earlyvangelists on hand, we sat down to define the set of hypotheses to validate. This is an important step to ensure that interviews provide meaningful outcomes. Nothing is more deflating than spending an hour with a customer only to find yourself with no good answer to “exactly what did I learn from this call?” Listing hypotheses is also a great way to communicate to yourself and others in your company what you are trying to find out and what you are purposefully setting aside for another time. This is very much like “theory-based decision making”, one of Rally’s corporate core values.
Since August, we have been incrementally evolving Stratus, one weekly build at a time, diligently validating our hypotheses one at a time. Earlyvangelists’ real-life experiences combined with our coaches yearning to apply agile and lean principles to the strategic level are informing the direction of Stratus. I feel really good about where Stratus is going.
As an agile product manager who has seen several projects being productized prematurely, I am truly enjoying following Blank’s rigorous Customer Development approach and definitely would recommend it to my product manager comrades. You do need executive support which thankfully Rally provides me. Following Blank’s technique is no small feat however, it is hard and diligent work with no guaranteed productization plans until you pass his customer validation final exam: “you have proven you have understood customer problems, found a set of earlyvangelists and delivered a product that customers want to buy, developed a repeatable and scalable sales process and demonstrated you have a profitable business model.” Then, and only then, will we graduate to Blank’s customer creation step, aka the delivery of an official Rally offering for Strategic Planning.
The customer validation step for Project Stratus is going full steam. We welcome more earlyvangelists to partner with us in this exciting endeavor. The more input we receive, the more valuable the product will be. If you have strategic planning challenges and a passion for applying agile principles for solving them, I invite you to reach out to us at stratus@rallydev.com. – Catherine Connor
The work done by Steve Blank on this method is fantastic. In addition to Project Stratus, I have used it with our large on-premise customers and with TechStars companies in order to keep from leaping to conclusions and trying to by-pass the customer creation stage. I hope many of you can empathize with the discipline required to do both of these things in the world of product development.
Catherine Connor is a Product Manager at Rally SoftwareDevelopment. She focuses on the product manager role in our customers’ agile transformation endeavors.
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.
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.
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
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.
Point of View – Use PDCA to move your planning horizon out and as the principle governing mechanism for organizations in continuous flow.
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.
Where we were and what was not working
The context at Rally was based on a couple of key concepts:
Core Values, Core Purpose, Sandbox and BHAG from Jim Collins
3 to 5 Quarterly Rocks, success criteria and Scoreboards from Gazelles
Rock team structures – cross departmental and story based
Facilitated, highly collaborative cross-departmental meeting of 30+ managers and above
Highly critical, non-cross departmental initiatives were de-prioritized
ORID process added to keep from jumping too solutions, but the data was not visible enough
What we decided to do about this:
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”.
Our initial experiments with A3 process the year prior — Working with our Ops team and product marketing teams on problem solving using real data
First quarter — How we kick-started Rally’s company-wide adoption of PDCA . I describe our “Mountain Team” and their transitional role.
Defining Rally’s True North
Creating our second level tree with current and needed metrics
Socializing these throughout the company seeking feedback in anticipation of our annual and quarterly planning
Started new experiments based on quarterly planning decisions
Next Quarter – Review new experiments, discussed learning and drive A3’s into the planning process
Mid-course adjustment by Mountain team, in middle of the quarter – What we discovered working and not working
The rocks were all dependent on each other.
Had to run Rock of Rock team meetings to steer to a final solution
Coordinated release planning would have
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:
Taking company-wide feedback into our Annual planning to collaboratively drive cross-department A3 creation around each branch of the tree
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.
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:
Quarterly rocks moved to a world of pre-defined from developed on the fly
Quarterly planning moved from ad-hoc based on yesterday’s weather to more programmed based on True North and meeting the target metrics
Strategic planning worked to validate annual True North in the context of long-term planning, shared vision development, cross-boundary collaboration and larger systems
What we learned and what you should do about it
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.
Year 0 – Introduce Lean thinking (A3 in our case)
Year 1 – Introduce PDCA (Novice)
Year 2 – Invest or abandon (Your choice)
A3 is now the language for problem solving
Making sure we are solving the right problem (aka slowing down to speed up)
Do not have a overall guidance team steering the continued PDCA process – it is owned by the “team”
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”
Where to start – The Strategy A3 an exercise
What is next? – We call it the Innovative or Lean Organization. Seeing large systems, collaborating across boundaries and creating your reality.
Point of View – Use PDCA to move your planning horizon out and as the principle governing mechanism for organizations in continuous flow.
Call to Action – Introduce the language of A3’s through problem solving or Strategy A3’s
Benefits — Help build a company of problem solvers to focus your efforts on the critical few things.
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.
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.
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:
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.
I’m offering this follow-up post as a means to provide an overall response to all these great comments. I want to add some further background on the “escalation” topic and some more of my personal conviction around it. Specifically, I’d like to provide some insights into delayed feedback, the need for conflict, and how to “show up”, all without escalation.
In one part of the comment stream, I heard and felt the call for an effort to get to the root cause of such deep-rooted assumptions.
According to the Systems Thinking Toolbox from Pegasus Communications,to break an Escalation structure, ask the following questions:
What is the relative measure that pits one party against the other and can you change it?
What are the significant delays in the system that may distort the true nature of the threat?
What are the deep-rooted assumptions that lie beneath the actions taken in response to the threat?
So, in our system of sharing information in the Agile community, we have to ask, “Are we setting up a dynamic that pits us against one another?” If this is true, then we have to ask, “How can this be addressed and still ensure that we share insights?”
Guided by Systems Thinking, that means we need to check in with: what is distorting our communications and what might our deep-rooted assumptions be that would have us act as we do?
Here is an example:
I created a delay in feedback by my not responding to posted comments. I believe that created assumptions around what I may or may not have intended in the post. I think some individuals thought I had written the post pointed specifically at them. Faster feedback would have helped quell that assumption.
I was writing about, and continue to write about, the Systems Thinking Escalation archetype and how I see it in our community. I was and am looking at a dynamic not at an individual. Escalation is NEVER about an individual; it is about the system in which blame is occurring and allowed to continue. I am fearful that blame and the win/lose game are in our system and that is what I do not like and I want to address.
Some of the comments to my post seemed to indicate that I was anti-conflict. Far from it! In studying the inner workings of high-performing teams, I have often referred to Sam Kaner’s model for participatory decision-making. Conflict is a must.
In this model, Kaner insists that, to get to high performance we must bring forth conflict to discover the best informed decisions. Divergent ideas must be invited. Divergent voices must be heard. Divergence must be allowed to just be. That is, don’t just jump to conclusions. With enough time and patience around divergence, we can then move toward informed convergence.
Conflict in this context is dialogue. It seeks insights. It invites greater and greater participation. I also want to emphasize that in this context of dialogue and non-escalation, our purpose is to engage in forward thinking. We let go and we look forward. And as we look forward, we let go.
So, as a member of the Agile community, my interest in expending energy in discussions is to seek insights, encourage divergence, and discover convergence as it emerges. All of these practices help and encourage me to create more and more forward thinking. If this is not occurring in our community, then we are not getting enough for the energies we expend. If in our community we really “must win” in order to “be heard”, we are stuck in an “Escalation” archetype. And, that means we are all trapped on an up escalator to nowhere.
What could any individual do to break an escalation pattern in a system? Create energy around your insights and share them without a need to apply win/lose stakes. Stop expending energy to refute others.
Here is a simple formula for bringing your viewpoint to bear without escalation:
Show up. (Be willing to be engaged.)
Find out what has meaning to you. (Be willing to be honest about your perspective.)
Tell your truth. (Be articulate about your insight without attacking or assigning blame.)
Let go of what happens. (Be courageous enough to allow others to agree or disagree.)
I believe this formula provides guidance on how to remain forward thinking, remain open-minded, and remain engaged.
I have some more mental models I want to offer here. But they will wait for another post.
Thank you in advance for your considerations, insights, and comments.
RallyDev.com
The customer validation step for Project Stratus is going full steam. We welcome more earlyvangelists to partner with us in this exciting endeavor. The more input we receive, the more valuable the product will be. If you have strategic planning challenges and a passion for applying agile principles for solving them, I invite you to reach out to us at stratus@rallydev.com. – Catherine Connor
I’m offering this follow-up post as a means to provide an overall response to all these great comments. I want to add some further background on the “escalation” topic and some more of my personal conviction around it. Specifically, I’d like to provide some insights into delayed feedback, the need for conflict, and how to “show up”, all without escalation.
