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.
