“It took me more than 53 years to understand that culture isn’t just important, it is everything.” -Lou Gerstner
In the coming decade, software and product teams must provide the critically needed innovative approaches to organizations throughout the world. The visual metaphors and practical, hands-on ideas in these posts will give executives, managers, and engineers ways to speed up this evolution. Starting on Monday.
To make and maintain a culture of innovation requires a team to consider that task as a part of their work, complementary to, and as important as, the commercial task. Work on the culture must go forward during the workday. We’ll suggest, for example, that you include a warm up as part of the daily stand up. The team leader will lead this at first, but when it has become part of the routine, leadership will rotate among the group. Team members who learn a new exercise somewhere else will bring that to the stand up. You won’t tack this on to the day as something extra: it’s central.
As well, on analogy with the public schools, an executive or team leader might propose in-service learning requirements. Normally schools don’t require that teachers take specific courses. They demand instead a required number of course hours per year or other interval. Such courses include learning new techniques applicable to the work at hand; but, more important, they can be general—education rather than training.
Google is only the most well known of modern corporations to suggest that workers spend up to 20% of their work time on personal projects. Google encourages personal projects that have no readily discernible connection to current work, and imposes no requirement that such projects result in marketable outcomes. Now and then, of course, they do. And they’re a main reason why the competition has such a problem keeping up with Google. Not even Google knows what the next thing will be. More important, they serve as practice in innovation: people discover and refine their skills in a no-stress situation. They are free to be wildly creative.
In colleges and universities a similar situation obtains, though with considerable pressure attached at certain times in a professor’s career. We mean the custom called “Publish or Perish!” To achieve tenure or to be eligible for promotion, a teacher must make a contribution to the field. Mostly this means publishing the results of research.
Some places, Harvard Business School among them, grant tenure only to men and women who have achieved an international reputation within one or more fields. While this requirement weighs heavily on young faculty, the purpose is clear: research offers faculty an opportunity to practice the skills they teach.
More important, though less observable, accumulation of knowledge beyond what’s needed for tomorrow’s class supports a career after the initial thrill of teaching wears off and interest wanes. Of course these are ongoing programs; they have their true effect over the long term, as they become embedded in the company tradition and in an individual’s sense of work.
But, you say, “How do we have time to do this?”
Turns out that a reasonable amount of time spent in these pursuits increases productivity. When Frederick Taylor began his time and motion studies of workers shoveling coal at the steel mill, they balked at his requirement that they take breaks on a schedule he devised. They were paid for piece work, and feared that Taylor’s breaks were a management device to reduce their paychecks. Taylor insisted, and the workers discovered to their amazement, that their pay went up noticeably.
This notion of pay for story points has not caught on in the software field.
Many folks in the Agile community would argue that Agile is all about culture change. As you know, we do not see Enterprise Agile adoption as solely about anything. For most teams it starts out as a process change, runs headlong into weak testing technology and then confronts some major cultural elements as the scaling or replicating come into play.
Our Flow-Pull-Innovate approach can be mapped into a state transition diagram that blends changes on all these fronts. It is our experience that teams neither have nor take time to appreciate these cultural items until they have shown some improvement. At this point, it becomes easier and paramount to reinvest some of these gains into continuing the journey. This can be in the form of slack time, schedule time for innovation, or new infrastructure in building, testing, or planning.
Now once teams get to the benefits of pull at a program level, the focus of adoption needs to move towards organizational culture. I believe the transition from traditional to Agile, involves quite a shift in infrastructure, methods and guiding ideas. The awareness for the changes in Guiding Ideas seems to come primarily from bottom-up adoption or occasionally from a new senior level executive who was brought into drive change.
Making changes of the magnitude we’ll suggest won’t be fast and easy. If you want to move fast, you’ll want to get help. This can be tricky. Consultants are typically a quick-fix; this won’t do in the long-term, but they can help with a push. However, a culture lasts, and work to create and maintain it should last as well. The consultant’s techniques stop lasting all too soon. We suggest that you find ways to learn about companies and teams that can become role models. This can be difficult. You’ll need to take time to build ongoing relationships of trust and reciprocity.
You can also consult people who routinely work in a culture of innovation. These include (but aren’t limited to) three groups.
(1) Actors make a new thing each night they perform the play, and their rehearsal processes are a compendium of good ideas for innovative agile teams.
(2) Theatre directors are a great source of method and lore for team leaders in an innovative culture. They every day address the difficulty of supervising men and women who have skills that they do not. They can’t bark out orders, but must find ways to encourage constant innovation.
(3) Painters (not house painters) in their work interact with an emerging form, the key element of collaboration, as they create a new and unique thing each time they make a picture. They can be especially persuasive and helpful on the question of replication: since they can’t do it (Every painting they make is new and unique, even if they try to copy themselves.), they have developed views and attitudes that software development teams and their leaders can use to advantage.
We remember a teacher who told his classes, “The way to improve your writing is to apply the seat of your pants to the seat of your chair.” The way to get started is to get started. Make the commitment. This can be a top down or bottom up movement, but support from above is key to a good beginning and to ongoing success. The budget for subsequent projects should include time and funds for preparation and team building of the kind we’ve described. Team leaders and managers should commit to constant reinforcement of the aim, and to vigorous support of performance by individuals and particular teams.
Keep an eye out for upcoming posts on this theme, where we will cover many of these concepts in greater detail. But, as always, your feedback in the form of comments would be tremendously valuable in shaping our ultimate path and conclusion.
An Introduction to Lee
Jean and I, along with other Rally coaches write on the concepts of Agile Enterprise Adoption and our recommended approach called Flow-Pull-Innovate; however, most of that copy has been dedicated to the first two states of Flow and Pull.
Personally, I have struggled to write about Innovate because our language seems to be all-wrong. So we recruited a friend to help, his name is Lee Devin. With Lee’s help we are going explore the state of Innovate with words and stories that will help us understand this advanced state of Agile adoption. There are a number of topics that we have discussed in this collaboration and we plan to share all of them through this first quarter of 2010 (see How to Foster a Culture of Innovation)
Lee fishing in Colorado's 11mile Canyon
I met Lee Devin through my next door neighbor Gordon Wickstrom. Lee was a colleague of Gordon’s in theater and a fellow fly-fisherman. Gordon is an old school theater professor, he believed in structuring the performance to give the actors a place to create. He like Lee has a passion for his craft and feels absolutely fortunate to have been able to work in the theater profession his entire life. Gordon and I have shared many a lively conversation about theater and software and it was one of those conversations that led me to Lee.
According to Gordon, Lee has a more creative approach to theater development; one that is more emergent than Gordon’s. After numerous professional interactions and three fishing trips, Lee and his family are good friends. And his son, Sean has got to be one of the best anglers on the planet; fishing with him is like fishing with Yoda.
Now into Lee’s book with Rob Austin, Artful Making. This book blends Rob’s research into innovation and agile product development with Lee’s mastery of theater; it is a real joy to read. It conjures up some of my best memories of creating beauty and greatness in software. Their contribution to our profession is to help us break our mental models or metaphors around the work of software development. You can let go of your mechanical metaphors and let Lee give you a complete vision of software as a creative and messy design process for conjuring up real beauty and innovation. After a fishing outing last summer in Boulder, Jean and I had breakfast with Lee and decided to collaborate with him on work around the topic of innovation. You can read Jean’s words about Lee and Rob, in her post “What do Actors and Programmers have in common?”
Just published in Dr. Dobb’s is my article on Agile Social Contracts; It covers the process of Agile rollout planning and the burning need for a clear commitment to your teams and organization. What is not as well covered are the other four components.
I make the argument in the article that Agile enterprise adoption is easy, if you are prepared and crisp with the right structure and discipline.
Here are the five items you need to be successful at Agile release planning or Agile Enterprise Rollout planning:
Release Planning Structure
Agile Enterprise Rollout Structure
Team – Cross-Functional Development Team
1
Team – Cross-Function Transition/Steering Team
Commitment - To the Definition of Done
2
Commitment – To changes in external metrics
Contract – Team Norms
3
Contract – Social Contract with the Organization
Roadmap – Product Increments
4
Roadmap – Flow-Pull-Innovate transition steps
Vision – Product/Service
5
Vision – Organization, Process & Technology
Agile Rollout planning is best done like sprint or release planning. This is what I and others mean when we say “using Agile to rollout Agile.“ We use the same methods, structures, and process to rollout Agile as we do to manage our development. This gets senior managers and executives talking and experiencing Agile along with all the practicing teams. It leads the transition team to the benefits of visibility, alignment and frequent feedback cycles. When this is done, it makes Agile Enterprise rollouts as easy as Agile software development.
I do not believe there is a recipe for Agile enterprise transition plans because good ones must take the context and setting of the organization into account.
I do believe that starting step-by-step is the only way to get the snow ball of incremental improvement rolling down hill. Our model, Flow-Pull-Innovate, is based on a strategy of creating a self-funding sustainable approach to adopting Agile; where some of the savings/profits from each step are reinvested in the next improvement step. (See my post An Alternative to Agile Adoption Cookbooks – Flow, Pull, Innovate for details on this approach.)
In addition to a step-by-step transition plan, you need a vision, shared commitment and social contract to be successful. Although, The Flow-Pull-Innovate model does provide sign-posts for your roadmap, the actual stories necessary to transition vary. When we work with groups or organizations to build a plan that will take them from one step to another, we use a transition planning model that I helped define in the mid-1990’s. This planning model is based on organizational change work from Peter Senge’sDance of Change and Michael Hammer’sReengineering the Corporation.
In this step-by-step plan, we use these high-level variables for planning change; “Strategy, Process, Organization and Technology.” In these transition steps, a typical story starts with the implementation of new technical and organizational infrastructure to support new methods, tools and techniques that lead to new way of working. Download An Example Transition Plan (PDF).
An Example Transition Plan based on the Flow-Pull-Innovate model for Enterprise Agile Adoption
Again, please note this plan is very high-level and a fairly generic application of the Flow-Pull-Innovate approach. (See Jean’s post on What’s So Great about Flow? for more details on the first step.) I have seen many variations on these detailed plans over that last 6 years. Use this as a simple starting point for you and your group to think about your own situation. If you work with Rally coaches to help you plan your organization’s transition, you benefit from their years of experience and ability to start with a clean white version of this model.
Transitioning to Agile at the enterprise level can be a very simple step-by-step process as long as you and your group thinks about it in this way. If you do a good job of defining “Done” for your steps, you will then be able to inspect your progress and adjust your plans based on empirical feedback. In this way your adoption approach is just like the Agile process your adopting for software development; an empirical process that you steer with regularly schedule inspection and adjustment.
If, on the other hand, you think about the adoption as a “Big-Bang” that will be done on a certain date, I believe your “plan-driven” thinking will cause you to miss the real opportunity. You will typically end up with only incremental improvement and not have the momentum to enable your teams to keep up the good work. And, you will fail to get on the continuous improvement curve that will lead towards Agile/Lean expertise. Given that most organizations are operating in a “plan-driven” world, this is not a surprising reaction to Agile adoption. Agile success comes as you gain success incrementally by taking one step after another, while keeping process, technology and organization change areas aligned.
In CMMI, Level 5 teams get to a place where they “become continuous improvement teams.“ In enterprise Agile adoptions, we start folks at continuous improvement and watch them benefit from creating employees and teams that both solve their own problems and continue to re-focus on value delivery through each step.
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:
Core Agile Development
Disciplined Agile Delivery
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.
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.
RallyDev.com
and CMM. What Jean and I present in our whitepaper titled “
