Inspect, adapt, coffee, repeat.
Click here to read the article in German
Meet John
John is happy. He lives in the suburbs with his wife Hannah and their two kids Emma (4) and Ben (2). Their favorite game is playing “the floor is lava” with their dad.
As a passionate Product Owner, he loves creating value that improves the users’ life and ideally makes the world a better place. Another thing he likes very much is good coffee — pure and black — often many cups a day.
With his 32 years, he has several years of professional experience as a Product Owner for a few consulting companies. Just recently he passed the PSPO II certification test with flying colors. Not only does John know the theory behind Scrum and the Agile mindset, but he can also apply the knowledge on a daily basis. One of his favorite questions is the simple but powerful, Why? to get to the bottom of the real problem. One of his key activities is facilitating collaborative (remote) workshops to explore, develop and maintain a product vision and its intermediate goals (see page 3) to align all stakeholders and developers. New features are a glimpse of a future product state. He sees them as a hypothesis that could add more value. To validate these, it’s necessary to have the users’ interest in mind at all times: What do I need to learn from the user? Which feature variation serves the users’ needs the best? With which data can I validate my assumption?
These are only a few questions John constantly asks himself and others while maintaining the product backlog where all ready-to-implement ideas are stored as a single ordered list. Each item is good enough to be implemented within the next six months as this gives enough focus and perspective for what is coming. After that, plans usually change a lot and it’s more effort to maintain the plan than it provides benefits. All other ideas which aren’t ready yet or where more brainpower is necessary he develops elsewhere. Digital whiteboards, mockups, and a digital notebook are only a few ways for him to capture ideas until the time is right for them to shine.
While waiting for his third cup of coffee one morning his thoughts went back to his first encounter with Scrum.
A rocky start
He remembers how excited he was when participating in his first Scrum class. He learned all the different pieces mentioned in the Scrum Guide and how to apply them. Everything sounded so sophisticated and shiny like it was the holy grail of how to create valuable software. He was thrilled to use all of it.
But then something unexpected happened when he got assigned to his first real-world project as a Product Owner by his company: His client BlueFire Services asked for Product Owner support for their product tracking service TrackMe!Now!. The goal of the service was to track any unit worldwide and show the history of past locations. The service could track everything from a large oversea shipping container to a single pharmaceutical package.
The management team at BlueFire had heard about Agile and Scrum. They knew the buzzwords. ALL of them! But Agile and Scrum were only fancy modern words for the well-known waterfall command and control structures. Daily Scrum meetings were the perfect opportunity to get an up-to-date status report and control the progress.
Sprint Reviews were only for the project lead to shine. Having developers, designers, testers or even users at the Sprint Review was frowned upon. Management believed that these meetings only distract the team from producing more lines of code. John was only invited to the Reviews to give a status report and transcribe the latest demands from the stakeholders.
A rebellious idea
For John, this was a real problem. He wasn’t able to create value but was used as a scribe or proxy by the stakeholders. In one Sprint Planning, the stakeholders demanded to have a blue button and in the next Planning, they required a green one. But for both demands, it was unclear if this was something that would improve the users’ lives.
When he confronted the stakeholders and questioned the value of the features, John got angry and arrogant answers: THEY “know the users best” and they “absolutely need this feature”. Or they “knew exactly what the product needs” because they have been doing this for decades. For John, these answers were not only unsatisfying but also felt very wrong. That was not how he learned the Scrum theory! This kind of product development was not based on the three pillars Transparency, Inspection and Adaptation from the Scrum Guide but the direct opposite. The stakeholders blocked the possibility to improve the product step by step through an iterative approach. This went on Sprint after Sprint while John was thinking about how he could make his stand.
Because the management also prevented direct interaction with the users, he had to come up with something else to validate if a feature was useful or not, to stop implementing unnecessary, unloved, and unused features with zero value for the user. Ideally, this would also save BlueFire time and money.
One day during lunch, Sarah, one of his colleagues from the developers, excitedly showed him a new game on her phone. The goal was to click on things as fast as possible. John didn’t get why the game was so hyped but it gave him an enlightened moment. “What if we don’t need to get in touch with the user to gather data if a feature is useful? What if we can just measure the usage?” The more he thought about the idea the more certain he became that this was the way to go. “Can we measure how often our features are used?” he asked. “Sure. It’s no big effort” Sarah answered. With a grin, she added “Shouldn’t be more than two days of work if you want it all fancy. But it would also be possible to have a prototype with half a day of work.” “Deal!” John laughed.
Since he still wasn’t in the position to prioritize the feature in the Sprint Planning, he needed a sponsor for his idea to convince the other stakeholders. So he created a User Story describing how the product would benefit from measuring the usage of features. With this data, it would be possible to identify missing functionality. Removing barely used features would also reduce the cost of maintenance and potential bug fixes.
To identify which of the stakeholder might have the highest interest in the feature proposal he mapped all known stakeholders. As the highest promoters, John identifies Larry, head of marketing, Mark, head of support, and Lynn, head of product management.
A setback
The next day he approached Larry with a well-formulated feature request. Unfortunately, Larry didn’t see the benefit in measuring the usage of the features. He explained to John, that customers always want all of the features. “When was the last time our customers were asked?” John wanted to know. “Around three years ago, when we added the functionality to export a list of missing products in TrackMe!Now!”, Larry answered proudly. After seeing John’s reaction he added “And there is no need to get on their nerves!” The argument that the proposed feature would give deep insights about which features could be promoted bolder wasn’t convincing either. John felt that it made no sense to try to persuade him.
Approaching Mark next with his idea led to the same rejecting answer. From his harsh response, John even got the feeling that Mark was afraid that his proposal could cause layoffs in his support department.
A bold move
Subdued and a little shocked he went to his favorite bar that night to spend some time with his best friend Jack. Late in the evening, John complained about his setback at work. Jack listened to it for 20 minutes before he said “That bad, huh? But I think I know what the problem is. Did you tell them about the WHY?!” John looked at him blankly. “What WHY?”
Jack laughed and continued. “Look, all you talked to them about, was WHAT you want to do and HOW. But you totally forgot the most important part: The WHY! Don’t you know the Golden Circle? I saw Simon Sineks awesome Ted Talk a few weeks ago. John, WHY is it vital for you to implement that new feature? Never mind, I’ll send you the link tomorrow so you can figure it out.”
The next morning John received Jack’s email with the link and dove deep into the search for his WHY. Soon it was clear: He needed the usage index feature to make evidence-based and data-driven decisions for maximizing the value for the user. With this newfound insight, he wanted to approach Lynn, the head of product management.
John decided that Tuesday morning would be the perfect time to talk to her. Looking at her Outlook calendar he found a single free 30-minute slot at 10 AM. Excited he opened the invitation window and entered all the necessary details. He ensured that the invitation title was meaningful “BIG opportunity to improve subscription renewal rate” and the details contained a brief description of what he wanted to talk about. Also, he set the meeting length to 25 minutes so she would have enough time to get to her next meeting. After checking all the invitation details John took a deep breath and hit Send. Hearing the sound of the outgoing mail, he felt anticipation.
A first victory
When he opened his laptop the next morning he saw a reply from Lynn confirming the appointment. Surprised he noticed that she even added a short note: “Hi John, really looking forward to our meeting and excited to hear about your idea. See you next week.”
On Tuesday morning John felt the adrenalin rushing in. While preparing the meeting room he went through his storyline several times. Lynn arrived at 9:58 AM and after a quick hello and small talk, John started to give her a brief overview of their meeting.
Then he explained that currently, he has no transparency about how users use their services and therefore it’s unclear if a feature brings value or just increases the maintenance costs.
He showed Lynn a first graph where the maintenance costs significantly increased over the last twelve months. A second graph revealed the decreasing number of users who renewed their subscriptions in the past year. Next, he pointed out that the number of features in the online service grew continuously.
He used the next minutes to link conspicuous drops in renewals to major product updates by their competitors. Then he pulled out a comparison between TrackMe!Now! and the competing products. It clearly showed that their competitors limited the available features and even removed some which were promoted as the main benefits of TrackMe!Now!. Based on the presented data John concluded that they really needed insights into the usage of the product to stay a relevant choice and be able to grow the customer base again. “And as I’m currently not empowered to talk with users, the only option for me to get back on the right track is to measure how the user behaves, starting with creating the proposed usage index.” he finished his pitch.
Lynn took some minutes to review the slides again before complimenting John for his good work. “These correlations are new to me since I always got green status reports. Can you send me the slides? I need to talk to the stakeholders and higher management. I assume I can convince the higher ranks to approve your initiative.” With a glance at her watch, she bid farewell and promised to give John feedback about the next steps soon. When she left the room he felt victorious.
Two weeks later he got a call from Lynn, telling him that his initiative was good to go ahead and was supported by the CTO. “Your correlations raised higher management attention and now they want to see results from me. Let’s meet for lunch to discuss further steps so we can prioritize this in the next Sprint Planning. And I want you to keep me posted. Let’s make it a success for both our sakes.” With that, she hung up. John felt excited to tackle his idea but also worried as the stakes became higher. He was finally on track to creating real value for the users of TrackMe!Now!.
He smelled fresh coffee… and woke from his daydream.
A ray of sunshine
While walking back to his desk with his coffee cup, he thought about his learnings. He grinned while remembering how naive he was to think that companies would play by the Scrum rules just because they renamed all of their processes. Since he wasn’t able to enforce the rules or lead his team to implement the framework processes at the time, he had to think outside the box to at least generate value for the users. He was thankful for his perseverance and willingness to inspect and adapt himself.
Looking out the window he saw rays of light bursting through the clouds. What a fitting image for his agile journey: Exploring more and more methods, always on the lookout for possibilities to create value and make products shine. He smiled.
