Ah, Marketing.  Enter a world of countless project requests, numerous stakeholders, limited resources and rapidly changing market conditions.

Sound familiar?  In fact, marketers face a lot of the same challenges as development teams, and Agile can be a powerful way to alleviate those common issues and intelligently plan our work.

In steps 1-5, I’ll explain how Rally’s marketing team conducts our version of Release Planning.  In steps 6-10, I’ll explain how we run our iterations to meet those commitments. Our planning processes continue to evolve, though this method has worked for awhile now.

10 Steps to Successful Marketing using Agile and Lean Practices

1. We recognize that Marketing has challenges that are different from Development.

• There is no unique product owner.  For example, if we chose Sales, then we would always rank lead generation over branding, customer programs or analyst relations, and that could ultimately hurt our company. Therefore we have to use some best-guessing to prioritize our backlog and determine what is most important.
• We face hard event deadlines set far into the future.  Sometimes we have no choice but to commit to an event or sign a contract months ahead of time.
• Each team member has unique expertise, i.e. writing, event planning, PHP development and so forth.  So one shared backlog is inefficient.

Now that we’ve reviewed the challenges, we give ourselves permission to do what we need to do, have patience and adjust anything that isn’t working for us.

2. Conduct an ORID to learn from the past

Before planning for the next quarter, we hold a retrospective in the form of an ORID, “a means to analyze facts and feelings, to ask about implications and to make decisions intelligently”, a process created by the Institute of Cultural Affairs.  We gather as a team to share:

• Observations (O) – What do we know?
• Reflections (R) – How do we feel about this?
• Interpretations (I) – What does it mean for the organization?
• Decisions (D) – What are we going to do?

This strategic overview helps set context for us to prioritize our focus for next quarter.

3. Align ORID decisions with company strategy

At Rally, we conduct quarterly and annual planning using the Plan Do Check Adjust methodology as explained in Getting the Right Things Done.   As we look at the overall company direction and goals, we keep these in mind as we hold planning at our own level.   Ideally, our major commitments support and align with company strategy. This also helps inform our “stop doing” list.

4. Poll our stakeholders

As part of determining quarterly commitments, we poll our major stakeholders for their top requests.  We use a Google survey to rank these requests by importance, size each request and bring these epics into our release planning meeting, to be included as part of our ranked backlog.

5. Conduct Release Planning to prioritize and agree on quarterly commitments

Now that we have all of our inputs, we hold our quarterly Release Planning session.  We write each epic on a sticky note and look at all of the possible work we could do this quarter.  Then, we evaluate epics based on importance taking company goals, stakeholder wishes, market realities like conferences and our own passions into consideration. We decide what we can realistically commit to, and agree as a team.  We keep in mind that making and meeting commitments is a huge deal, and we try really hard not to over-commit.

Part 2 – Meet our Marketing Commitments

6. Create a task board

Since our marketing team is mostly co-located, we pin up several large sheets of paper to use as a task board.  This is where we review our commitments on a daily basis as a sanity check that our stories are prioritized correctly and that we are tackling the right work as the quarter progresses.

As a team, we write our quarterly commitments on the task board with the definition of done assigned to each one.  We also include our “foundational” work – recurring work like website updates, online ad campaigns, field events, press releases and other important work that we need time to do.

Note: this is not a Kanban board because we do not have a shared backlog nor do we have a team-wide WIP limit.  As we break into smaller project teams that do share a backlog, we often use AgileZen to manage this work.

7. Hold iteration planning every 2 weeks

Every 2 weeks, we hold an Iteration Planning meeting.  Each team member has her own sticky note color, creates stories on those notes and manages her own prioritized backlog using T-shirt sizing to roughly estimate each story.  In this hour-long meeting, we begin by expressing appreciation for team members who gave exceptional assistance.  Then we hold a brief retrospective on what worked and what should change for the next iteration.  Finally, we each read out our prioritized stories for the iteration, putting them on the task board’s backlog.  This gives everyone visibility to what’s happening, identifies if someone is over-committed and lets the team swarm any epics with looming deadlines.

8. Conduct a daily stand-up

At the same time each day, we hold a stand-up meeting (with a consistent conference call #) that is at most 10-15 minutes long.  We form a semi-circle in front of our task board and share no more than 2 cross-cutting significant actions or take-aways from the day before, no more than 2 that we are planning to accomplish that day, and whether our work is blocked by any issues beyond our control.   As we start working on stories throughout the iteration, we move them from the backlog into their section of the task board to show what we are working on.  When the story is complete, then we move it to a place on the task board labeled “Done”.  Once the commitment’s Definition of Done is met, we check off that commitment and feel good about completing it.

9. Be patient as things change

It would be lovely if nothing changed during the iteration, but that just doesn’t happen.  The goal is ultimately to respond to change rather than cling to an outdated plan.  As new opportunities arise, new time-sensitive information appears and new requests are made, so our iteration work changes and that’s ok.  We try to just document what we’re working on and create new stories so that we can make intelligent prioritization decisions during the course of the iteration.

10. Retrospect, inspect and adapt

As we keep running our iterations and fulfilling our commitments, we are always looking for ways to improve them.   Ultimately, we’re using Agile to improve the quality of our work life by using objective, smart ways of planning how we spend our time. And we’re learning a lot from the journey.

Here’s something obvious I’ve learned the hard way: delivering “potentially shippable product increments” each and every Sprint isn’t easy.  Essentially you’re trying to take all the disparate activities that occur throughout the waterfall process, focus them on just the little product increment’s functionality and then jam them into a teensy little Sprint.  Hard to do and definitely pretty unlikely to get accomplished right out of the chute. The authors of “Practices for Scaling Lean & Agile Development”, Craig Larman and Bas Vodde, forgive you in advance for not getting this done straight away. In fact they suggest that this is more a goal the team will approach over time than a rule they put in place on day one.

The authors propose something very simple but very insightful:

• Sketch out all the things you need to do to get your product out the door.
• Define “done” as that subset of those the team is currently capable of performing every Sprint.
• Use your retrospectives to challenge the team to bring more and more of the “undone” work into each Sprint.

This has already changed the way I think about retrospectives. For other nuggets from Larman and Vodde’s book, read on.

Overall a Must-Read for Agile Development Leaders

I was blown away by “Scaling Lean & Agile Development”, as you can see from my bullish review on O’Reilly.  Some time has passed since then but I still feel that it’s one of the most important development books I’ve read.  That book alluded to the companion volume, “Practices for Scaling Lean & Agile Development”, and as you can imagine I awaited its publication eagerly.  It came out in February – I’ve worked my way through it now.   It’s most definitely a worthy successor.

The first book presents theoretical and philosophical underpinnings for agile and lean development. The second book presents a survey of practices relevant to all aspects of the process of developing software at scale, presented by two guys who bring a wealth of knowledge and experience to the table.

Continual Investment in Requirements

Larman and Vodde present practices relevant to a continual investment in requirements throughout the product development process. This is done both up-front, in seeding the product backlog, and iteratively, in refining requirements to support upcoming Sprints.

I love the emphasis they place on whole-team involvement in the initial Product Backlog development effort – even for projects with large teams.  Too often I’ve seen this be the provenance of Product Owners, working in near isolation, which does little to get the project off on a good footing.  The first the team sees of the requirements is the Product Backlog itself, having been involved in none of the  discussions and thought that went into it.

The notion of requirements areas, which was introduced in the first book, is leveraged here to help parallelize the initial requirements development work.  Concurrent sizing and value estimation workshops keep the requirements work rooted in reality.  They spend some time on the problem of bootstrapping a consistent sizing process in a large scale team. The use of cross-team estimation sessions result in the development of a canonical set of sized stories used as a basis for subsequent sizing at the team level.

In Favor of Forward-Looking Requirements Refinement

The discussion of forward-looking requirements refinement really resonated with me. I’ve found in my own practice that peeking ahead at the Product Backlog items upcoming in the next Sprint and then spending time together working through them to understand what they really mean – before we get into the Sprint planning session – goes a long way towards supporting a predictable iterative process.

It also puts the requirements elaboration just barely outside the Sprint that the work is planned for.  This separates coming to an understanding about what we want from the stress of figuring out how to fit it into a Sprint, which makes for more open and enjoyable requirements development.  The authors suggest the use of examples and Acceptance Test Driven Development (ATTD) to more precisely capture the intended behaviors of the stories in a way that realizes both conversation and confirmation of the “three Cs” . Smart.

The authors show how traditional approaches to project scoping and commitment (where separate product management and development organizations act essentially as competitors) are very much analogous to the contract negotiation that the Agile Manifesto cautions us against.  I’m surprised to admit this never occurred to me – I always read that part of the manifesto pretty literally. But it’s inarguably true that the wrangling between these two groups over project scope and timelines that happens in many organizations is a form of contract negotiation, and the waste it drives can be startling.

The arm wrestling of the product management “market ask” captured in a Market Requirements Document followed by the team’s “development response” carefully defined in a Product Requirements Document is a case in point.  Weeks and months can go by during this ritual.  What are the development teams doing during this time?  Not at lot, in my experience.  Does development really “win” if they manage to push out the end date or reduce scope?  Does product management really “win” if they manage to squeeze in extra features or pull in the release date?  I’ve seen how the empowerment of the Product Owner and the establishment of the Product Backlog as the single high-level requirements and release scoping artifact helped to prevent some of these painful dysfunctions but I’ve never thought of them in terms of an imbalance of contract negotiation over customer collaboration.

Creating “Desire Lines” in Design

Larman and Vodde strongly advocate wikis as the preferred basis for the technical documentation the team develops.  They suggest a page for the overall product and pages for each Sprint. That worked for my teams as well, although there was always a certain (healthy) tension regarding what was appropriate for Sprint documentation and what should be living documentation at the product level.

They present the compelling idea of “desire lines”, which, in landscaping, refer to paths that develop naturally, as people use a given space.  Rather than guessing how people would use the area, they are observed using it and then the landscaping is designed around their actual usage.  Similarly in design, rather than trying to guess what the needs are, let them emerge and then refactor to support the emerging design tensions.  A lovely analogy, I thought, and one that will stay with me.

They suggest both a priori design in collaborative design workshops and design after the fact in System Architecture Documentation (SAD) workshops.  I like the acceptance that both approaches are going to be useful. The former stresses the need for team contribution to the design as the Product Backlog items are being developed, while the latter recognizes that team needs for technical documentation will emerge over time and so setting time aside to fine tune design documentation is both warranted and healthy.

The authors also address the question of whether and when to rewrite code – like Joel Spolsky, I personally favor refactoring to improve legacy code rather then re-engineering.  The authors present a compelling and complementary argument for refactoring and incremental improvement based on the value of instilling a notion of continual (rather than punctuated) improvement in the development teams.  They stress that the real problem isn’t the legacy code you’ve got but rather the legacy code you continue to write.  Encouraging the team to have a mindset of each check-in leaving the code base better than it was before – fixing the broken windows and taking out the trash – is a better solution to the problem of poor code quality than is carving off large sections of time for exclusively improvement-oriented work.

Acceptance Test Driven Development

The book’s worth it just for this material alone.  Larman and Vodde present a wonderful analysis of ATDD and characterize its place in the context of Scrum, including tying it into iterative requirements refinement, the Definition of Done and the Sprint Review.  I’d seen teams go in this direction driven largely by the desire to better engage testers in their teams throughout the Sprint and avoid “scrummerfall.” The authors take this further to show how ATDD, in which acceptance tests are defined and automated in advance of the development of the code that will pass those tests, does for teams in an iteration what Test Driven Development (TDD) does for individual developers in ten minutes.

They stress the need for the test automation to be a distributed responsibility shared by the whole team rather than one assigned to a specialist team.  I couldn’t agree more.  I’ve seen many attempts to establish test automation through the creation of a group apart from development and I can’t say that I’d call any of them particularly successful – at least not in the broad and encompassing sense that Larman and Vodde are envisioning in this book.

Continuous Integration at Scale

I was particularly glad to see treatment of Continuous Integration (CI) at scale. I’ve seen groups start with vanilla CI as it is described in the Extreme Programming literature and do well with it initially but then fail as their groups grew larger.

Essentially, Larman and Vodde propose a nested set of continuous integration builds, each larger one subsuming sets of smaller ones within it and each build defined for a particular concern.  Examples of these concerns include the verification of specific components and subsystems but also particular kinds of testing – including things like performance and stability testing.  One key aspect of this approach is that, at each level, you’re trading off the immediacy of feedback to the developer against the likelihood of the developer’s submission affecting quality at that level and the expense of the tests.

The Elusive Definition of Done

As noted earlier, Larman and Vodde,  suggest defining “done” as that subset of the work needed to release the product the team is currently capable of performing each and every Sprint – then use your retrospectives to challenge the team to bring more and more of the “undone” work into each Sprint.  The authors point out that there are really only two ways to extend the Definition of Done:  increase the cross-functionality of the team or increase the degree of automation the team uses.

In the meantime, however, while the Definition of Done leaves some work undone, Larman and Vodde suggest meeting that problem honestly, by doing things like defining an undone work team and pushing undone work onto the Product Backlog.  By being explicit about where the team currently stands against the goal of delivering potentially shippable product increments, this undone work can be better managed and the team’s insights can be directed to the problem of expanding that definition of done to get them closer to the goal.

For the Bookshelf of any Agile Team Member

The book isn’t without its faults.  It’s certainly long enough and some sections can be tedious (there’s a fifteen or so page section where different scenarios for story splitting are laboriously addressed – I get that this common complaint about stories needs to be put to rest but this feels like killing me with kindness :)).  The book’s organization lends itself more to use as a reference than as something you’d read cover to cover.   There are many repetitive sections that allow each chapter to stand on its own but are a bit hard to get through when you read it straight through.  But these are really just quibbles.  In all, “Practices for Scaling Lean  & Agile Development” is, just as its companion volume before it was, a tremendous book that belongs on the bookshelf of any agile coach, manager or team member.

I’d like to thank Anne Greenhaw and Selaine Henriksen for their help in developing this post.  Thanks also to Ryan Martens for inviting me to post here.

About the Author: Ed Willis has been a ScrumMaster, Product Owner, Scrum coach and trainer.  He is currently a developer in the telecommunications industry.

Managing the right goals in software development can have a major impact on your team’s success. You get what you measure. In this regard, the goals you choose can be a defining factor in whether your organization’s Agile adoption thrives or dives. So, what are your choices?

A story about goal-setting

Imagine you are a runner. You have a running coach defining targets for you. Your coach chooses miles and seconds in order to measure you. These metrics turn out to be useful; they are universally understood by you, your coach and your competitors. That’s a good thing. A target goal exchange around these metrics might look like the following:

Coach: “I need you to run a 2-minute mile.”

You: “Uh, I’m not sure I can do that. In fact I don’t think it has ever been done before by any land animal other than a wildebeest, a pronghorn antelope or a cheetah. And, I’m not a wildebeest.”

Coach: “You’re not listening. I already told Sports Illustrated you will. Don’t make me look bad.”

You: “Seriously I’m pretty sure that’s just not humanly possible. I’m no Usain Bolt and I’m not sure even he could sustain a 2-minute mile.”

Coach: “Hey, I set the goals. Run that mile in 2 minutes. Just hunker down and work harder. 2-minutes is the target goal. If you don’t meet it, I’m kicking you off the team.”

You: (muttering under your breath to self, “I can’t do it, you aren’t listening to me, and you are a moron. Why do I even bother to open my mouth?”)

Why goals matter

Get the idea? I’ve been reading John Seddon’s Freedom from Command and Control: Rethinking Management for Lean Service. My colleague Alan Atlas recommended the book. Then my manager Ryan Martens became very interested which led to a book appearing on my desk. Soon after, Karl Scotland mentioned it in an informal conversation about Lean and Kanban. Time to pop it to the top of my reading stack!

Seddon sets a context about Purpose driving Measures that then drive Methods. The combination of purpose and measures start to look like goals. And Seddon breaks goals into two types: Target Goals and Capability Goals. While John’s book is not specifically about software, I could see how we use and abuse goals in our software world. So I decided to delve deeper.

Target goals are arbitrary and doom-laden

Target goals are set to measure hopeful results, often an arbitrary number. Think about our runner story and the 2-minute mile. That target goal was  set by someone else. A target goal typically does not account for your strengths, capabilities , availability and skills. Target goals don’t serve you. They don’t serve organizations either. And yet we cling to them. Consider if, as a developer, I hear the following from my manager:

“Jean! You missed the release deadline we gave you. We told marketing and sales who then told our customers that dev would deliver this specific functionality on this specific date. You’re ruining everything. We’re doomed I tell you, doomed! And all because YOU didn’t hit YOUR deadline.”

Uh, it wasn’t my deadline. And yet, missing that goal is now rippling negatively through the organization. This is a lose-lose situation all due to expectations hinged to an arbitrary target goal.

So why do target goals exist?

In many hierarchical, command-and-control software organizations, target goals are how deadlines are set. As Seddon points out, use of ineffective target goals usually arises due to an impossible purpose coupled with non-value add methods. The measures (or goals) are meant to drive teams to the impossible purpose. A command-and-control organization believes that goals must be set top down. The negative impact of these goals is inextricably woven into unrealistic expectations, death marches, and non-value add methods for controlling the work toward the goals.

Enter the capability goal

Let’s replay the runner scenario again.

Coach: “There is a race coming up, a half marathon. That means we need to start training now. What is your time currently?”

You: “I haven’t been really running lately. Rather than guess my times, I’ll start running now. Do you want to know in terms of how long it takes me to run a mile, or how far I can run in a specific timebox?”

Coach: “Let’s start with how you finish a mile. What is your typical way of getting going?”

You: “First, I do a walk/run combination. Then I can give you my actual mile capability in a week.”

Coach: “Okay, let’s set up a plan and together set some sort of goals based on your capabilities. That will help me guide you and figure out when we are faltering. I know you can do this. I’m going to work with you starting right now.”

You: (muttering under your breath, “This is amazing; yea me! I am going to finally put my passion for running to work, keep improving, and run my first half marathon. I love my coach!)

Capability goals are based on real data

Together, the runner and the coach watch the capabilities of the runner to define goals. The purpose of the goal is clear. Measures are set up that usefully help determine the runner’s progress. The method (or running regimen) for attaining the goal is then applied. Simple.

We use this same approach in Agile teams. A team lead or project manager does not set an arbitrary target goal. Rather, the Product Owner sets an overall purpose/vision. The Agile lead, often referred to as the ScrumMaster, works with the team to assess what goals can be reached based on a team’s capabilities and availability. From iteration to iteration, the team provides feedback on what it is able to complete based on its capabilities. The Product Owner absorbs this information and sets expectations outside the team. The process of continuous improvement continues. The team declares, “Based on what we tend to complete, and given the purpose from the Product Owner, we are going to improve our methods in the following ways.”

When good capability goals go bad

There’s a Gary Larsen “Far Side” cartoon of an open refrigerator with a bowl of glop inside holding a gun. The caption? “When good potato salad goes bad”.

Unfortunately, I’ve seen good capability goals go bad in a number of organizations. Listen to this conversation:

Program Director: “I see that our Agile teams are all now using these things called story points to track their work.”

Me: “Yes, it’s working well. Each team has a good sense of what it is capable of delivering iteration over iteration. That helps me figure out how to help remove impediments, where bottlenecks are, and where any team may need us to better resource them. It’s great!”

Program Director: “Hmmmm.”

Me: (muttering under my breath: “That ‘Hmmmm’ just doesn’t sound good. I think I’m about to get sick.”)

Program Director: “So, what’s the highest story point commitment a team has made?”

Me: “27.”

Program Director: “Great!  I’m setting 27 points as the target goal for all teams to commit to for each iteration. Every point will represent 3 hours of work. This precision will help me calculate exactly what we’ll deliver when. Plus, I’ll know which teams are really working and which ones are slackers.”

Me: “Hmmmm.”

Program Manager: “So, let’s get out there and commit! This Agile stuff is great!”

Me: (muttering under my breath, “We’re doomed, I tell you doomed!”)

What just happened must not be allowed

As you roll out your organizational Agile adoption, you’ll encounter many challenges. Pay attention to the usefulness of capability goals. Insist on using them.  Non-Agile organizations won’t like this. At times, you may feel like Sisyphus pushing a rock up hill for all eternity. Be strong. Don’t allow Agile measurement abuse. Create team and organizational trust.  Remove target goals and embrace the incredible value of capability goals. And, don’t allow any backslide. Don’t let your capability goals devolve slowly into target goals in sheep’s clothing.

You: (muttering under your breath, “You know? This MAY just work. Capability goals versus target goals. For the sake of my team, our organization, and the value we deliver to our customers, I’m going to do it!”)

Yesterday, the Agile Journal posted their May edition of the online publication with the above focus.  To support their release, they asked us to share our opinion on the topic.  Here is our response:

Ryan Martens: Age of Reconsideration, Reform and Regeneration

The last decade marshaled in a new empirical way of working with increasingly complex, interconnected and highly-critical software-based systems – Agile.  We are entering a period of reconsideration, reform, and regeneration in software, systems engineering and project management.  Agile is working, Lean Software and System is working, and the combination is starting to prove very powerful with regard to throughput and workers.  The benefits of autonomous work, engagement and mastery are driving systemic improvements in our way of working and growing to meet complex challenges of our world.

These results illuminate a future vision that has the potential to expand our current notions of Lean and Agile from software teams and into real organizational agility.  As a result, there is a chance to unite and unify many communities under the guiding ideas of flow, pull, and value.  All of these communities are being drawn in and starting to play well.  These are beautiful days with all the implications to CMM/SEI, Agile, Scrum, Lean/LEI, and PMI/PMBok communities yet to be determined.

In the first half of this decade, look for collaborating across boundaries, seeing larger systems and groups working hard to create their future realities.  Following that period, look for messy consolidation as the winners of this new platform emerge for a new golden age of networked, software product and system development. Together we’ll be focused on the problem domain of global scale difficulties in governance, cyber-warfare, energy, water, communication, commerce, medicine, climate, transportation and nano-technology.

Ryan Martens is an amateur triathlete,  founding board member of the Entrepreneurs Foundation of Colorado, and CTO at Rally Software Development.

Jean Tabaka: Let the System Talk

Thinking about our path with Lean, I’m compelled to draw upon research I’ve been doing in Systems Thinking and, more recently, what I’ve been learning in Systems Engineering.

In Systems Thinking, we recognize a world of system archetypes based on the dance of balancing loops, reinforcing loops and the outside agents that may cause them to transition. Lean, as a system of thinking, has certainly responded to systems that rely too much on take-make-waste. A set of negative reinforcing loops: the more you waste the less you have to take and make. Outside agents, the scarcity versus abundance of materials, has led us to Lean. Lean principles and practices create a positive system wherein the more we reduce waste the more value we get which in turn reinforces more waste reduction. It is a reinforcing loop propelled by continuous improvement.

Recently, I attended the Lean Software and Systems Consortium’s 2010 conference in Atlanta. What a revelation. From James Sutton’s talk on Lean Systems Engineering, I added new vocabulary that I think will become critical to Lean’s future.

Will Lean be our best source of practices and principles in the future? That depends on what will be guiding our systems:

• Scarcity
• Abundance
• Desperation
• Conformity

Once we have clarity about what guides our system, we can understand more about the system in which we are operating:

• Simple
• Complicated
• Complex
• Chaotic

Lean has steadfastly addressed pressures of scarcity and hence a system of complexity. That brings me to Dave Snowden’s work captured in Cynefin, a Welsh word he has used to describe a framework of problems, situations and behaviors in these four systems. For our world of complex systems, Lean provides the perfect high-level thinking for what we must embrace: emergent practices informed by, as Snowden puts it, “sense-making”

As we move into the next 10 years of Lean, I fervently believe that our sense-making must inform us about what supports emergence that responds to complexity. The practices will follow. For now, let us concentrate on the systems in which we operate, what outside agents or pressures are guiding our systems, and how we can best continue to formulate and hold dear the practices that will naturally emerge.

Jean Tabaka is a wine enthusiast, author and Agile Fellow at Rally Software Development.

Last week, 10 of us from Rally product development, sales and coaching attended the Lean Software and Systems Consortium’s 2010 conference in Atlanta.  For me, the learning highlights of the conference were in the Systems Engineering track  led by James Sutton. To kick-off his talk on Lean Systems Engineering, James used a number of compelling stories around different systems and what guide them.  As part of his introduction to systems, he played this hilarious Dave Snowden video about how you plan or act based on one of 3 systems in which you might find yourself -- Chaotic, Ordered and Complex.

www.youtube.com/watch?v=Miwb92eZaJg

David Snowden -- Cognitive-Edge -- Ways to Plan a Party

James, a Systems Engineer, Principal with Lockheed Martin, is an invested member of the Lean SSC board as well as a technical advisory member.  He is the deepest expert that I have ever met in the field of systems engineering. And he has a wonderful gift for bringing multiple resources to bear in helping people understand and care about systems. For a Civil Engineer and Computer Science major like myself his talk and track were the definition of a prop-spinning geek nirvana.

Systems are guided by the pressures that form them

The point of view that James imparted on us was to understand that there are fundamental systems in which we operate. They are not value-based; one is not better than the other. They just help us set context and inform us about the world around us. Why should we care about this? How you approach your product and project development depends on which system  you find yourself in. And, as it turns out, the system you find yourself in is largely guided by one of four compelling pressures. That is, you will recognize the system in which you operate based on what is driving you to act.

There are four fundamental pressures that guide us: abundance, scarcity, desperation, or conformity. And each leads to a different system context. To illustrate this, James led us through the story of four different nations following the second World War.  Each nation, responding to different drivers, led to advances in different types of systems management approaches in use today.

• United States -- Abundance -- Systems Engineering

• Japan -- Scarcity -- Lean

• England -- Desperation -- Chaos Theory

• USSR -- Creativity and Conformity -- Patterns of Inventiveness
  

The Four Systems

Given this sense of what guides particular systems, James explained that we live in a world of four fundamental systems: Simple, Complicated, Complex, Chaos.

Cynefin

Once you recognize what system you are in, you discover what principles and practices will best serve you in that system. But systems tend to not be static. So, James presented what agent or pressure might cause you to move to a different system and therefore what tools and practices would guide your thinking and actions for transition.

For instance,  if you are in a Simple system and are moving into a Complicated system, Lean Manufacturing and Analytical Systems Engineering are your best tools and guides. If, however, you are in a Complex system verging on Chaos, you’ll work best relying on the perspective originated by Dave Snowden: Cynefin, the Welsh word for “the place where you hold multiple things.” Cynefin serves Complex systems well as it emphasizes emergent behaviors and, what Snowden refers to as “sense-making.”

The history and vision from this talk became almost a grand unifying theory for me. It all made great sense. If you are a  systems engineering fan, do not miss the recorded version of this talk when it becomes available.

Thanks Lean SSC

While 6 speakers and several attendees from Europe were prevented from attending the conference due to the Icelandic volcanic ash cloud, the Lean SSC rolled with the punches and pulled off an excellent event. The folks able to attend and the over 40 sessions offered created an electric buzz both in the air and on Twitter. Given the caliber of sessions, hallway discussions, and Open Space,  I am sure there will be many posts that emanate from attendees. And no doubt new ideas will be growing that were nurtured by the conference. Kudo’s to the Lean SSC board for creating a space for this excitement and emergence.

About the Authors:

My name is Jean Tabaka.

I live in an Agile and Lean world where we take a “stop the line” mentality for granted.  I am encouraged to give my observations and recommendations about continuous improvement. I’ve been learning to create my own reality, to continue learning and to find my strengths in cross-functional work. I passionately read about, talk about, and practice Agile and Lean principles. These principles continually inform how I can create benefit for my company and how I derive benefit from my company.

I’m the lucky Tabaka.

My father, Jim Tabaka, was a life-time white collar worker for GM, starting fresh out of University of Illinois with his mechanical engineering degree.  He worked 12 hour days, on his feet the entire time, walking the plant floor, making sure cars kept coming off the line at all costs. He retired at age 55 with a great pension and unbelievable health benefits.

My brother Tim Tabaka is a retired GM blue collar autoworker. Well, retired is the euphemism for, “Would you please leave early so that we can bring in a younger, less experienced, cheaper workforce?”  During his time at GM he worked any shift he was told to work. He even moved to a different, older plant. Why? He needed the job and they wanted to replace the older workforce with a cheaper, younger workforce.

My nephew, Andrew Tabaka is a current GM autoworker. He came in under-skilled and now works a night shift for a GM subsidiary building brake assemblies. Andrew is one of the people Tim trained on his way out. Andrew is 24 and this is his first job. I suspect he intends it to be his life-time job. Well.

I’ve never worked for GM but learned to drive a stick-shift on a Chevy Corvette (yes!) And, while growing up, my dad used to take me to visit the plant where he worked in St. Louis. The acres of parking lot outside the plant were for all the cars that had rolled off the line but could not be shipped to a dealer. Too many defects.

Get the picture? We have been and are a GM family.

And I’m telling you this for a reason.

In 1984, GM and Toyota entered into the NUMMI (New United Motor Manufacturing Inc.) agreement to co-run an auto plant in Fremont CA. NUMMI made big news at the time. It took an existing, highly dysfunctional GM workforce and turned them into one of the most productive auto plants in the US. A documentary about this recently aired on Ira Glass’s “This American Life”. What a story, too fantastic to be made up: the complete turn-around of a failing GM plant to a thriving joint venture. The documentary recounts 30 disgruntled, unmotivated GM employees traveling to Japan to work with Toyota employees to learn “The Toyota Way”. It features commentary from Jeffrey Liker (author of “The Toyota Way”) John Shook (author of “ Managing to Learn”) as well GM line workers and GM management. The power punch of the Ira’s story? GM never replicated the success at the NUMMI plant.  Several theories about this failure are postulated at the end of the documentary. It is up to the listener to form their own conclusions.

Two weeks ago, as a coda to the documentary:

The Fremont NUMMI plant had its last Corolla roll off the line. NUMMI was shut down, this time for good. It was the first factory ever shut down by Toyota.

I care both personally and professionally about that darn NUMMI plant. The Ira Glass documentary about NUMMI’s turnaround and GM’s failure to replicate struck a deep chord for me. I called my brother Tim that evening to get the real scoop. I had heard him recount what his life was like in a GM plant and I wanted to hear it from him again.

The truth is the NUMMI success DID have an impact on GM outside the Fremont plant. Prior to the NUMMI conversion, life in the Oklahoma City plant where Tim worked was miserable. As in the story “Rivethead” by Ben Hamper about GM plant life in the 1970’s, alcohol abuse, absenteeism and nervous breakdowns were common place at Tim’s workplace. He lived the life documented about the Fremont plant prior to the Toyota venture.

Life with the Andon.

In the late 1980’s though, Tim told my about how things were changing, amazingly so. A “stop the line” mentality was adopted at their plant. Use of an “andon” was introduced. One tug on the andon was the alert to call over for some help; a second tug was “stop the line” we need more time to fix this. Tim was one of the people who roamed the plant floor prepared to assist when the andon was pulled once so that it wouldn’t have to be pulled again. Every station had its own andon “song”. (Apparently the “Baby Elephant” song became the bane of my brother’s existence.)

Life was so much better (the “Baby Elephant” notwithstanding). Workers were encouraged to stop the line and fix problems versus pushing cars through. Teams were brought together to offer suggestions for how to improve the work processes and the flow within the plant. Quality went way up and defects went down. Morale and motivation went up. Alcohol and drug abuse went down (this is anecdotal from my brother, not based on an actual study.) And for Tim personally, plant life improved dramatically. The new system played into his strength: being a cross-functional team member, challenged and rewarded for doing his work.

Back to the NUMMI story and what GM ultimately adopted.

Fair enough. I have my brother Tim as an example of an autoworker who benefited (well, except for the darn “Baby Elephant” team’s issues). But I also have a father who, as a GM executive was expected to tirelessly follow and communicate the GM line. It took its own deep toll on him. And I have a nephew who continues to work as a very replaceable night shift cog in a different plant in the GM machine. GM has declared bankruptcy for any number of reasons. And now, my mother’s benefits, my brother’s pension, and my nephew’s pay are in peril.

My name is Jean Tabaka, daughter of Jim Tabaka, sister of Tim Tabaka, and aunt of Andrew Tabaka. My father never benefited from Lean thinking. My brother had a wonderful brief taste of it. And my nephew is now somewhere in an odd stew of Lean and non-Lean practices.

I’m the lucky Tabaka. Lean has brought me a lot and taught me a lot in my Agile world. While Lean may be most closely affiliated with the Toyota Production System; and while it may be assumed that failure to adopt the TPS was GM’s ultimate demise, I believe the Lean lessons have continued to grow, spread, and morph as a result of both success and of failure in Lean adoptions.

GM, Toyota (yes Toyota), NUMMI, the Oklahoma City plant and others all have their stories of success and failure. Each had their approach to Lean adoption. Like Tim Tabaka and NUMMI, we have our lessons to learn from Lean in our software world. Lean is not the panacea. The TPS cannot tackle all issues. Agile is not the panacea. No one methodology can guarantee product success in all situations. Our continued belief in checking the value of our adoptions is critical. Our conviction to pay attention to failure modes as well as success is key. If you don’t believe me, ask my brother Tim.

Today we announced Rally’s acquisition of AgileZen, a visual project collaboration tool that manages work using the Lean concept of Kanban. AgileZen is a simple, elegant project collaboration tool that supports software development by providing a Web-based Kanban board.

Our definition of Kanban

If you aren’t yet familiar with Kanban, there are lots of great resources out there. The simplest description we could come up with for Kanban and Scrum is in our press release, but we welcome your thoughts and additions:

Kanban literally means “sign board,” and in Lean it is the signaling tool for visualizing and tracking work as it flows through various stages of a process. A Kanban board does this by exposing bottlenecks, queues and waste in a process so that teams can deliver high quality, high value work. Both Scrum and Kanban methods focus on early value delivery, and both provide transparency into the work in progress.  But Kanban can operate with a different planning and delivery cadence than Scrum and emphasizes different metrics.

What does this mean for Rally and the industry?

We believe that Kanban is a simple but natural extension of Agile software development. It will invite more teams into Agile and provide more runway for mature teams. But most importantly, it will help us extend Agile beyond development teams to create an Agile business. The AgileZen team has been effective in all of these areas. We are in heavy learning mode and, at least in our view, the entire industry is still figuring out how Scrum and Kanban work together and which methodology is better fit for various projects.

Welcome Nate and Niki Kohari!

Nate and Niki Kohari, co-founders of AgileZen, have built the best Web-based Kanban board out there, and we have the utmost respect for their product, company and brand. We are incredibly excited for them to join our North Carolina office.

What does this mean for AgileZen?

First, you should read Niki’s blog post. Not much has changed for AgileZen users. Together, we’ll continue to support the AgileZen solution as a low-cost Kanban-focused project collaboration tool, and users can access support as they always have.  If you aren’t familiar with the AgileZen product yet,  check out their free product.

Join us at the Lean SSC Conference in Atlanta next week!

The Rally and AgileZen teams will present our products and coaching services at the Lean Software & Systems Conference 2010 in Atlanta April 21-23. Ryan is also speaking on Plan-Do-Check-Act. We look forward to seeing you there!

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. Jean Tabaka is a wine enthusiast, author and Agile Fellow at Rally Software Development. Subscribe today to get free updates by email or RSS.

On April 21 in Atlanta, the Lean Software and Systems Consortium will come together for its second US conference.  Last year’s event in Miami was “amazing” according to Jean.  So this year, Rally is exhibiting, I am speaking while Jean and Aaron are running the open space on Friday.  The price per attendee goes up by $250 on March 31st, so if you do intend to go, REGISTER now.

At our booth, Rally will be demonstrating its product support for highly-visible Kanban, WIP/Cumulative Flow reports, and cycle-time  metrics. Join Alan Atlas, Jean Tabaka, Aaron Sanders and Craig Langenfeld in our booth.

I will be presenting an experience report titled: PDCA: Beyond Simple Inspect and Adapt. On spring break this week, I’ve been thinking more about the details of my talk. Here is my abstract and outline for those of you who might consider attending:

Lean and Kanban focus on practices of continuous flow of product delivery. Plan-Do-Check-Act (PDCA) is a Lean discipline that moves beyond inspect and adapt of Agile team-level processes.  At a corporate level, PDCA provides guidance for strategy as well as problem-solving work. In 2009, I led Rally’s move to PDCA for the company’s strategy process at both the annual and quarterly levels.  My primary guide was Pascal Dennis’ “Getting the Right Things Done”. In this experience report, I share Rally’s PDCA first year of adoption: where we started, how this impacted our corporate behaviors, and where we are now. I want to share Rally’s story to compel participants to embrace PDCA and get good at it. I ask each participant to come with its organization’s #1 goal and success criteria. I will close with a planning A3 exercise from Pascal’s book .

Outline

1. What brought me here—background on why I am passionate about sharing my organization’s overall Lean story including the addition of PDCA, A3’s and concurrent set-based development.  This talk focuses on PDCA as the critical step in increasing structure and discipline in strategy execution.
2. Point of View – Use PDCA to move your planning horizon out and as the principle governing mechanism for organizations in continuous flow.
3. Benefits — Mature your strategic planning and execution environment to handle the complexity of increasing speed, agility and scale and to gain alignment, pull and innovation.
4. Where we were and what was not working
   1. The context at Rally was based on a couple of key concepts:
      1. Core Values, Core Purpose, Sandbox and BHAG from Jim Collins
      2. 3 to 5 Quarterly Rocks, success criteria and Scoreboards from Gazelles
      3. Rock team structures  – cross departmental and story based
      4. Facilitated, highly collaborative cross-departmental meeting of 30+ managers and above
   2. What we noticed
      1. Rock work as a second or third job
      2. Wisdom of the Crowds to help fix over-reaction and group think
      3. Too much on the fly, not enough backlog grooming
      4. Highly critical, non-cross departmental initiatives were de-prioritized
      5. ORID process added to keep from jumping too solutions, but the data was not visible enough
5. What we decided to do about this:
   1. Explanation of PDCA — A brief overview of PDCA in general and then specifically what I used as guidance from the Pascal Dennis book, “Getting the Right Things Done: A Leader’s Guide to Planning and Execution”.
   2. Our initial experiments with A3 process the year prior — Working with our Ops team and product marketing teams on problem solving using real data
   3. First quarter — How we kick-started Rally’s company-wide adoption of PDCA . I describe our “Mountain Team” and their transitional role.
      1. Defining Rally’s True North
      2. Creating our second level tree with current and needed metrics
      3. Socializing these throughout the company seeking feedback in anticipation of our annual and quarterly planning
      4. Started new experiments based on quarterly planning decisions
   4. Next Quarter – Review new experiments, discussed learning and drive A3’s into the planning process
   5. Mid-course adjustment by Mountain team, in middle of the quarter – What we discovered working and not working
      1. The rocks were all dependent on each other.
      2. Had to run Rock of Rock team meetings to steer to a final solution
      3. Coordinated release planning would have
   6. Final quarter – We worked to expand the plan. We took the Mountain team’s True North and feedback to drive our PDCA for Rally’s Annual Corporate planning by:
      1. 1. Taking company-wide feedback into our Annual planning to collaboratively drive cross-department A3 creation around each branch of the tree
         2. Mountain Team retrospective over the course of year 1 that helped create a planning rock team.  The Mountain team’s role as a transition team ended.
   7. Year 2 – Doubling down our efforts to go from amateurs to intermediates —Changing our process to institutionalize A3’s and PDCA as our strategy execution approach:
      1. Quarterly rocks moved to a world of pre-defined from developed on the fly
      2. Quarterly planning moved from ad-hoc based on yesterday’s weather to more programmed based on True North and meeting the target metrics
      3. Strategic planning worked to validate annual True North in the context of long-term planning, shared vision development, cross-boundary collaboration and larger systems
6. What we learned and what you should do about it
   1. The cycle of adoption is a year, quarterly cycles work to improve the process, but it is hard to make leaps on a quarterly basis.
      1. Year 0 – Introduce Lean thinking (A3 in our case)
         
      2. Year 1 – Introduce PDCA (Novice)
      3. Year 2 – Invest or abandon (Your choice)
         1. A3 is now the language for problem solving
         2. Making sure we are solving the right problem (aka slowing down to speed up)
   2. Do not have a overall guidance team steering the continued PDCA process – it is owned by the “team”
   3. Putting pressure on the organization to get more clear about our economic models to mature from “Theory-based decision making toward the right solution,” Now “Data-driven decision making toward the right problem”
   4. Where to start – The Strategy A3 an exercise
   5. What is next? – We call it the Innovative or Lean Organization. Seeing large systems, collaborating across boundaries and creating your reality.
      
7. Point of View – Use PDCA to move your planning horizon out and as the principle governing mechanism for organizations in continuous flow.
8. Call to Action – Introduce the language of A3’s through problem solving or Strategy A3’s
9. Benefits — Help build a company of problem solvers to focus your efforts on the critical few things.
10. Where I hope you go with this: Great companies build great software, great experiences and work on creating win/win scenarios.
    

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.

I’ve noticed a piece of advice repeated in many Agile blogs, articles, and books.

Seeing it makes me roll my eyes until it hurts. (Why I would hurt myself on purpose will be the subject of another post, on a blog reserved for psychotherapists.)

Even my very most favorite Agile book, “Scaling Lean & Agile Development” by Craig Larman and Bas Vodde, has a section in there with this advice.

I saw it in Jim Highsmith’s new book, too, although by the time he’s done discussing it he does make a couple of good points. It’s an old piece of advice that pre-dates Agile.

What is this old chestnut? Here it is:

Hire the best.

I mean, come on. Is this supposed to be a big lightbulb moment? Where do they find stuff like this, in the “Journal of the Totally Obvious?” Am I supposed to leap out of my chair, smack my forehead and exclaim “Eureka! All I have to do is hire the best! Why didn’t I think of that?”

Is this really good advice? Is it actually possible, or necessary in an Agile world? Is this sensible, if trite, piece of advice useful at all? Talk amongst yourselves while I blather on for a bit.

The problem with “Hire the Best” as an operational principle is that:

a) it immediately excludes most of us, and
b) it’s extremely difficult to do.

What’s the best? The top 5%? 10%? Certainly no more than 20%.

So what about the rest of us? What are we supposed to do? Are things hopeless for us? Should 80% of companies worldwide just give up and shut down because the top 20% of people are taken? What about big companies and the Law of Large Numbers? Can you really hire only the best when you’re hiring 10,000 or 20,000 people?

Something that makes much more sense to me, and which has much more power, is this idea:

Hire well, and develop people.

Check it out! Everybody can do this. “Develop People” is one of the two pillars of Lean, while “Hire the Best” is not. So far, those Lean folks have been right about pretty much everything, so why not this, too? Why would I need to develop people if I only hired the best? Why not save the money so I can pour it into my “Hire the Best” employment initiative?

The Agile Principles say something like […find motivated people and trust them…], and I believe in Agile. So I cannot find in the bedrock of either of my professional beacons, Lean and Agile, any indication that I should “Hire the Best”.

My common sense and experience tell me that it is incredibly hard to actually hire the best, and I like that it might not be absolutely necessary for success. How cool would it be to hire the ‘pretty good’ and then kick the butt of some company that thought it was hiring the best? Is that possible? Yes.

“Hire the Best” is really hard to do.

I’ve worked as a full time hiring manager at more than a dozen companies, all of which thought they hired the best and only one of which actually did. That company really worked hard at hiring the best. At that company, one rule of the hiring thumb was that you only hired people onto your team who would immediately place in the upper 50th percentile.

In other words, when you were on an interviewing team in that company, you were expected to vote to hire somebody who was better than half the people on your team. You think that’s easy? You think that isn’t scary? Try it sometime.

What I’m really really really interested in is something that can take my average team (and let’s face it, Ms. Wishful Hiring Manager, it is overwhelmingly likely that our team is average, for some value of average) and make it better or improve its ability to deliver value to my customers. That’s worth some effort to achieve because it is worth money to my business. If I believe in “The Art of the Possible” then I like this better, because it’s a lot more possible than simply hiring the best.

Anybody can embark on a long, expensive and likely unachievable quest to only hire the best, but if Agile were really valuable,  it would help me to take my team of competent professionals and make them significantly more effective than they were. It might even make them more effective than a gaggle of “the best” somewhere else.

The Agile Principles talk about motivated people, but they don’t actually mention “the best”.  I view this as a good thing because I strongly believe that the best teams are not built from a homogeneous mix of the smartest, fastest, bestest people.

Teams work best when they are diverse and when the power of the team can be unleashed by empowerment and self-organization. I also know from bitter experience how hard, and frankly scary, it can be to really hire the best. (Sorry if I harp on that, but I have scars…)

What I want is what I think both Lean and Agile offer to me as a businessperson. They offer me a way to take solid professionals and then ignite their passion and professionalism within a framework of continuous learning in a way that allows them each to contribute to the fullest extent possible.

That’s something that make Lean and Agile worthwhile to me, and not some lazy idea about hiring the very best (somehow) and then automatically winning.

About the Author: Alan Atlas is a Soul Musician, Certified Scrum Trainer, and Agile Coach at Rally Software Development. Subscribe today to get free updates by email or RSS.