Agile For Non-Software Teams: Three Steps to Get Started

I speak often with agile novices about the benefits and, frankly, beauty of being agile. It sounds good enough: Be adaptable to change; delivery value more consistently, work at a sustainable pace as a real team. Basically, the promise of agile is to fix everything that sucks about work. But then, there’s this leap. Agile was invented by and for software makers. The Agile Manifesto and Principles mention ‘software’ five times and all other forms of work output zero times. How do you practice agile when you’re not, as the preamble to the Agile Manifesto declares, “developing software”?

Step 1: Declare your rationale

A lot of teams decide to start practicing agile for flimsy reasons. This applies to software and non-software teams alike. Some of the common reasons I’ve heard are: Our management hierarchy told us to start doing agile; a book tells us we can do twice the work in half the time; everyone else around us is doing it. Those types of reasons are understandable and, in some case, arguable, but they miss the point. They don’t provide a rationale for why it would help YOUR team perform better. Have a team discussion and agree on the answer to this question: What benefit do you as a team expect to reap from practicing agile? If you can’t agree to why you are doing agile, it might not be a great idea right now. Whatever answer you come up with can be a core component of your mission or vision. If you can identify a metric that helps you quantify the benefit, you can make it the basis of a team goal.

Step 2: Define a story

In agile software development, stories (aka work items) refer to new features for software. If your output is not software features, an important first step is to define what you mean by a story with your product. In order to do so, you need to define what your product offering is and what a feature is. The instinct for many is to define everything that you do as a story, but that is a misguided notion.

For discussion purposes, take the example of a fictitious company called Super Bicycles, whose mission is to improving the design of their line of bicycles. There are all sorts of things that you do that do not improve the design of a bicycle. You have meetings, you hire employees, you pay employees, you pay the rent on the workshop, and a zillion other things. Those things aren’t stories; they are just things that you do. A story is something that you create that enhance the perceived or actual value of your product. Stories in the improved bicycle product backlog are only features that improve the customer value of Super Bicycles. That backlog of new product features is entirely focused on improving the bike's design.

Step 3: Decide where to start

From there a team is ready to really move towards agility. Typically a team can start with a list generated in response to the question: What’s the ONE most important thing to focus on first? Start a list and prioritize it. Many teams start their journey toward agility in a state of being overly busy, where everything is “really really important.” Remember that “important” is a relative term – if everything is important than nothing is important. Take your list of potential places to start and commit to tackling THE most important thing. Examine the assumption that there are things that have to be done before we can work on the most important things. Focus on the actual most important things. What could you do right now that will make the biggest difference? Start with that one thing and crush it. And don’t worry about all of the other most important things – they are, by definition, less important than the most important thing.

These three steps will help your team to find purpose with agile. Whether or not you develop software, your team will improve its chances of enjoying the rewards of higher productivity and quality that agile promises.