Do you notice a difference between problems and difficulties? A problem has a solution. When engineers solve it, the problem goes away. It’s a question raised for solution with fixes, tests, and checklist updates. In contrast, a difficulty has no solution. A difficulty wants you to sit with it, address it, not solve it. Artists know this world of the difficult very well. No definitive fix, test, or checklist will suffice. Sitting with and playing with the difficult is simply part of the knowledge work of the artist.
For both the engineer and the artist, a difficulty is often what tangles up the solution to a problem. We see problems and difficulties all around us in the world of innovation. What’s needed to address a difficulty may not be clear at first, if ever. You may, in fact, never achieve that lovely industrial clarity. And yet, our ability to gaze unflinchingly into the face of difficulty will lead us to solve problems with greater innovation and deeper artistic mastery.
Difficulties require “AND” thinking
Difficulties are fuzzy. Improving how we address difficulties requires us to hold a large container with the word “AND” versus the word “OR.” This concept was first introduced to me in Peter Senge’s Fifth Discipline Fieldbook. I also delved into the topic in his course on Leading and Learning for Sustainability. To work with difficulties, we hold and play with a spectrum of possibilities, multiple solutions sets: this AND this AND this AND this. For the actors in a theater ensemble, AND means absorbing a variety of possibilities with the materials surrounding the play. Many innovative outcomes await based on the ensemble’s ability to hold the ambiguity of the art and embrace that sense of release.
For engineers, this might look like the following: you are solving multiple simultaneous equations for problems you see in the larger system. To be able to hold on to this container, you and the team have to feel safe “failing” with lots of little experiments. You must keep the “art of the possible” in mind. This is not an easy task for an individual, much less a group. Difficulties that accompany problems require the courage and patience to sit in a large container of ambiguity.
Consider the wicked problem example
In their book Wicked Problems, Righteous Solutions Peter DeGrace and Leslie Hulet Stahl help us delve further into problems and difficulties. Wicked problems arise out of several conditions. First, the problem domain is complex and fraught with difficulty. Then, the solution domain is similarly complex and difficult. Finally the two overlap. That is a wicked problem. Wicked problems hold nests of difficulties. Let’s compare the wicked problem of an engineer and one of an actor.
The engineer’s work begins by reading a user story and exploring the problem sheet from the architecture council. In this assignment, the engineer must be prepared to address known and unknown difficulties on the path to a solution. The engineer recognizes that there is no one solution. How difficulties are addressed may be the key to just how innovative the resulting solution is.
This assignment is the equivalent of a script given to actors. The script is not a limit, but rather material on which to perform and interpret to create something new. There is no one solution. And so, the actors hold ambiguity as they move to the ultimate offering to their audience. How the final play comes together may depend on the ensemble’s ability to play with and address the large realm of possibilities.
The art of the possible and innovation
Like actors, engineers and other knowledge workers need to do our homework, invite innovation and alternative solutions. We need to address difficulties not by point solutions, but by applying “AND” thinking, creating large containers of possibility. We must embrace the art of the possible. In the case of the actor, this comes in the form of rehearsal, ensemble and release that ultimately leads to the actual performance. In the case of the engineer, this work comes in the form of design spikes, set-based engineering, and tests. In both cases, experiments create space around difficulties. The art of the possible broadens the team’s or troupe’s innovative outcomes.
For such a culture of innovation, “AND” thinking is a vital function. At Rally, we apply “AND” thinking in how we address difficulties in a variety of ways. We may take a particular problem with its difficulties and spread it across a paired team of engineers. The teams work safely in an “art of the possible” mode for addressing difficulties in a way that leads to a better solution. We eventually move through the “AND” to a final solution, having addressed the difficulties in a variety of contexts. How you invite “AND” thinking and the art of the possible into your organization may include your Chief Engineer, a Product Owner, Director of System Engineering or a peer engineer all working in a new larger container.
Say “No,” to “No way!” and “Yes,” to “Imagine if…”
Within given circumstances, which are different for each team member, and a safe container for the conversation, the group can play out the implications of a solution, and discover its virtues and flaws. As with an ensemble of actors working through the possibilities of a scene, the only rule is: Never say, “No!” Swallowing that “No” can be hard! You must fight your first response to a suggestion or proposition, which is often “No, there is no way that it will work.”
Instead, the thing you must do is think, “Wait a minute. Let’s assume it will work. Let’s find out what happens when it does.” And, you’ll find out what happens when it does by behaving (thinking, talking, deciding) as if it is in place and working. If your first response is “Oh, wow, what a great idea!” the release might be, “How do I fit myself into this? What can I do personally to make it work?” The tool here is imagination.
We must find comfort in ambiguity and uncertainty. The question is: how can you create the container that allows your team to live with this difficulty and keep from jumping to try and solve it? If we create a culture friendly enough to notice accident and serendipity, we set ourselves up for the asymmetric payoffs associated with successful innovations. Our “AND” thinking and art of the possible ferret out the wicked problems and harvest collective team creativity.
Plan to do what you want. Prepare to do what you must.
Don’t get us wrong, we value planning: it’s important and highly creative work. But in the Culture of Innovation preparation means much more. In a world that defines success as a result and failure as a step along the way , we plan regularly as we adjust to results, outside stimulus, and feedback. Preparation marches us up the stairs faster and ensures that we’ll arrive someplace new and valuable.
Planning is an exercise for imagination and not spreadsheets.
In planning we figure out what we need to accomplish this task. It‘s a process of creative thinking, dialogue, narrowing to convergence, healthy skepticism, and risk mitigation. In planning we need to treat difficulties as a challenge; to resolve a creative tension between reality and what we want. Teams brush away perceived limits as they press toward understanding by asking WHY? Thinking in the 5 Why’s of Fishbone diagrams, these teams do not simply work with WHAT and HOW. Once done and aligned, the plan becomes a communication of intent and result and NOT a goal or commitment. Dependable results come from a focus on the limits to throughput, sources of failure, and lack of preparation.
In our experience with Agile teams, we see advanced Scrum teams begin to let go of some planning practices as their expertise grows. The benefits of pull-based planning and smooth flow delivery create new space for them in the market. As a result of their growing confidence, they increase their ownership of their process, a key step on the way to a culture of innovation. That culture creates, not just one off innovations, but an environment ready to take advantage of opportunities and happy accidents. A big part of creating that environment comes from a focus on preparation.
Let’s consider preparation. Teams and managers must learn and practice a set of skills that taken together can help them create a culture of innovation. These skills often seem off the subject, not to the point, and therefore difficult for teams and managers to make time for. We think of preparation in three main categories: for collaboration and leadership; for comfort in ambiguity; and for daily productivity. In this brief introduction we won’t suggest a detailed program. Instead, we’ll outline an abstract of the culture, seen through the lens of preparation.
Collaboration and leadership
You can prepare for collaboration (innovative team work) and leadership (team direction and support) by learning and practicing release and concentration. Teams and their leaders need release from tension, as a way to increase available energy and flexibility; and release from inhibition and vanity for freedom, to include the work of others in their own and to regard the success of the team as their own success.
Take a look at athletes for good examples of release from tension; at actors in a play or movie for good examples of release from inhibition.
Watch Sharapova’s face as she looks up at the ball she’s about to whack; see the pitcher take a big breath and whoosh it out before he throws the ball. Look at a still photo of what the pitcher does to his arm in the delivery: it’s not hard to imagine what would happen to those muscles if they weren’t completely released, free of any kind of tension. Look at Paul Newman’s famous eyes blaze with rage (as Harry Manning, dumped in the river: Where the Money Is) or fear (Buffalo Bill astride a fractious horse: Buffalo Bill and the Indians).
We’ll use a story to illustrate what we mean by concentration. Once upon a time two students of Zen walked along the lake shore. They spoke as follows:
First Student:“I have the world’s most amazing Master.”
Second Student:“Have you?”
First Student: “He performs miraculous deeds. The other day he walked right out on this lake and spoke to us, standing on the surface of the water. Then he walked back, and his shoes weren’t even damp.”
Second Student:“That’s certainly amazing. I congratulate you. My master, however, can do something much more important and amazing.”
First Student:“No way.”
Second Student: “Yes way. My master can do one thing at a time.”
Who among us can do one thing at a time?
As you plan your week next Monday, think about these questions.
What is the #1 Thing you have to get done right this week? Be clear about that to yourself and with your team and put your best time and focus on this one item.
What preparation or practice can you do to release tensions with regards to this item?
Who can you collaborate with to make this an outstanding result?
What can you do to celebrate the results of this effort?
What might you do to prepare to execute these choices? What kinds of practice might you build into your daily, weekly, monthly, routine?
Comfort in ambiguity
Accident, serendipity, new things. Innovation confronts the team with all of these sources of ambiguity. What’s gonna happen? What should I do? What on earth is this thing? How do we know when it’s complete?
How does preparation contribute to comfort in ambiguity? It gives us grounds for confidence in our ability to manage the new, the surprising, the unpredicted. We don’t need to dread the uncertainty of innovation because we know that we can make good use of whatever comes up.
Teams and managers who do innovation find ways to live with uncertainty about the outcomes of their work. They know that outcomes will be unexpected and surprising. If they could anticipate them, how new could they be? Preparation will involve getting free of the reflexive invocation of the past: “That isn’t how we do things here”; and embracing the uncertain future: “Let’s see what happens when we do this.”
Preparation will sometimes replace planning.
Of course we plan, so that we can do what we need to do. We plan to have the materials we need, space to work in, the right people on the team, to make an efficient schedule. Planning creates sequential progress toward a known goal. Preparation, on the other hand, aims at collaborative iteration toward an emergent outcome. No one can predict the results of a true collaboration. We prepare to cope with whatever happens. In a culture of innovation, whatever happens is likely to be new. It will elude any kind of sequential progress toward a known goal. When an outcome doesn’t seem to have any immediate value, we recognize that nothing is lost: we set it aside (Might come in handy some day.) and press on.
The notion of emergent design conditions any serious innovation. At Rally Software, we do a number of things in the context of Agile software development to keep from planning too much and to hold space for reaction to ambiguity. First, we acknowledge multiple levels of planning with less precision as the time frame goes out. Second, we insert free time into our schedule in the form of slack and programmed innovation time. Third, we work “sets” of designs through a narrowing process to keep from choosing the design before we learn. Finally, we do not plan until after we have closed the last cycle: We check the results of that last cycle and consciously review our goals. We “Plan to get lucky” and provide room for that to affect our next cycle.
We took a young engineer to visit an acting class at People’s Light, the theatre we know best. A bunch of teenagers were practicing improvisation. One sat on a bench in the park. Another passed by, stopped to talk. A story began to develop. Suddenly from the class a third jumped up and walked into the park, joining the two. This newcomer brought an entirely new slant to the story. After a moment the first actor remembered an appointment and left the other two. Someone else from the class joined in. And so on. The story grew, got elaborate, got simple, got turned inside out: the kids never repeated themselves, never stopped. No one ever refused the new material offered by an other. The engineer turned to us and whispered: “This is exactly what my guys need to learn how to do.”
This kind of practice fairly closely resembles the desired skills. Engineers like to look for an answer in the back of the book; they need practice in making up answers out of the available material. The kind of preparation we’ll call exercise strays from the skills it prepares for; it’s off subject, away from the actual work. Athletes exemplify this kind of preparation. “The champ,” goes the saying, “is always in the gym.” Larry Byrd was famous for staying in the gym after practice. Why? To shoot 100 free throws. To build a reflexive confidence that supports the hectic innovations of the game. What’s more, the champ has decided, has made the choice, to like being in the gym; how could he do the work otherwise?
As you plan your week next Monday, think about these ways of practicing or preparing for emergent innovations:
Schedule some creative time into your schedule to spend in a creative place and time.
Step back from your #1 item for the week and ask yourself a question about its value: What other things could I do to deliver even more of this value?
Find one example of yourself closing down to new solutions based on the concept that “This is the way we always do it.” Can you release that constraint?
Ask yourself: What is the most important thing I have to do this month or quarter? Not urgent. Important. Do I have enough time, support, and space to do this right? Try removing less important or merely urgent things from your calendar to make room for this.
Daily productivity
In a culture of innovation, everyone chooses a professional obligation to work happily, enthusiastically and at maximum energy.
Artists and athletes again serve as models. Neither group can do what they do unless they’re totally fired up. High morale and physical readiness are basic conditions of their work and they must learn how to create and maintain them, no matter what. An actor arrives at the theatre well before the half hour call (On time is already late.), and begins the day’s work with an extensive warm up. Vocal exercises, calisthenics, stretches, lines; actors have routines they follow religiously.
An actor we know told us this story. He used the 30 minute drive to the theatre as his time for vocal warm up. One night, distracted by some domestic emergency, he only got through part of his routine by the time he arrived at the theatre. In rehearsal he had discovered a way of saying one of the lines in the 2nd act that every one liked a lot: his voice got deep and sexy, very nice moment. On this night the performance went very well, in spite of the truncated warm up. Until that deep sexy part. He said that line exactly as he had done dozens of times before. But instead of deep sexiness, what came out of his mouth was tired little squeakiness. The audience were too embarrassed even to laugh. You can bet that actor never missed another warm up.
In software development, this is akin to doing some manual work outside the scope of your automated build, deploy, test cycle. It can seem quicker to do a simple, one-off integration or system test outside that environment, but unintended consequences always catch-up . In our experience, cutting the preparation corners usually costs 10X more in the whole lifecycle than it saves in the short-term. Beyond the interrupts of customer-impacting defects, the team loses a bit of the pride and belief necessary for the Culture of Innovation
Team work demands a no less total performance than acting or tennis playing. It needs, but rarely gets, the preparation of a warm-up. A basketball team combines individual warm ups (stretches, shooting around) with group work (lay up and passing drills). Why should knowledge work be any different? Imagine the energy available if your morning stand up included a vigorous warm up led by a different person each day. Jump back!
As teams and organizations reach an Innovate level of Agile adoption or Ri , they take ownership of their process and environment. Their improved throughput, collaboration, and preparation have brought them to a place where many of the vanilla iteration, planning, and estimating practices of Scrum and XP stop serving them. These structures helped the incremental transition down a path of increasing agility, but in a Culture of Innovation, where smooth, continuous flow of one thing at a time is the goal, the focus moves from planning to preparation.
Next up in our series – Options, Fall-back and Design Sets
Failure and success are handy terms when we want to characterize closure in an industrial making process: We call a thing that works a “success,” and a thing that doesn’t work a “failure.” In an iterative collaboration that leads to an emergent result, they’re not so clear cut, not so handy. We come to closure on an iteration. When we test it, we find it doesn’t do some of what we need.
Thinking industrially, we say “This sucker won’t work. It’s a failure.”
But we need nuance here. It makes sense to observe that the thing failed the test. It makes non-sense to say that the thing’s a failure. As part of an iterative collaboration the current thing is a necessary part of a journey toward an innovation. Chances are pretty good that this iteration contains the seeds of the one that finally does the job.
We think of starting to build a new culture by reconceiving a couple of words because we believe that language is the key to our work; use of language is, after all, the fundamentally human action. Those old Greeks had this idea: they thought of language as a distinguishing feature of a human being. They knew creatures in the world who did not speak Greek, who made unintelligible sounds like “Bar, bar, bar, bar.” They called such creatures “barbarians.”
We won’t go that far, but we will suggest that language is our best tool for thinking and making choices, for knowledge work.
In this Blog Post by Tim Walker at Hoovers - Tim asks, How do you cope with Failure?
Before we make suggestions about how to address this difficulty, let’s revisit an important feature of any culture of innovation. The dominant way to make innovations is to run collaborative iterations. Get an idea of what you’d like to have; make one; test it and discuss it among the team and, if possible, with the end user; on the basis of this discussion, reconceive what you’d like to have and make new one; use everything you can from the previous iteration; chase new ideas to their end without predicting results; test and discuss; reconceive; make a new one; and so on until the project reaches closure. You recognize closure when anything you can think of to do makes the thing worse, not better.
Most of us are okay with the idea that the end product of an innovative process emerges from that process and is, finally, unpredictable. What we have not confronted is the idea that the words we use to think about processes and products may interfere with that and may need reconceiving.
Redefining ‘failure’ and ‘success’
If you can plan for and schedule a process, how new will the outcome be? Not very. But, how can you start on a project without identifying a goal, making a plan to reach that goal, and without confidence in your plan? We all know these keys to success, and unsuccessful equals failure. Right?
Failure! “I’m no good. Better go out in the back yard and eat worms.”
Failure! “Thank God, let’s drop this sucker and move on. Now that we’ve failed, and learned from our failure, the next idea will be a good one.”
Well, maybe not. Maybe instead of failing, you’ve taken an essential step along the way.
Maybe you haven’t reached an end point and suffered a defeat. Maybe you’ve moved toward an unpredictable closure. Some innovators, Tom Kelley of IDEO among them, believe that to succeed you must fail often. Works for him.
We think there’s a better way.
We can begin by noticing that our models for “failure” and “success” limit our work. This means that we need to make a cultural change, from industrial (plan, design, execute) ideas of making toward artful, innovative ones (prepare, iterate, test, iterate again). Think of a staircase. We don’t regard the first step as a “failure,” as “unsuccessful” because it doesn’t get to the second floor. It’s a step. One of many. Just so, we need to decide to put our attention on our process, conceiving it as a journey.
The change of mind here is: we can’t say, exactly, when we’ll complete the journey, or when we’ll arrive. In fact, sometimes (out of which times come the really good stuff) we’re not even sure where we’re going. But what we can say is what we just learned and what we recommend that we do next.
At Rally and in many Agile teams, we use a notion from eXtreme Programing called spikes. In a spike, the engineer sets out to learn what she does not know by conceiving of a simple test to prove or disprove a theory. These spikes are used to help narrow an estimate, gather data on a continuum of choices or narrow a field of options. By calling it a spike, the XP creators helped us RECONCEIVE the ideas of success and failure for a story and thus helped themselves and the rest of the team.
Suppose we decide to go further beyond just a small task like a spike and conceive of each iteration toward an emergent innovation as an essential step along the way. Suppose we decide to conceive success as a measure of progress, not closure. In our culture of innovation, this means we conceive product as a result, not a goal. We’ll know it when we get to it.
Here’s an idea that can help. “Nothing is lost, and wonders never cease.”
Artists live by this mantra: when the work reaches closure it contains everything done on the way. (You’ll see actors who don’t seem real. That’s because all they’ve done is learn their lines and blocking and a way to say the lines so that they’ll sound good. You’ll see actors who seem as if they are the character; you can’t believe they’re not personally like that. That’s because all they’ve done is spend hours and hours of thought and research into creating the given circumstances, a complete history, of that character.)
Instead of discarding work that didn’t reach a goal, reconceive the idea of “goal” into “result” and decide to use what you just made as material for the next iteration toward a result that you’ll recognize when you see it. The more of the current iteration you can find to use, the better. The harder you have to work to include everything, the better. In combination with the new ideas you (the team) get from discussion, and from the imaginative effort you spend, something unpredicted, something new, will appear in the next pass. This will happen.
The cultural principle here is: Collaborative iteration equals Innovation.
In this model, we can measure the progress of effort as it converges on the product. What were the tests results with which stakeholders? What paths will we not follow any further? What potential design sets still need to be tested?
The failure of tests down a path is actually progress and a sign of innovation. Progress is a narrowing of options toward an optimal solution and failures are critical to narrowing.
By adopting the iterative process of Agile we increase the opportunity for innovations, but ultimately we need to prepare for improvisation by changing our idea about language. We need to use language; to decide what words mean. To use language, in other words, as a tool we control, not as a reality that traps us. And that’s a cultural change, not a tip we can quickly use.
We do have a tip, a simple (but not easy) way to begin this complex change. Never say no. Hang that on your wall next to the “No Sniveling” sign. “NEVER SAY NO.” This simple (but not easy) change cannot fail to increase the creative range of individuals, teams, and the organization. It’s not a final answer, but it’s a step along the way.
“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?”
This week, I had the pleasure of attending the seminar “The Way of Artful Making” presented by Rob Austin and Lee Devin , co-authors of the book “Artful Making”.
While I have met both gentlemen separately in the past and heard them both speak, this was one of those golden moments when I was able to hear them co-present. And for me, I loved the odd mixture in the audience: MBA students, MFA student actors, and software engineers. (Okay, guess which group I was in?)
Lee and Rob have a great “pairing” style in presenting. For those of you who don’t know them, Lee is a professor emeritus in Theatre from Swarthmore College. And Rob is a former associate professor at the Harvard Business School and is now full professor at the Copenhagen Business School.
In co-presenting, Lee and Rob take turns applying their perspectives about the look and feel of artful making. For Lee, this is about life in the theatre. For Rob, this is about great product development and, in particular, software development. So two great tastes that, as it turns out, taste great together (sorry, a reference to an old candy advertisement :)
So, what do actors and programmers have in common?Well, some amazingly fundamental things as it turns out:
Iterative work
Collaboration
Innovation
Theatre work and product development both thrive on iteration and collaboration. Lee described this in terms of rehearsal and the emergent look of a play leading up to and even after opening night. Rob affirmed the value of a collaborative and iterative approach in product development and provided videos from Boeing and Bang and Olufsen showing how both companies take advantage of this approach.
What do these practices have to do with innovation? Well in both theatre and product development, Lee and Rob encourage us to embrace what should be the glaringly obvious; that is, iteration and collaboration invariably produce innovation .
What happens when you put iterations and collaboration together? Rob introduced us to a term he had learned during his study of Boeing’s use of iterations: “try-storming”. That is, instead of just brainstorming ideas (whether in theatre or in product development), take your brainstorm and try it. Find something out about it as soon as possible. Then “try-storm” the next idea. (I think I am going to have to steal that term from him!)
I was also very fortunate to be able to sit next to Pete Behrens of Trail Ridge Consulting during the evening. Talking with him afterward, he reminded me of a few more similarities between theatre and product development:
You need to be able to surprise people in order to create value
If you don’t know in exact detail where you are going, it’s okay
The ideal play/product you hold in your head is very limiting; let go of it
In iterations, like rehearsals, each iteration may be or even will be significantly different from each other
We’ve been able to move to being more iterative these days, more Agile, because of technology making it cheap enough to iterate
Nothing is lost and wonders never cease as we build up each iteration from all the iterations before
Artful Making through iterations, collaboration and try-storming—all are important if you intend to be a theatre or product development organization that is truly innovative in the 21st century. And THAT is what actors and programmers have in common.
RallyDev.com
Do you notice a difference between problems and difficulties? A problem has a solution. When engineers solve it, the problem goes away. It’s a question raised for solution with fixes, tests, and checklist updates. In contrast, a difficulty has no solution. A difficulty wants you to sit with it, address it, not solve it. Artists know this world of the difficult very well. No definitive fix, test, or checklist will suffice. Sitting with and playing with the difficult is simply part of the knowledge work of the artist.
This week, I had the pleasure of attending the seminar 
