Agile Development Blog

On the road to Agile adoption, I often get asked, “how do you get teams spun up on Agile fast?”  The short answer is to just do it. The long answer is that I believe there are 3 options. 1) Rally and other Agile coaching organizations offer programs that place a coach in your team to help with preparation, planning, estimating, setting norms, committing, tracking, daily stand-up, demonstrations and retrospectives. 2) You can take the DIY approach,  but watch out for the unintended consequences.  3) Finally, I think there is the intensive practice approach.  Let me give you some examples:

A Sprint Per Day for the First Week

While speaking and attending Agile Vancouver in 2008, Linda Rising facilitated a fishbowl exercise with a custom development firm in Vancouver.  Given they were starting and stopping projects and reforming teams all the time, they had developed an approach to speed the team through the formation process and inculcate new team members (employees and customers) to the process.  The would run a scrum sprint every day for the first week.  This intensive process would allow them to work through tons of issues in a very intensive week.  I would call a form of this preparation over planning.

A Sprint Every 90 minutes for a Weekend

If that is not fast enough for you, how about a sprint every 90 minutes?  That is what the folks at SnapImpact did last weekend in Boulder at their SnapCamp (based on the notion of Startup Weekend).

I heard about this from one of the organizers and fellow Sprint Triathlete Dave Angulo.  Dave is co-founder of the non-profit SnapImpact, a guerrilla non-profit that has a mission to “Make Doing Good Easy.”  They developed an iPhone application and Wordpress plugin to simplify how people learn about volunteer opportunities near them.  It takes feeds from HandsOn Network and soon All for Good. It is cool, I’ve been playing with it for a year.  Anyway, ran into Dave at a CTO lunch in the TechStar’s bunker today and he told me about the wild success they had with 90 minute sprint process through the last weekend.

To give some background, SnapCamp was the kickoff effort for developing v2.0 of All for Good, the platform which powers http://serve.gov and a number of other sites. It’s the largest single repository of volunteer opportunities in the world. Version 1.x was pushed into production quickly and, while it is up and running, there have been a number of technical limitations which have frustrated All for Good’s partners and limited the platform’s usefulness. SnapImpact offered to develop v2.0 of All for Good because of the close alignment of the two organizations’ missions and their desire to have a more comprehensive list of opportunities for their iPhone app.

Dave - We started the weekend with dinner on Friday night to allow time for everyone to meet each other, learn about each other’s backgrounds, and have a shared group experience. We had people from all over the country as well as a great local contingent. Some were die-hard SnapImpact volunteers, others had only heard about us recently. The dinner allowed for folks to get to know one another in a casual setting without having to do it in between trying to get work done.

Saturday morning, we laid out the business problem, context, and goals for the weekend, then I announced we would do 90 minute sprints. The business teams (we had marketing, UI, and product teams as well), would adhere to the same schedule. The beginning of the first sprint for dev was spent laying out four areas of technical problems and having the team self select into what tickled their fancy. Everyone then got to work. I moved between the teams to discuss possible technologies for them to consider and dive deeper on the problems they needed to solve. The volunteers then took over and by the end of the first sprint everyone had a handle on their problem areas. Most even had a initial plan of attack.

Everyone has heard of Forming, Storming, Norming, and Performing. With 2 days to get work done, we had to get them to performing as quickly as possible. The dev teams were all about 3 people in size with differing skill levels and familiarity with the technology stack we were using. The 90 minute sprints forced a tempo which required the teams to get to performing quickly – no one wants to report out nothing was accomplished. Yes, some of the progress initially was small, but these were hard problems to tackle in a weekend. I had one team who’s requirements were being developed by the business team through the weekend, some sprints the deliverable was “received requirements from business and developed a response.”

By the end of Saturday, all of the development teams had produced something which was merged into mainline for the other teams to pick up. That was huge and everyone could see the bar moving.

Sunday started with a review and then everyone picked up where they had left off. The development teams reformed and started working before we even had the morning review. The pace on Sunday kept accelerating, merges occurring after every sprint, until late afternoon, when we started winding down.

I have run many volunteer projects. The SnapImpact team had actually completed one earlier in the week involving several hundred people with BDNT, and it’s absolutely critical volunteers feel like they are moving the bar. Given the scope of this project, it was going to be very easy to have volunteers lose sight of the progress they are making and give up. The 90 minute chunks with progress review and planning helped ensure the volunteers didn’t lose sight of the progress we were making that weekend. As project owners, we had goals of our own on what was going to be delivered at the end of the project. The sprints allowed us to keep moving in the direction we needed to go as well as identify trouble areas.

Dave – Training – One decision I made was to use a relatively new technology stack, Scala/Lift, for the framework. Instead of holding a formal training session for those unfamiliar with it, I made sure there were experienced people in each group and let training happen “on the job.” I think next time it would be better to do a short training session, as given the pace, sometimes that training disrupted forward progress. Just the basics, so when a concept was discussed it wouldn’t be completely foreign.

Deliverables – We got sloppy during the reviews and didn’t nail down specific deliverables for teams. At times, it caused teams to lose focus during the sprint. The reviews were every 90 minutes, so the lack of focus was caught sooner rather than later.

Insert more fun – Because the tempo was so high, I’m not sure folks had as much fun as they could have during the event. I’m a big believer in fun being central to any successful project and I think teams could have bonded a little more and we may not have been as exhausted by Sunday afternoon. There was some fun, we just needed more.

Dave – Our goal was a beta of existing functionality by the end of the weekend. We’re very close to that now, but some decisions made during the weekend prevented accomplishing that goal. The SnapImpact team is continuing development and once the existing functionality is in place we’ll start working on a host of new feature requests from the business team. We’re entering all of that information into Rally now and beginning the planning process. Folks will see v2.0 at http://allforgood.org in June.

Dave - Preparation started weeks in advance. My role in this project is CTO and VP of Engineering. So, the 3 critical things I needed to accomplish before the weekend started was making sure I stacked the deck in my favor with some talented people, had a toolbox ready with possible solutions to the technical challenges we would face, and had stakeholders present to make decisions.

Given the new technology stack, I needed to recruit folks with some very specific skills. To enable that effort we recruited the leader and founder of the Lift project, David Pollak. He helped us motivate a few people with experience using the technology. We also had the SnapImpact team actively recruit their friends. The result was a very high quality team capable of getting the job done.

When the teams started work, they would spend too much time investigating everything unless I gave them a starting point. By bringing some ideas (not solutions) to the table to solve their problems, it helped define their playing field and allow them to make a decision quickly. Implicit in this was understanding the known business problems that needed to be solved.

We knew we would hit roadblocks during development waiting for business input on implementation details. So, we made sure to have some present the entire weekend. One of the stakeholders even brought a developer who was using the existing system. We embedded the dev in one of our teams working on implementing some external interfaces. Yes, that really accelerated the implementation decisions. Also, the stakeholders were really disappointed with certain aspects of the existing system. We had ideas to resolve those issues, but needed to ensure they met the stakeholders needs.

Thanks Dave for the great details on this event and example of agility at work!

This is #3 in a Series on the Culture of Innovation with guest blogger Lee Devin.

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 2^nd 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

About the Authors: Ryan Martens is a goat cheese maker,  founding board member of the Entrepreneurs Foundation of Colorado, and Founder and CTO at Rally Software Development.

Lee Devin is a dramaturg at the People’s Light and Theatre, a Senior Research Scholar at Swarthmore College and a senior consultant with the Cutter Consortium. These activities often interfere with his fishing, and cause him to neglect his grandchildren.

Subscribe today to get free updates by email or RSS.

This is #2 in a Series on the Culture of Innovation with guest blogger Lee Devin.

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.

Next up in our series – Planning and Preparation

About the Authors: Ryan Martens is a goat cheese maker,  founding board member of the Entrepreneurs Foundation of Colorado, and Founder and CTO at Rally Software Development.

Lee Devin is a dramaturg at the People’s Light and Theatre, a Senior Research Scholar at Swarthmore College and a senior consultant with the Cutter Consortium. These activities often interfere with his fishing, and cause him to neglect his grandchildren.

Subscribe today to get free updates by email or RSS.

As a Scotsman living in the US I take more than my fair share of trips through Heathrow airport.

There are many things I enjoy about being back in the UK but Heathrow airport is certainly not one of them. For a while HSBC bank tried valiantly to cheer us up, and as we trudged wearily from terminal to terminal, our journey was made more colorful by the many posters from their What’s Your Point of View campaign.

Here is an example of one of their posters:

Looking at these posters made me reflect on my own work as an Agile Coach and how I am often confronted by different points of view.

If I am speaking to a group and criticize waterfall development there is a chance someone will feel I am disparaging their team or their efforts. Sometimes use of the word agile does not serve a good purpose. Many have negative perceptions of Agile and believe it to be chaotic, undisciplined and unpredictable.

As a coach, I don’t like to spend time fixing negative perceptions of Agile. My passion is making teams and organizations successful. I like to steer away from the waterfall vs. agile discussion.

Instead, I focus on sharing what I see happening in high performance teams and organizations:

• Without knowing what value really is we can’t reduce waste. A focus on customer value answers two key questions: (1) Who am I building this for? and (2) Why am I building this? Once we have a keen sense of what value is we can then prioritize our work to deliver the highest value first.

• By delivering early and often we give ourselves the best opportunity to beat the competition to market, realize revenue and discover insights that we can help us improve.

• One of the biggest impediments to delivering early and often is the inability to reduce batch size and many teams struggle with this. This is a battle worth fighting.

• Another impediment to delivering value is not pull testing forward. If we don’t complete our work as we iterate then we are creating technical debt that will affect our ability to release.

• Successful teams know it is best to take small incremental steps towards improvement and to establish a rhythm of continuous improvement. We don’t try to define the perfect process, we don’t set the bar too high and we continuously inspect and adapt.

• As Émile Chartrier once said “nothing is more dangerous than an idea when you only have one”. Successful teams and organizations know that to survive long-term they need to create a collaborative culture that fosters innovation and shared commitment.

Are these are agile principles or lean principles? Some like to draw an ideological line between the two but like Wille Faler I don’t believe that’s a bottom-line discussion. Call them waterfall if you like, so long as you’re successful.

You might not like my list and that’s fine too. Make your own list but don’t just pull it out of a book. Visit the gemba and come up with something visceral that your team can identify with.

About the Author: Ken Clyne is a 26.2 finisher, Certified ScrumMaster and Agile Coach at Rally Software Development. Subscribe today to get free updates by email or RSS.

I had the fine fortune of spending a day with Liz Keogh and Eric Willeke in Boulder last week.

What a wonderful experience! The three of us gathered with the goal of producing something for the Lean and Kanban software community. We didn’t know what that would be. We just knew we felt strongly that we should give something to the community.

We were heavily influenced by past conversations with Chris Matts, his call for “fewer leaders, more leadership”, and a desire to see the Lean Software and Systems Consortium (LSSC) learn from some of the trials that other communities and community-leading organizations have undergone. Ryan Martens, the CTO and a founder of Rally, also provided thoughtful input to our discussions during the day.

As we talked, we discovered something. We were all keenly interested in the general notion of “community”. We became less convinced that the LSSC needed a challenge from us, and more convinced that it was applicable to software communities generally. For me, this was a deeply personal statement and commitment.  It played heavily into my recent blog posts on “Escalation”. And yet, together, Liz and Eric and I found the same deep conviction.  So as you look at the statement I provide below, if it’s exactly the same as the copies on Liz or Eric’s sites, it’s only because their arguments were equally sound and convincing.

Because of that personal nature, we wanted to avoid putting our statement up as some kind of manifesto that people can sign. If you feel strongly enough about this statement that you would want to sign up, copy it. Post it on your own site. Attribute it to wherever you got your copy from – the act of sharing is more important to us than the act of creation – and feel free to change it so that it reflects your own values. I don’t think that any statement like this can ever be perfect, nor will we perfectly live up to it.

I am a member of a community of thinkers. So are you.

”A Community of Thinkers” by Liz Keogh, Jean Tabaka and Eric Willeke is licensed under a Creative Commons Attribution-Share Alike 3.0 License. Please attribute to the distributor of your copy or derivative.

About the Author: Jean Tabaka is a wine enthusiast, author and Agile Fellow at Rally Software Development. Subscribe today to get free updates by email or RSS.

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 21^st century. And THAT is what actors and programmers have in common.

About the Author: Jean Tabaka is a wine enthusiast, author and Agile Fellow at Rally Software Development. Subscribe today to get free updates by email or RSS.

I have a systems archetype in mind that is troubling me. I am annoyed that some of the current (and past) one-ups-man-ship around Agile is distracting us from the useful constructive dialogue I crave.

The archetype I am thinking of “Escalation” is where “my fix is your nightmare and you have to lose in order for me to win“.

Situations can get sticky with too much escalation

Think of the American movie “A Christmas Story” about young Ralphie Parker and his own dilemma with “Escalation”.  In this classic scene, Ralphie’s friends Flick and Schwartz dispute over whether a person’s tongue will stick to a frozen flagpole. Schwartz ultimately issues Flick a “triple dog dare” (the most serious of childhood dares); bypassing “triple dare” and resulting in a serious breach of boyhood protocol.

Dares, blames, accusations and hard stances all contribute to the distraction and destruction that is associated with “Escalation”. When everyone is trying to win, the system suffers. Anyone’s “win” is nobody’s win; and anyone’s “loss” is everyone’s loss.

I see no place for this in Agile and yet the fight is on. Triple Dog Dares are becoming business as usual.

Escalation is Killing Agile.

So why the heck are we involved in so much escalation around things like “My Agile approach is better than your Agile approach” or, “Well, you’re only in it for the money” or, “I’m going to make fun of you until you stop what you are doing“?

How is ANY of this furthering my growth or our organizations’ growth in Agile?

In a systems view of the world, we can see patterns made up of balancing loops and reinforcing loops. In the case of “Escalation”,  we see factions sucked into a downward spiral reinforcing loop of fighting. The more someone fights, the more the fighting continues.

In our case, the fight may be about certification, or timeboxes, or engineering practices, or continuous improvement, or tools. Fights then lead to blaming and finger pointing. And in the systems view of things, once you get into blaming individuals or other parts of the system, your system is broken. Not the individuals, the system.

So in our Agile world, I ask, “How is this fighting useful? Could someone explain that to me? And how is it our system has metamorphosed into one that allows (encourages?) blame and mockery, one that remains so, or even worse, seeks to move further and further into this archetype?“

For me, a more useful approach is to find balancing loops. Here, we seek to create more knowledge in dialogue not blame. We seek insights with others interested in dialogue, not in escalating debates and accusatory blame. We look toward inquiry versus advocacy and so we seek people interested in this kind of work, not fighting.

One way I intend to take advantage of balancing loops is to seek people interested in Agile growth NOT in attacks on approaches or individuals. I’m thinking, for instance, of Linda Rising as a good example. Linda has been our steadfast beacon of reaching into kindness versus violence or fear or confrontation to use our personal perspectives usefully and creatively.

I’m done with all the distractions that don’t feed my growth. I’ve lost the ability to abide behaviors that don’t give evidence of what was written with conviction in the Agile Manifesto. The train has left the station on a number of initiatives within Agile, Let’s stop fighting them. More fighting isn’t going to make anything go away. Instead, we will just feed “Escalation”. Let us get on with where each of us can find and contribute to growth. Please.

Here is my personal commitment going forward:

My personal commitment is to seek those interested in creating more and more insights about how we can grow and learn. I will seek dialogue around various Agile approaches and what can contribute to the growth of Agile. I will not take delight in anyone’s cleverness or meanness toward an approach they don’t support. I will seek voices of engagement, deeper intention, non-blame, and creative inquiry. “Escalation”, to me, is like the old joke of trying to teach a pig to sing: it only annoys the pig and it frustrates you. I have no intention of spending time with such activity in Agile.  It distracts and annoys me. You’ll have to figure out for yourself how it serves you or hinders you.

So, moving forward, let us think about true dialogue. Let’s challenge ourselves if that is what we invite in each of our interactions. To add encouragement and inspiration, think about the etymology of the word – dialogue:

From the Greek “to gather reason through speech, usually between two people“. I invite each of us to reach for gathering not escalating.

Without this intention, we will all lose.

About the Author: Jean Tabaka is a wine enthusiast, author and Agile Fellow at Rally Software Development. Subscribe today to get free updates by email or RSS.

In this time of “quick – figure out how to do more with less,” the ROI, work smarter message dominate the airwaves.  Back in early agile conferences “quality of life,” “fun,” and “innovation” were big reasons many teams were adopting agile. They are the main reasons that agile gets pulled into most organizations from the team level.

Pulling from her experience on Rally’s marketing team, guest poster Jessica Kahn describes the improved quality of life she gains from working in an agile organization.  This is the kind of spirit that makes agile so much more than a process fad.  It is a way of working.

Guest Post From Jessica Kahn

As a marketer, I spend a lot of time discussing how Agile speeds time to market, improves software quality and makes teams more empowered and productive.  But Agile also has a profound impact on the quality of life of people whose roles have nothing to do with product ownership or delivery.

When a company is in the pull or innovate phase of Agile adoption, the energy is different.  You join a culture of continuous learning, trust, results measurement and servant-leadership.  This energy is far more significant than the mechanics of the theory.

So, I feel compelled to share 10 ways going Agile will improve quality of life, for developers and non-developers alike.   Why should you care?  If your organization is committed to making this change, get on board.  You might see some big gains yourself.

10 Ways Agile Improves Your Quality of Life:

1.  Every team member contributes.

Since Agile empowers the delivery team, nobody can be a weak link.  They’d get exposed immediately, and they’d get left behind.  By definition, everyone has to produce strong work that contributes to project success.  And it is fun to work with people you can count on.

2.  Servant-Leadership teaches us better skills.

There is no time or place for micro-management or Command and Control in Agile.  Since servant-leadership is the goal, managers are responsible for removing roadblocks to their teams’ success.  Planning sessions prioritize the “what”, and team members are responsible for the “how”.   Do we still get lots of feedback?  Yes.  But are we told how to do our jobs?  No way.  As a bonus, you’ll learn how to be a coach and mentor for your own teams.

3.  Meetings have purpose.

We don’t meet unless we have to.  Our daily standups typically last 10 minutes.  Our planning meetings are tightly timeboxed, so we have to focus and then move on.

4.  Decisions are based on data.

We measure everything that is important to the business.   How else can you make smart decisions on where to spend your time and energy?  Rather than succumbing to the whims and opinions of a few squeaky wheels, by measuring important factors, we have the knowledge we need to back up our decisions  and stay the course, as long as it makes sense.  Therefore…

5.  Whiplash is minimal.

Have you ever worked with someone whose great ideas wagged your entire team back and forth until you could never complete a full project?  If an excited, charismatic tail wags the dog, then chaos, frustration and anger result.

In an Agile environment, you put the great project idea in the backlog, prioritize it against other initiatives, and choose whether and when to work on that project.  And you use your capacity and story sizing to manage expectations.  Which leads us to benefit #6:

6.  Politics are absent.

If you are making decisions based on quantitative results and you have a prioritized backlog, then there is no reason to make political decisions.  What’s the point?  You have the numbers, now go do your job.

7.  The bar is high.

You know how one mediocre project can take you forever to finish, but three challenging projects can sometimes energize you?  Agile sprints are more like the latter.  Sprints can be intense and challenging, and also satisfying.  Sometimes you can even point proudly to your results.  Why waste your days doing boring, mediocre work?

8.  The workday is intense and fast.

With all of that challenge, the Agile workday is short and intense.  Do you want to feel like you are always working, or like you have to hang out at work to show face time?  Work hard, play hard.

9.  Change is frequent.

We hold retrospectives frequently (timeboxed, of course).  With a commitment to changing what doesn’t work, we find ourselves altering our plans regularly, including deciding what to stop doing.  This is refreshing.  In Agile, you go along with the ride and breathe a lot, which is probably good practice for life.

10.  You’ll be smarter.

Future colleagues and partners will want to learn from you.  Your Agile skills will turn up in some unusual places.  You might start timeboxing how long you clean your kitchen.  You may choose to include words like ‘epic’ and ‘backlog’ in your everyday vocabulary.

But you also might do what I did and let go of some of your perfectionism, which has no place in Agile.  And, like me, you might pick up some better ways of structuring your work.

Most of all, you might really enjoy your days more.

When I am coaching a team through their first iteration, I often have a Scrum Master and/or team lead pull me aside prior to the retrospective to express concerns.

Sometimes its about things they know the team should address in the retrospective.
(e.g. “we need to get better at estimating”)

It may also be about things they wish the team wouldn’t bring into the retrospective.
(e.g. “we want longer iterations”)

These team supporters are coming from a place of concern for the success of the team and their Agile adoption, but they aren’t trusting that the team will make the right decisions on their own.

They want me to make sure the team talks about - and only about – these specific items, sometimes asking me to explicitly bring the issues in with a softer (i.e. manipulative) approach. I tell them I can’t and I won’t.

I tell them they need to trust the team and trust the process to determine where to focus their collective energy, passion and time in order to improve their process and product. And almost always, the issue a compassionate and involved leader hopes the team will focus on is exactly what the team ends up discussing and moving forward with.

This isn’t just about the team taking responsibility for their work and their improvements, it’s about creating sustainable decisions the team can own.

Good team leaders and Scrum Masters create a space where teams can inspect and adapt safely and successfully, so they can continue to find ways to improve.

Last week, I ran our quarterly planning session and was very positively surprised with the results of testing Toyota’s A3 method in the meeting. Before the meeting, I was convinced that I was trying to “push” too much, but instead the team sucked them up.

Breakout groups at Rally quarterly planning

If you don’t know what an A3 or problem sheet is, I recommend starting with John Shook’s article in the MIT Sloan Management Review.

What is an A3?

John says in his article, “At Toyota, there exists a way to solve problems that generates knowledge and helps people doing the work learn how to learn. Company managers use a tool called the A3 (named after the international paper size on which it fits) as a key tactic in sharing a deeper method of thinking that lies at the heart of Toyota’s sustained success.”

An A3 is a problem sheet in which the owner attempts to:

1. “Establish the business context and importance of a specific problem or issue

2. Describe the current conditions of the problem

3. Identify the desired outcome

4. Analyze the situation to establish causality

5. Propose countermeasures

6. Prescribe an action plan for getting it done

7. Map out the follow-up process”

There is much more information on this topic on the Lean.org blog.

Introducing A3’s to the Rally team

At Rally, we started using A3’s to diagnose issues due to growth and market maturity last summer.  I hired a trainer and friend from my US WEST days Jay Arthur and focused our first effort on product marketing and product management.  In that three-month effort, we had very positive results from working 4 simultaneous A3’s and built a well prioritized backlog of countermeasures.  We knocked off the highly feasible and highly effective ones that next quarter, but we continue to work off that list today.  After product marketing and product management, we brought the technique to operations team, too.

Given this foundation and 25% of our team trained on A3’s, we brought them into quarterly planning as part of our rock prioritization process. Jean and others warned me that it was a ton to grasp in fully packed day of checking the last quarters results and adapting for the next quarter. For that reason, I was prepared to fall back to our old way of working and prioritizing.

Homework is good?

What happened was even more than I could expect. Instead of throwing out this process, the team embraced it and even worked through breaks. Using A3’s to structure your thinking requires discipline and critical thinking.  I guess there was more pull waiting in the room than I expected; maybe it was the required reading of John’s article that helped?  My conclusion – homework is good?

As Jean and I continue to explore what makes an Agile organization, I am curious as to what others are using in their business planning processes to prioritize their quarterly or annual efforts.

About the Author: Ryan Martens is an avid outdoorsman, founding board member of the EFCO, and Founder and CTO at Rally Software Development. Subscribe today to get free updates by email or RSS.