As agile ways of working become more and more popular, many newcomers mistakenly believe that they are only suitable for products, and not for services.
This, along with the belief that agile is only for software development, is one of the two biggest misconceptions people have about agile. It is only made worse by the fact that there is very little helpful information on the subject out there.
Agile isn’t limited to developing products. The agile mindset and the ways of working that stem from it can be just as well be used for developing (and managing) services.
How do I know this?
Because I have hands-on experience leading a tagging and analytics team whose only role was to take the tools in Google’s Marketing Platform (think Google Tag Manager, Google Optimize, and Google Analytics) and put them to good use for capturing data about how customers were engaging with the organization’s websites.
That team accepted requests in a service desk, worked on tickets on a Kanban board, and followed standards and operating procedures to configure, deploy, and manage the life of these tools.
It had daily standups, worked on stories on a product backlog, grouped those stories under epics, and continuously improved its ways of working through standardization, templatization, and automation.
Not only were there no software developers on the team, but, in the classic definition of the word, there was no product to manage. Only a portfolio of services to take Google’s marketing tools and set them up in a way that created value for the organization that sponsored the work.
Agile Beyond Product Development
Start somewhere:
You are the owner of something, whether you work with a team or by yourself. Define what that something is, the context that it fits in, and the vision and goals that you have for it.
You’re there when you read through the description and it makes you go, “Yes, that’s it!”
Capture all work in the form of items on a backlog:
Now that you shaped your thing and you set a goal for it, capture all of the work that needs to be done, by you and/or by others, to get to that goal.
Start from a high level, then break it down into “just enough” detail to bring clarity.
Order the work items:
Congrats, you just created a backlog! The next step is to order the work items on that backlog in a way that makes the most sense for your thing and in your situation.
You will have to figure this out on your own, taking the context into account and with feedback from others, keeping in mind that there are no right and wrong answers.
Get down to work:
Start walking the walk, one small step at a time. Complete the backlog items of highest value—however you define value—first, then proceed to the next ones. As change occurs and as you start to see the work from a new, better-informed perspective, adapt your plans.
New work items will come in. Old ones will need to be resurfaced. Units of work you once thought of as critical will become outdated and irrelevant. Stay the course, but respond to the changes in the terrain.
Make small improvements that add up:
Contrary to what most people think, agile isn’t about getting a lot of ambiguous work done in no time. It’s about always being clear about the work that is being done, and about making small improvements to the way that it is shaped and delivered continuously.
Over time, those small improvements compound and lead to marginal gains in effectiveness (doing the “right” thing) and efficiency (doing the thing “right”).
Agile in Services: A Practical Example
Julie and her husband Steve own a small café called Julie’s Sweetery.
Julie, whose grandma taught her how to cook, bakes the cookies and makes the cakes. Steve, who used to be a barista at Starbucks, works the coffee machine.
When a new customer enters the café, Julie or Steve greet them and take their order at the counter, writing it diligently on a yellow sticky note and sticking it in a place where they can both see it.
Tasks that don’t have anything to do with customers but are important to keep the café running nevertheless, such as keeping eggs and whole milk in stock or taking out the trash, are noted on red sticky notes in the same place.
That place, they joke, is their backlog. Even when their café is overcrowded with customers from the nearby business center at lunchtime, their backlog helps them remember who ordered what in what order. As a result, their customers stay happy—and Julie and Steve stay sane.
Julie and Steve have found that when they have more than ten unfulfilled orders at a time, all orders are delayed by at least a few minutes because they have their hands full.
When one of them notices this, they call out “ten” to the other, and both start telling customers that their orders might take a few minutes longer, handing out free French macaroons and thanking them in advance for their patience.
Some customers are in a hurry to make the most of their short lunch break and leave. Others stay, and—instead of fretting about the delay—they smile while biting into one of Julie’s delicious macaroons.
Without knowing it, Julie and Steve have mastered the flow of Kanban and have put in place limits to work-in-progress, which is helping them to identify and mitigate bottlenecks as they occur.
Business has been good, and the two hired help: a barista to handle the coffee machine while Steve ran errands around town and a junior cook to help Julie with baking.
Steve had very explicit instructions for how to make espresso, cappuccino, and mochaccino to the barista. But, instead of expecting her to memorize them all, Steve wrote them down in a softcover Moleskine notebook and placed the notebook right next to the coffee machine.
“I know you’ve been doing this for a while now and I did share all of my techniques with you,” he said to Anne, Julie’s Sweetery’s new barista, “but when in doubt and if I’m not around for you to ask, everything’s in that notebook.”
Julie’s helper, Mia, is a college student who has always enjoyed baking at home. Mia has never worked in a commercial kitchen, and she is not as experienced as Anne, the barista.
Compared to Steve, Julie did something different. She wrote down all her recipes in a cookbook, but all those recipes called for doughs and batters that she mixed and kneaded every morning.
That way, Mia could assemble the most delicious of cakes without doing everything from scratch herself and while she was still learning the ropes. Julie was happy because, after all, she took great pleasure in cooking.
The customers were also happy because the drinks and the desserts were just as delicious, even though Steve and Julie had hired help!
The couple once again acted in an agile way, and they didn’t even know it. When they hired staff, they thought carefully about the workflow and the procedures, standardizing and documenting “just enough” to make their art and craft repeatable for everyone else who worked at their café.
When they opened a second shop uptown, they built on what worked for their original location by encoding their values and principles in trainings, cookbooks, and practices that made day-to-day work at the café smooth for everyone—and a company culture that helped customers feel at home.
What Steve and Julie had started with sticky notes had now evolved into cash registers powered by an easy-to-use Point of Sale (PoS) system that allowed them to benchmark their two shops and proactively work with their staff to resolve problems and implement improvements.
Whether they called it that way or not, the two clearly understood the value of agile:
Start somewhere, stick to what works, and evolve or drop what doesn’t along the way.
Focus on what makes your customers happy and on what keeps your staff happy to come into work, and remember that, as much as we like to think otherwise, it all comes down to people and the quality of the communication between them.
Stay open to being wrong, measure what you can measure, and learn lessons as you uncover what works and what doesn’t, never forgetting that life—and work—are as much about the journey as they are about the destination.
In Conclusion
We often make conclusive statements and use agile slang to hide the fact that we ourselves have trouble understanding the matter, and that’s okay.
But, at the end of the day, let’s not forget that agile is a mindset that gave birth to the Agile Manifesto, which then paved the road for the agile frameworks that we know today.
And a mindset is the simplest, most universally-applicable thinking tool that one could have. Without it, it becomes all too easy to miss the point of the application.
