In 2001, the Agile Manifesto was created with 17 signatories from around the world. Following on the heels of the first XP conference in Sardinia in 2000, the Manifesto fired its shot of agility across the Waterfall bow. A year later, at XP/Agile Universe 2002, I found myself standing at a folding table with Janet Danforth of Facilitator4Hire. We were selling facilitation services to the members of the Agile community gathered at a Courtyard by Marriott in Lincolnshire, Illinois. Approximately 80-100 people had come together in that steamy summer venue to continue Agile discussions and to define ongoing growth of methodologies, practices and frameworks.
Where we were
At the same time I was at my folding table in Lincolnshire in 2002, Ryan Martens was at a whiteboard in Boulder, Colorado. Ryan was brainstorming ideas about how he could use Agile practices to create a Software as a Service platform in the Agile domain. His goal? To provide zero-waste, low-carbon emissions applications and services for this growing, vibrant community.
In 2003, the Agile community gathered in Salt Lake City for the Agile Development Conference. This was my first time presenting at an Agile conference. Janet Danforth and I conducted a workshop: Collaboration 4 Agile Projects. And, unbeknownst to me, Ryan was also in Salt Lake City for his first Agile conference. As Ryan was busy engaging vendors about how they were supporting the adoption of Agile, I was busy networking with Agile thought leaders and helping to found “The Freaking Flock” (you’ll have to ask me about that in person!) Our paths were set and Agile was on the move.
Fast Forward to 2011
Now, in 2011, we are 10 years on from the Manifesto signing, 9 years on from the first sighting of me at the folding table, and 8 years on from Ryan’s first foray into the conference.
The Agile 2011 conference is an exciting one for both Agile and Rally. We are pleased once again to be a Title Sponsor of the conference. This year, August 8-12, Rally has 11 speaking sessions on the wonderfully vast and diverse program.
We’ve also participated behind the scenes in advance of the conference as producers, co-producers and reviewers for various conference stages. And, once again, we’ll have a booth where you can come to meet our Agile coaches, talk with our technical gurus, and see the latest that is happening with Rally’s Agile ALM platform and services. Plus, you won’t want to miss our special commemorative activity at the booth this year. Stay tuned to the blog and follow our Twitter hashtag #roadtoagility for more details on how you can participate with us!
Going back to my history of Agile and Rally and the conferences
Ryan and I never met at the 2003 conference. But in 2004, as the conference moved into the northern Rockies in Calgary, Alberta, 4 of us stood together at a folding table in a small hallway. Rally’s representation at that Agile conference was Ryan as President of the company, Richard Leavitt as our VP of Marketing and Sales, Brad Norris as our sole sales person, and me as the sole Agile Coach. At that point, none of us were speakers. However, Rally has had one or more speakers at each conference since: Denver in 2005, Minneapolis in 2006, Washington DC in 2007, Toronto in 2008, Chicago in 2009, and the 2010 event in Orlando. Additionally, Ryan served on the Agile Alliance board during the years of the Washington D.C. and Toronto conferences.
From the folding table to now
Some things have changed in Rally’s Agile journey. We’ve grown from a 20-person company in 2004 to over 250 people and counting. Ryan is now the head of the office of the CTO. Richard is now the Executive Vice President of Worldwide Marketing. Brad is our Vice President of Field Operations. And I am an Agile Fellow in the Office of the CTO.
From a Manifesto, a whiteboard, folding tables, and a single speaker to title sponsorship with multiple speakers, producers, reviewers, and booth presence in a true exhibit hall at a conference with over 1,600 attendees, we’ve indeed come a long way!
Jean Tabaka is a frequent flyer on no particular airline, an author and Agile Fellow at Rally Software Development. You can follow Jean on Twitter at @jeantabaka
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.
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-Incountered 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 Greekoxy (“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.
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.
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.
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
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.
Picture from Pegasus Communication - Leaders in Organizational Learning and System Thinking
A Two-Pronged Approach to Agile Adoption in a Recession
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.
RallyDev.com
Now, in 2011, we are 10 years on from the Manifesto signing, 9 years on from the first sighting of me at the folding table, and 8 years on from Ryan’s first foray into the conference.
Ryan and I never met at the 2003 conference. But in 2004, as the conference moved into the northern Rockies in Calgary, Alberta, 4 of us stood together at a folding table in a small hallway. Rally’s representation at that Agile conference was Ryan as President of the company, Richard Leavitt as our VP of Marketing and Sales, Brad Norris as our sole sales person, and me as the sole Agile Coach. At that point, none of us were speakers. However, Rally has had one or more speakers at each conference since: Denver in 2005, Minneapolis in 2006, Washington DC in 2007, Toronto in 2008, Chicago in 2009, and the 2010 event in Orlando. Additionally, Ryan served on the Agile Alliance board during the years of the Washington D.C. and Toronto conferences.
