I love the leverage you get when strategic planning is working well.
At Rally, I run our strategic planning process with help from Jean and others in our organization. We have experimented with many agendas, internal facilitators and guests, but we’ve found the most success when Jean facilitates these meetings and I lead them. It is challenging work and we try really hard to create a setting that leads to magic and allows the best to emerge from the group. As you might imagine, if you know Jean and me, we never stop trying to improve the process. In addition to our desire to keep advancing, the context at Rally keeps changing. Whether from growth, hiring, market changes, maturation of agile, or changes in customer demographics; our overall setting for strategic planning keeps shifting. It is a difficulty that we wrestle with, but knowing it is ultimately unsolvable, we have learned to embrace the dance.
I do not recall what was the chicken and what was the egg, but we started working on strategic agile topics last year and it launched two efforts and blog series: N Levels of Planning, and Scaling Agile to the Strategic Level. In this post I am bringing the two series together to explore tooling the process of strategic planning in an agile context with Catherine and Ronica. Larger Rally customers and past employers have shown that managing a strategic plan in a spreadsheet creates vacuums. Through our efforts at Rally, we have learned that trying to maintain strategic alignment with our development teams without a single source of record to visualize variances on plan versus actual is challenging. (HINT: Slides are not a very capable source-of-record :)
It is difficult to integrate big-bang, waterfall planning/stage-gates and traditional budgeting with effective agile teams who keep learning and adjusting. It is even more difficult to stay on course as an agile organization without effectively closing the feedback loop on roadmap/strategic planning efforts. In the first instance, it is easy to simply be driven by a naive plan. In the latter, it is easy for the development effort to drift apart from the goals and direction.
These well-validated difficulties led to the birth of Project Stratus and the N-Levels of Planning efforts at Rally. These two initiatives are intended to help increase the effectiveness of strategic planning in an agile context. They are helping us balance the need for forecasting delivery while also benefiting from the fast feedback that flows out of agile teams and programs. We like to talk about this process as steering realistic roadmaps to maximize the delivery of value.
To explore this problem space, we diligently carried out discovery and validation exercises that led to a working application (Project Stratus) and a service offering (Agile Strategic Planning) that we use to ensure the delivery of a Whole Solution. Through our customer interviews, we found that the most common strategic planning solution when doing agile development is a strategic planning person holding the plan of record in an Excel spreadsheet. This spreadsheet holds some form of a roadmap of releases, programs and resource allocations. It is updated on a regular cycle, typically quarterly. However, two major problems exist with the spreadsheet approach.
The plan is outdated as soon as the work starts because there are two sources of data; one for planning and one for tracking progress
Planning in a vacuum happens as correlating the empirical data into a highly customized spreadsheet leads to outdated data which tends to erode trust
As a result, this most common solution is horribly disappointing with human translations that lead to over-aggressive estimates and/or status updates progress reports. Bringing agile values into this faulty process will shorten feedback loops and bring real data effectively into the cycle.
In exploring the space, we are discovering multiple ways that organizations manage the strategic planning process. As we are still making sense of these patterns, it is early to report on our findings. However, one approach does stand out.
The model articulated in Dean Leffingwell’s newest book, ”Agile Software Requirements: Lean Requirements, Practices for Teams, Programs and the Enterprise“ is clearly one of the patterns of agile strategic planning. You can see a snapshot of this method on his blog, but if you really want to learn it, you should get his book. It is a clear articulation of how to manage your strategic priorities as series of releases. The book breaks the problem into three agile requirements management areas: the team, the program and the portfolio. The beauty of this approach is how it trains all levels of product owners, product managers and portfolio managers to run in agile unison. Dean developed this model starting with the teams and working systematically up through the enterprise portfolio level (ie bottom to top). And, importantly, Dean worked this iteratively through a number of his consulting customers over the past decade (see the Big Picture section of his blog to the incremental progress laid out over time).
In addition, in Agile Software Requirements, Dean has described a “business epic kanban system” which he uses to make the work in process visible, understand the state of epics as they transition to development, and to get the portfolio planners on a similar agile page as are the agile development teams. He and a number of our customers have used this system effectively in a number of large enterprises, so we know it makes a good starting model for portfolio/strategic planners who run portfolios as a sereis of releases.
As a result, this model of strategic allocation and roadmap planning is proven to work well for agile teams that ship code series of releases. Here is Dean’s model from that book and his web site.
Big Picture: Scaled Agile Delivery Model by Dean Leffingwell
We have a number of customers making very good progress in developing strategic roadmap steering capabilities using this approach and Rally’s Project Stratus. If you are interested in this approach paired with Stratus, consider contacting Dean or Ronica, our services owner, directly or through your Rally Account Manager. (See Ronica’s contact information below.)
We will continue to explore hybrid waterfall/stage-gate, other hybrid agile (scrum/kanban), and continuous flow techniques for strategic planning in the coming months. Please stay tuned.
Finally, to fully explore the problem and solution space, we created the RallyON conference. We will host this conference in Boulder on May 10th and 11th. We limited the conference to 150 attendees and it has sold out quickly to our most active users and champions. Don’t worry if you are not attending as there are a number of ways to engage in the conversation including:
Responding to this post with your challenges, ideas and comments on strategic planning in an agile context
Sharing your opinion or challenges related to topics that Rally Coaches, Technical Account Managers and Product team members are posting for the conference on our new Coaching Blog.
Posting your agile, scrum, kanban and xp questions on pm.stackexchange.com or programers.stackexchange.com to have a the community formulate answers to your questions prior, during and after the conference. We will have expert users from both of these stackexhanges on site at the conference to help us leverage this rapidly growing community.
No matter what choice you make, please tweet your efforts with the #RallyOn11 hashtag. It will get the attention of the Rally coaches, technical account managers and product team, in addition to all the physical and virtual RallyOn attendees.
Please join us online before during and after the conference to explore the topic of strategic agile.
Special Thanks to Catherine Connor, the lead on Project Stratus at Rally and Solutions Evangelist Ronica Roth, who owns our Services strategy at Rally.You can reach Ronica at ronica[at]rallydev.com
Did you know that some people pronounce Rally and Raleigh the same? It is also a tongue twister to say them together. These are two of the more esoteric things I have learned in the eighteen months following our acquisition of 6th Sense Analytics.
Five Fingers for a great Q2 and great North Caroline BBQ
This is in the forefront of my mind following a recent trip to Rally’s Raleigh-Durham, North Carolina office. After Agile 2010 in Orlando, Jean Tabaka and I visited our largest remote office in their new digs. We were there to help share in their Q2 Celebration event. It was a real pleasure to see that office filling out and becoming whole. (more on the cupcake thing below)
Becoming whole is so critical for a remote office and for an Agile team.
When I was working at BEA, I was part of an amazing machine that really knew how to acquire companies. BEA learned from Cisco about how to do this right and how to balance autonomy and culture to create a healthy soul for an office away from the corporate headquarters. Typically, BEA moved one or two folks to the remote facility to become active managers and help provide local leadership. These embedded people helped make the transition smoother by transferring norms, values and informal networks of the existing organization to the newly acquired team. In fact, BEA would not move forward with an acquisition deal unless it had management bench strength who were willing to move and play that role.
We compensated without management bench strength.
In Rally’s case, we did not have that management bench strength to move folks from Boulder to Raleigh. As a result, we lived through what some folks on the team called “open wheel racing.” We had a lot of rubbing and bumping. We struggled as Boulder team and Raleigh team tried to figure out the balance between autonomy and culture. And we were tackling this cultural bumping while working collaboratively on the same product and sometimes in the same code-base.
We knew we had to address the lack of local leaders from corporate and so we started with 3 specific practices:
We stuck with eight-week agile release cycles. This frequent synchronization really helped keep the wheels on both cars. To help jump start real collaboration for the releases, the Raleigh team flew out to Boulder for most of the release planning meetings in 2009.
Within the releases, we chose to develop a vast majority of the Raleigh code as a separate service running in separate application containers. This supported the Raleigh team having almost complete ownership of the functional value they delivered.
We added HD Video conferencing to support frequent meetings and open worm-holes to broaden communication channels beyond emails, IM, and phone calls.
Our next steps brought in additional agile team members.
Since the acquisition of 6th Sense in late 2008, we had a only a partial agile team in Raleigh. To complete the team, we added a development team lead and a product owner in Boulder. In 2009, the Raleigh team released Rally’s customized reporting service and time-tracking capabilities. Todd Olson’s ability to lead the Raleigh team in collaborating with the existing team in Boulder was yet another critical piece in our path to integration. Todd was the original founder of Six Sense and the spiritual leader from founding and past experience in ALM space with Together J and Borland.
Todd and his daughter enjoying one from the Cup Cake Shoppe in Raleigh
This summer, the office moved into a larger space to accommodate our hiring efforts in Raleigh. So far this year, we have hired or moved six new people into Raleigh and we are not done. Shameless plug – “In fact, we have 21 open positions at the company in Boulder, Raleigh, London and in the field.“ Part of the Raleigh growth was due to the AgileZen acquisition in April. In January, we were feeling good enough about our lessons learned with the 6th Sense acquisition to make that move. This time, instead of moving Rally people to where AgileZen lived, the AgileZen team moved to our Raleigh office. We found out about their intention to move during the negotiation process and it was a huge green light in the transaction. (Think like BEA above – makes balancing autonomy and culture much easier when the management bench can not support the acquisition.)
Based on some of the joy, happiness well-being and cupcakes! (These were no ordinary cup cakes, they were from the Cup Cake Shoppe – made famous by President Obama during the Healthcare debate. We found out the owner is a great lady as she even chauffeured our own Susan Ruh to the new office!) Jean and I witnessed all this during our Q2 celebration visit, Rally Raleigh has certainly taken strides to build a cohesive agile team in a period of growth and integration.
But, there is still more to do
We recognize that there are always items in our organizational backlog. As the Raleigh team continues to build the whole, we owe a bunch to the folks who were closest to the open-wheel racing process. They kept their cool, did things to build empathy for the other team and kept focused on delivering value. For Rally as a whole, we still have a lot to learn about running remote offices in a culture that is much more collaborative than what any of us witnessed in the last decade at BEA, Borland, Mercury, Quark, Rational, or Serena.
Please comment your ideas or experiences with remote offices and highly agile teams.
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:
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: 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.
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 Tabakais 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.
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.
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.
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.
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:
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 there 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 you 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?
RallyDev.com
Finally, to fully explore the problem and solution space, we created the RallyON conference. We will host this conference in Boulder on May 10th and 11th. We limited the conference to 150 attendees and it has sold out quickly to our most active users and champions. Don’t worry if you are not attending as there are a number of ways to engage in the conversation including:
I just wanted to take this opportunity to thank each and every one of you who follow the Agile Blog.
Last week at Agile 2009, I attended a 
