Entries tagged with “XP”.


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.

Blog Post by Tim Walker at Hoovers

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.


I have been told repeatedly that my brain thinks in pictures, and as a result I have to work hard to communicate my logic effectively in words. Recently in my argument against an Agile Process Maturity Model, I made a comment that Agile is an instance of Lean.

One of the replies on the Agile Alliance Group of Linked-In countered that my statement isn’t accurate – and in fact a team being both “Agile and Lean” is an oxymoron. So, I looked in the mirror and said this must not be clear. I need to communicate better in both words and pictures.

“The term Oxymoron originates from the Greek oxy (”sharp” or “pointed”) and moros (”dull”). Thus the word oxymoron is itself an oxymoron.”  Wikipedia’s Etymology for Oxymoron

Instead of trying to figure out which is sharp and which is dull, I thought I would present my mental model on the evolving Agile software development ecosystem.

Agile as an umbrella term

First and foremost, Agile as an umbrella term was hatched in 2001 to represent a “way” of developing software that is focused on rapid value delivery, collaboration with a customer, face-to-face communication and measuring progress in working code.  It casts a wide net of iterative and incremental process frameworks including RAD, Spiral, Extreme Programming (XP), Scrum, DSDM, Feature-Driven Development (FDD), Lean Software Development, OpenUP and Kanban. These methods stand in contrast to highly structured methods that tend to measure success based on meeting plans and following the process.

slide11

My rendition of the geneology of Software Development Approaches

Agile has evolved both bottom-up and top-down based on the evolution in technology infrastructure, tools and guiding ideas of our industry. It is symbolized by increased productivity, speed to market, response to change and craftsmanship.

I believe it is not a fad, but a natural by-product of the increasing scientific as well as craftsmanship approach brought to this critical industry.

Lean merges with capital-A Agile

I see the pictured genealogy tree merging Lean software development methods together with capital-A Agile methods. This is because the physics behind Lean design and production are the same physics that make Agile deliver impacts like we see in the Agile Impact Report from QSMA – 50% faster time-to-market and 25% increased productivity.

Though the principles of the Agile Manifesto do not sound like the principles of Lean, the patterns are the same. (For a great overview of Lean software do not miss Corey Ladas’ guest post on Shaping Software.)

  • Small batch sizes, short cycles that create rhythm
  • Reduction in queues through pull
  • Reduction in work in process inventory
  • Design quality in
  • Stop-the-line defect control
  • Value streams the link to the customer
  • Integrated learning through reflection
  • Last responsible moment decision making

These patterns are the same for an effective Lean effort or an effective Agile effort. This thinking has me advocating that Agile is an instance of Lean, not just a ground-up new tree that was born solely from the roots of OO, Spiral and RAD.  I am having a hard time seeing the black and white separation between agile and lean. This is all grey, maybe I should say blue and red based on the diagram, to me. 

What do you believe – is Agile is an instance of Lean, or together are they are an oxymoron?

I’m live here at the LA Agile Success Tour with the success stories of our panelists. In my next post, I’ll cover the Q&A.

Israel Gat – Cutter Consortium member on Agile, former VP from BMC, IBM, Microsoft and EMC

  • Software is becoming pervasive in our lives. The key will be how we align the functionality of that software with what the customers actually need, not our guesses about what we think they might need.
  • A key component of this is agility in the process between developing software and getting that value into our customer’s hands. He used Flickr and IMVU as examples of the power of using constant deployment as a method to effortlessly deliver software, and ultimately value, to customers.

Chris Babcock – VP of Technology at Real Capital Markets

  • Introduced to Agile in 2000 as a reaction to his “death march” experience at another company, where his team worked 100-hour weeks. He moved into a development management role and took on the goal of delivering projects on schedule, in a way that was healthy for the team. One of his development leads discovered the XP methodology and they never looked back.
  • Tracking project metrics was an important part of his role at one company. He shows empirical evidence of the benefits of Agile. With waterfall, time = 31 weeks, 16 critical defects and 153 stories. With Agile, time = 19 weeks, 0 critical defects and 234 story points. He was most proud of 0 critical defects into the market.
  • Benefits from Agile – faster development, more manageable codebase, fewer defects. Industry average is 15 to 50 bugs per 1,000 lines of code. With each release, through refactoring and Agile development, they are decreasing the size of their code base. Yes, that’s right, more features, with higher quality, with 100,000 fewer lines of code.

Laureen Knudsen – Sr. Dir. of Program Management at Qualcomm

(more…)

This last week I was with a number of our extra-large customers and prospects.  A common theme with these large and very successful high technology companies was the statement “growth hides all issues.” 

When we are growing rapidly, we all tend to focus on investment and hiring just to keep up and not limit the growth.

I remember this same feeling at BEA Systems in 2001 as the tech bubble popped. In our Boulder office, we found ourselves staring at 10 times more people than we started with in 1999.  Even though we took Extreme Programming (XP) teams into that growth, we ended up with a 100+ person and multi-location, waterfall process.  Our team reacted by putting back in XP engineering practices and large-scale, nightly, integrated builds to increase visibility and feedback.

zero-sum-thinking

Picture from Pegasus Communication - Leaders in Organizational Learning and System Thinking

A Two-Pronged Approach to Agile Adoption in a Recession

What is critically different about Agile adoption in this recession is the need for a two-pronged approach. In December, I wrote for Tech Target on two-pronged approaches to cutting budget while implementing Agile development. This is a systems thinking approach that is effective at breaking myopic thinking.

I was thrilled to see this approach used in the President’s stimulus package – short-term tax cuts to stimulate and provide relief coupled with future-looking government investments in more sustainable and equitable infrastructure. Without this type of approach, myopic thinking tends to increase the chances of “Fixes that Fail.”

It was a really good week last week.  As a result of this positive feedback, our team is going to devote a substantial amount of blog space during early 2009 to covering the strategy, approach, myths, and success stories around the use of Agile development to cut costs and simultaneously prepare for future growth.

Please stay tuned, link back your stories, comment, subscribe and consider your actions.

Further Reading: