All of us working with Agile and Scrum are used to the (sometimes) large transformations that these approaches can have at work. But it is not everyday we see the impact, the amazing impact, it can have on other types of work. How about this: Marcus Hammarberg, walks into a hospital and the hospital is about the crumble. Literally! The roof has collapsed, there’s dripping water and buckets everywhere and the second floor is overrun with debris. But that is not where the problems end…
A few months later, and using Kanban, Agile and Lean ideas the hospital is saved. But how did that happen?
Marcus explains his story, and the amazing transformation in his latest book: The Bungsu (now available for pre-order at Amazon), and we have a short video to explain the main points of the story right here.
Click on to see the video, and sign-up to get the first chapter of the book.
This is a question that every Scrum team should know the answer to. Not knowing the answer means more meetings, more disagreements, more conflicts, and ultimately the wrong work gets done first. But this does not happen because anyone is doing something wrong! It happens because there’s no common, agreed and clear way to decide what is the most important work. How to solve this problem?
Work life is a serious thing. We spend (at least) one-third of our time awake at work, and in some cases much more time than what we spend with our families most days of the year.
Now imagine what would happen if your work would be falling apart. You have too much work, and are being constanly interrupted. Your authority and ability to contribute is undermined. And on top of it your place of work is literally crumbling: the roof collapsed and what is left is being innudated by dirty water that runs off from the roof’s debri.
Meet Ibu Elsye! Ibu Elsye is the lady dressed in black in the picture or “Mrs.” Elsye if you don’t speak Indonesian ;).
She’s General Manager of a hospital, Rumah Sakit Bungsu (aka The Bungsu), that Marcus Hammarberg helped, in Indonesia. General Manager; what is that, in a hospital? I’m happy you asked: basically she’s in charge of everything that is not health care. Food, laundry, maintenance, security staff, drivers … you name it.
In The Bungsu, if you need something fixed – go to Ibu Elsye.
But Ibu Elsye’s work life was not going very well…
When Marcus Hammaberg first started to work with the Bungsu hospital they were in a devastating situation. Their finances were on a bottom low after years of decline of patients visiting, their operational permit had not been renewed and they were operating on a probation, the staff was disengaged and blasé … oh, that’s right – the roof of the entire second floor had collapsed.
When a product grows and becomes a success, so will the demands on the Product Owner.
There will be more stakeholders interested in the product, which leads to more meetings. The number of teams developing the product will grow, which will increase the number of meetings and daily questions to the Product Owner.
The more successful the product becomes, the harder it is to manage that product with one single Product Owner.
It is no surprise that most successful products seem to be constantly affected by the lack of time on the part of the PO. However, that’s not the only cause for a PO to be pressed for time. In smaller companies that are adding products to their offering, we often need to start working on a new service or product before a new PO can be hired. On top of that, the knowledge that is already in the PO’s head will be hard to transfer to a new PO, so hiring more Product Owners may even be the wrong thing to do.
Read on for more details and the full article download.
Why do we have daily meetings? Why do I need to be involved with the team every day? Why can’t I just give you the requirements document and concentrate on other tasks?
This blog is part of Module 2 of the Coach your Product Onwer v2.0 video course.
The Anti-Patterns When A Product Owner Is New To The Team, The Product And To Scrum
These are just some of the questions that Product Owners that are new to Scrum will ask. But sometimes we need to onboard Product Owners that are new to Scrum, new to the Product and new to the team. That’s not an easy task.
The Product Owner may not have any technical knowledge of the product or the understanding of the business the product supports. When a Product Owner is new to the team, and the collaboration habits have not yet developed. For example, he may be tempted to just go away and write all the User Stories in isolation or with a Business Analyst, and never involve the team. Which later leads to the “tell the team what to do, and disappear” anti-pattern. Continue reading Product Goal-Setting: How Scrum Masters can onboard a new or beginner Product Owner
The overly busy or absent Product Owner is a common anti-pattern in agile organizations.
This can have serious consequences for the teams we work with as Scrum Masters.
Additionally, Product Owners that are spread too thin may not even have time to be in the Scrum meetings because they serve many teams or handle several products, or because they have so many other meetings with C-level, or other stakeholders. Missing critical Scrum meetings (e.g. Sprint Review, Sprint Planning, Grooming) will quickly lead to a de-motivated team, as well as lack of trust and potential conflict between the team and the Product Owner. In my own experience, when the Product Owner starts missing critical Scrum meetings, the team will quickly start asking: “why do we even do these meetings”, which quickly leads to the meetings being dropped.
How do we help our Product Owners overcome these challenges? Read on…
The Product Owner (PO) is a tough role to fill. Product Owners are torn between users, senior management, team and other stakeholders that they need to attend to.
While the team is working on completing the backlog items, the PO is probably meeting with the Director of Product to agree on a roadmap; with the CEO to hear about the latest ideas he got from visiting a client; trying to meet with the user research group to understand better the customer; reporting status to the head of Project Management; and still needs to visit the Sprint Planning, Backlog Grooming, Demo and the occasional daily meeting to answer questions from the team. And let’s not forget the email backlog! With all of these tasks one has to ask: do we believe a single person can do this all alone? What I describe here is not even rare! We seem to collectively think that the Product Owner is a super-hero!
Given all of these tasks, it is little wonder that the PO’s end up struggling to even manage the JIRA tickets the teams ask them to review, give feedback on, and prioritize.
“My Scrum is failing!” is a commonly heard comment. “Agile isn’t working for us” or the common “we do Scrum, but … [add your favourite anti-pattern]” are just symptoms that the teams are struggling with Agile adoption.
In the other end of the spectrum, we have teams that are highly effective. They deliver valuable functionality to the market every sprint, and sometimes even several times per sprint. These teams seem to have found a “groove” where collaboration is natural, they are motivated, and the results speak for themselves. We call these high-performing teams. Teams that spend more time delivering value than “struggling” with their agile adoption.
Where is your team in this continuum? And it is a continuum. There are many shades of grey on this scale from “my scrum is failing” to “we lover our job, and our customers love us”.
How do we bridge that gap? How do we help people go from scrum-but to “yeah! we did it!? Read on for more…