Imagine a company that spends a year building an iPad app—and on launch day the product owner says: “Now it’ll be interesting to see if anyone uses it.” In this episode, Marcus Hammarberg and Tore Fjaertoft share why organizations keep installing frameworks like software, why it still doesn’t work, and what they’ve learned from places like Spotify about treating your way of working as a product in itself.
When Copying Without Adopting Becomes the Norm
“It becomes more about following whatever this framework tells you to do, rather than to understand what the problem you’re trying to solve is all about.”
Marcus and Tore met at a consultancy in Malmö and within 15 minutes realized they shared the same frustrations—despite coming from opposite directions. Marcus comes from the ground up as a software developer and coach, while Tore works top-down with leadership teams on product organization design. Both had worked at Spotify and both had seen organizations copy famous frameworks and models without adopting the underlying mindset. The telltale sign, as Tore describes it, is when people focus on compliance rather than being pragmatic—following the manual without questioning whether the way they’re working is actually serving the organization. As Marcus frames it through Cynefin, product development lives in a domain where best practices don’t even exist—only emergent practices that you discover by trying things out.
We explore a real-life project that Marcus was part of, and how the #NoEstimates methods he used helped him make predictions, even if did not estimate the work to be done.
This conversation started from an article that Marcus had posted earlier on social media. In that article Marcus explained how he had used data, as opposed to estimates to make a prediction of when the project would be finished. This approach still creates a lot of controversy on twitter, even if it has been (at the time of recording) 10+ years since the original discussion around estimates started by Woody Zuill and Vasco Duarte on twitter under the tags of #NoEstimates and #Estwaste respectively.
As Marcus quickly found out in this project, the rate of progress could not have been predicted easily at the start (if at all). When he first started the project, the progress was swift, but at one point he faced a problem he could not solve for several days. This phenomenon is not new for any programmers in the audience, and is quite common. Also, one of the reasons why using methods like #NoEstimates (as explained in the #NoEstimates book, and in Marcus’ blog post), can help uncover information that estimation would not.
Dealing with surprises: the information you need to share with stakeholders
We explore a real-life project that Marcus was part of, and how the #NoEstimates methods he used helped him make predictions, even if did not estimate the work to be done.
This conversation started from an article that Marcus had posted earlier on social media. In that article Marcus explained how he had used data, as opposed to estimates to make a prediction of when the project would be finished. This approach still creates a lot of controversy on twitter, even if it has been (at the time of recording) 10+ years since the original discussion around estimates started by Woody Zuill and Vasco Duarte on twitter under the tags of #NoEstimates and #Estwaste respectively.
As Marcus quickly found out in this project, the rate of progress could not have been predicted easily at the start (if at all). When he first started the project, the progress was swift, but at one point he faced a problem he could not solve for several days. This phenomenon is not new for any programmers in the audience, and is quite common. Also, one of the reasons why using methods like #NoEstimates (as explained in the #NoEstimates book, and in Marcus’ blog post), can help uncover information that estimation would not.
Dealing with surprises: the information you need to share with stakeholders
Marcus wrote a blog post about predicting progress in ‘well-defined’ projects. He used a simple example where uncertainty was very limited. You can read the details in the blog post. However, even when uncertainty about the work was low, the predictions he was able to do (and he collects quite a few metrics in that story), was limited.
In this episode, we explore the limits to prediction, and how that affects how we should look at prediction in our own software projects.
Embracing uncertainty and what that means in practice for software projects
This is a guest post by Marcus Hammarberg, author of Salvation: The Bungsu Story, How Lean and Kanban saved a small hospital in Indonesia. Twice. And can help you reshape work in your company. (available on Amazon)
This is the fourth and last post on a series by Marcus Hammarberg about how metrics can help engage, motivate and ultimately push a team towards success! (See other blog posts in this series here)
When we first started to work with the Bungsu hospital they were in a devasting situation.
Fast forward 1,5 years and you would see a hospital that was making money every day.
In the end, we turned the hospital from a situation where only the director and her closest staff cared, to a situation where 100 people in the hospital were actively engaged in everyday improvements.
How is this possible? What kind of magic was applied?
Visualizing the right metric
Each morning we showed the result and it was good we had loud cheering among the staff. But for bad days it was mostly silence, head hung low.
I also noticed that the lady that was in charge of gathering the numbers, Ibu Elly (Mrs Elly) the directory secretary, behaved a bit different for days with bad numbers. She was almost reluctant to present them and quickly went over the whole thing.
We had talked about what we wanted to learn about the numbers and I had written “KENAPA” (WHY) beneath the graph. Because I wanted us to learn from the metric we were collecting and visualizing every day.
For example on this graph – can you see something that stands out?
See those regular dips? If you asked “KENAPA” and counted the dates, you could probably figure out that those dips are Sundays… People don’t go to a hospital, as much, on Sundays.
“KENAPA” – what can we learn? Well, we could (and did) try to be more open on Sundays, but pretty soon realized that it would be very costly to keep more staff around and that it was a cultural thing keeping people back.
Until that point, most of the management team understood the KENAPA-question, but it made Ibu Elly feel ashamed for bad days. That troubled me, until one day when she was bustling with joy. We had made an excellent result yesterday: 138 patients served in one day. The first time, above our goal of 134 patients.
As she entered the numbers and headed back to her seat I asked… “Kenapa, Ibu?”
She stopped in her step and turned around with a puzzled look. “No, you don’t understand. It was a good result, sir.”
I did understand that it was a good result but I pressed on. “I know, but why was it good”.
Poor Ibu Elly looked around for support and then back to me with an even more puzzled look. “Well… in the polyclinic, we had 32 patients, and then for the ER we had 12 patients and …” I interrupted her gently.
“I understand all of that. You are showing me the math. But why was it good yesterday?”. At this point, she gave up and just said “I don’t understand” and took her seat.
I felt bad for her but we had an important learning point here, so I pressed the others. “Anyone else knows why it was good yesterday? Kenapa?”.
After a few moments of hesitation, someone offered “Well, yesterday we had three doctors in the polyclinic, rather than our usual two. Dr Paula did an extra day for us.”
“AHA!” I exclaimed, a bit too loud if I’m honest… “So what can we learn?”
We eventually concluded that more doctors probably means more patients. At least that was a hypothesis we could use to run an experiment.
More importantly, with the visualized data and by continuously focusing on learning we found that knowledge nugget. We now had understood the value of asking “WHY” the data behaves as it behaves. And from this point on we viewed the graph differently – it was now a source of learning, regardless of the result.
This is a very actionable tool that you can you use today in your organization to make your visualizations matter to everyone all the time.
The Bungsu Story is a fascinating account of a real-life crisis, and how Agile, Lean and Kanban saved the Hospital from bankruptcy! Twice! Get ready for the journey, it’s going to be a bumpy ride!
Enter e-mail to download a clickable PO Cheat Sheet
This handy Coach Your PO cheat-sheet includes questions to help you define the problem, and links to handy, easy techniques to help you coach your Product Owner
Enter e-mail to download a clickable PO Cheat Sheet
This handy Coach Your PO cheat-sheet includes questions to help you define the problem, and links to handy, easy techniques to help you coach your Product Owner
Enter e-mail to download a checklist to help your PO manage their time
This simple checklist and calendar handout, with a coaching article will help you define the minimum enagement your PO must have with the team
Enter e-mail to download a checklist to help your PO manage their time
This simple checklist and calendar handout, with a coaching article will help you define the minimum enagement your PO must have with the team
Internal Conference
Checklist
Internal Conference
Checklist
Download a detailed How-To to help measure success for your team
Motivate your team with the right metrics, and the right way to visualize and track them. Marcus presents a detailed How-To document based on his experience at The Bungsu Hospital
Download a detailed How-To to help measure success for your team
Read about Visualization and
TRANSFORM
The way your team works
A moving story of how work at the Bungsu Hospital was transformed by a simple tool that you can use to help your team.
Read about Visualization and
TRANSFORM
The way your team works
Overcome Team Resistance and Gain Leadership Buy-In
Discover practical, real-world solutions from leading Agile practitioners. Download three free chapters from 'Tips from the Trenches Scrum Master Edition' and start transforming your Agile practices today!
Overcome Team Resistance and Gain Leadership Buy-In
Discover practical, real-world solutions from leading Agile practitioners. Access three free chapters from 'Tips from the Trenches Scrum Master Edition' and start transforming your Agile practices today!
Overcome Team Resistance and Gain Leadership Buy-In
Discover practical, real-world solutions from leading Agile practitioners.
Download three free chapters from 'Tips from the Trenches Scrum Master Edition' and start transforming your Agile practices today!
FREE! Audiobook Chapters: Overcome Team Resistance and Gain Leadership Buy-In
Download three free chapters from 'Tips from the Trenches Scrum Master Edition' and start transforming your Agile practices today!
Your FREE ticket is on the way!
Check your inbox for details.
Email us at
ProductOwnerSummit.org if you have questions
Check Your Inbox For Details
Email us if you have questions:
ProductOwnerSummit@oikosofy.com