Here’s a product owner in her perfect setting. She is an integral part of a scrum team. Everyone sits together, has lunch together, jokes around, and hangs out after office hours. This product owner swiftly answers every question that pops up in a sprint, leaving virtually no room for misinterpretation, loose ends, and waste. There she is, on a team that has a well-earned reputation for top speed and quality.
But then, it all changes. There’s a new challenge. The product owner must set up a full-scale digital transformation project with enterprise-grade software that meets rigorously established business goals and supports the core operations of a market-leading multinational company. Her new team? People of five different nationalities, working from different locations.
“Welcome to agile at enterprise scale, dear product owner! Exactly how will you continue performing as before?” they ask.
To get the answer, she casts her mind back to when she was a newly minted member of her first scrum team and she was consulting “Deep Thought.”
“Oh Deep Thought,” the young product owner had asked, “Please tell me the answer! What’s at the core of the main activities of a scrum team?”
After some time, but fortunately less than 7.5 million years, Deep Thought answered,
“I have the answer, but you are not going to like it: the Backlog!” Deep Thought added, “Remember garbage in, garbage out? When it comes to backlog and scrum, this is exactly how it works!”
The Most Popular Guide in All the Galaxy
It was at that moment that our product owner decided to write this guide. Mainly because Big Thought was right: a ramped-up scrum team steadily works on the interactions of backlog writing -> refining -> planning -> developing and testing -> demoing. And, it all restarts for the next iteration.
Which makes everything centered on… you got it, the sprint backlog!
The thing is, you have zero slack to risk being frAgile at enterprise scale. So, to guarantee maximum alignment and the smoothest sprint possible with a multicultural, distributed team, things really need to start off on the right foot. The goal is the best backlog man ever made. (For those who are used to “backlog” being almost a dirty word, yes, there is such a thing as the best backlog man ever made. We refer to it as “epic structure.”)
For enterprise-grade projects like digital transformation, people from the business as well as IT are involved. Starting off on the right foot means first getting a pretty good grip of the big picture of what has to be done and having unconditional buy-in from your key users—the people you write the user stories for. No simple task, of course! But when you have a big picture and buy-in, you will also have fertile ground for seeding the epic structure. User stories will, later on, sprout from this like leaves on the trees.
This guide is your path to success. It’s where you will have all the information about the eight proven steps that can help you hitchhike your way to agility at enterprise scale. Also, it tells you what to do if you come across a Vogon (always remember, Vogon poetry is even worse than a bad epic structure).
CHAPTER 1 - The Rules of the Guide on Project Initiation
This chapter is about project Initiation. The goal of this phase is a sound definition of the project’s epic structure that will lead you to success. And, who knows, maybe, if you do things well, you might be running in the race to defeat the Galaxy President! So, take your time going through initiation and be prepared for a journey full of adventures.
Step 1. Users Come First
We all say it, but only a few do it. The vast majority of apps available in the popular stores collect dust over time, even though no one plans to spend time and money building something that the end users won’t value. The same thing can happen for enterprise apps and systems, and the stakes are just as high. If your app isn’t adopted and used in your organization, you’re staring down the barrel of an intergalactic weapon that could take out your career for good.
Agile was designed to live off high-end user engagement, so you need to get to know some of your users, profile them, and do what Gojko calls “Impact Mapping” before you do anything else. With this, you capture the who, the what, and the why, and then you turn the business goals of your users into high-level user needs for your product.
A good strategy to assure that what you build adds value to your user community is setting up your epic structure based on each identified user need. Then, when in X months time, you come across a user story hanging in an epic, you know exactly what to do. Here’s an example:
Step 2. Be Visual
You’ve spent some time with your key users; together, you have established what is most relevant for each profile. Now, you’re in a room to discuss—possibly unfamiliar—business processes for your enterprise-grade app. So what should you do?
Pick up a pen and paper. Then, select each user need in priority order, and use good old Business Process Modelling and mockups to tackle what they entail and what they could look like in the app.
Any user story later supported by these elements is more likely to meet the end user’s expectations for experience and journey.
At this point, you will have acquired a significant amount of specific business knowledge. Most people in the room have already picked up the pen once or twice to take a crack at it. So, since the engagement level is pretty good, you’re ready to move to the big picture.
Step 3. See the Forest
So, now you’re pumped and can’t wait to get your team at their desks so they can start building your app, right? After all, it’s the logical next step when building a pretty contained and small-ish app.
Hold your troops off! You’ll just be shooting yourself in the foot.
With a complex and large project, you absolutely cannot jump into coding too soon. If you do, you risk, in each iteration, creating software that no one can make any use of. You will also cause a lot of frustration, and you might even kill the agile feedback cycle principle.
So, before you start Sprint #1, you have to envision the road ahead, even if you adjust the course as you go, which is a welcome part of agile and the reason you chose it in the first place.
So this last step of your initiation is for your team to surface from a deep dive, establish a well-thought-out big picture and then decide how to break down the scope so you can incrementally deliver meaningful pieces of working software. In Jeff Patton’s words, this step is called of User Story Mapping.
So, again, you pick each user need and break it down into its high-level process steps. Put the outputs of step 1 and the activity diagrams of step 2 to good use here. Next, sort each high-level process step in chronological order, left to right. Inside each process step list, compose activities—these are your user story candidates—and sort them from top to bottom by value, criticality, and precedence. This is what it would look like in a practical example: your alarm clock just rang, and you have to go on a galactic voyage:
So, let’s say that alarm clock didn’t help you much on this particular morning. Which activities could you absolutely do without? The dotted red line crossing the epic structure in the diagram determines this minimum list of activities per process step—or epic—this is your minimum viable product for that user need.
Pick Up Your Towel and Don’t Panic
Now that you have a guide to help you get to the best epic structure during the Initiation period, remember:
- Agile at enterprise scale involves dispersed multicultural teams and that means more challenges, some of them serious. Throughout a project lifetime, a lot of people will come and go while the product scales in complexity rapidly. Therefore, knowledge retention is a must! Investing in a proper backlog will guarantee you a persistent single source of truth.
- Be sure to put the end users at the front and center of how you approach an enterprise-scale project. After all, enterprise-wide adoption is your biggest concern. You have to keep users actively engaged despite the longer timespan of an enterprise project to maintain a proximity feedback loop.
- Your project backlog (epic structure) is not just a list of user stories. Certainly, they sprout from it, but the backlog has to be well-designed so that you can prioritize user needs, stay value-driven, and maintain the best iterative delivery path.
- Always bring a towel. A towel is about the most massively useful thing a hitchhiker can have.