Building Skyscrapers and Shattering Dreams in Product Development | Guest post by Rainer Tikk

Rainer Tikk writes this guest blog post about what Product Development looks like from the perspective of a leader of a software organization in a mid-size bank. He’s the Head of Software Development at LHV, an Estonian bank betting on IT as a competitive advantage.

To a non-IT person, developing an IT solution might often seem like a mystical activity that boys with ponytails (and some girls) do in a dark basement somewhere. Moreover, software development, in general, is an expensive activity altogether and often takes more time than it really should. And even if there is money available to pay for the software development, more often than not, it’s almost impossible to find a developer to build the stuff you need.

There is a significant shortage of qualified IT talent (at least in Estonia, where I live and work), which in a way explains why Estonian companies invest way too little into automation and the usage of modern technologies which would make their processes more efficient. However, this would be a whole other article.

Now, back to software development. We’ve come a long way from boys with pony-tails in dark basements and tech companies have more than successfully shaken off this image. The offices of tech companies are fancier than ever and there’s plenty of diversity which has made the “average stereotypical developer” almost extinct.

But the lack of time and money to develop the software solutions we need, however, remains. How expensive is expensive, is up to you to decide, but I will try to explain a little about what usually goes on in the dreaded “dark basement”.

To do this, I’ll use the construction of a house as a metaphoric example, an analogy to make my arguments clear. To simplify, let’s assume that software or product development is like construction work – somebody orders the construction of a house, somebody will build it, then other people will start using it and so on. I talk about product development specifically, because that’s what matters most in my domain.

As we are building a home for our residents, we need to make it into something they actually need and want – not just a roof over some walls. Software development (walls and roof) is just one part of developing products.

TIP: As a Product Owner you should always focus on the big picture. Product development is not a delivery problem (getting something done fast), it’s a discovery problem (discovering and doing the right things).

Where do time and money go?

Time in product development is divided between three different types of work: building a new house (new functionality/product), upgrading an existing one (making things better), and, at the end of the day, everything needs maintenance and repair (software upgrades, refactoring, redesign, etc.). In addition to all that, we provide support to the owners of the house (Product Owner/business) as well as the residents (software/product users) who also have occasional questions and issues.

Broadly speaking, one-third of all time spent is used to build new houses, one third is usually reserved for upgrading existing ones and the last third is spent on general maintenance and other organizational issues.

Why does construction always seem to take so long?

Let’s extend the metaphor a bit more and assume that the building of new houses is planned at the beginning of the year. That first one-third of the time spent on building new houses is not that long if you look at the big picture. But expectations are high, lots of new houses are expected to be finished within that time frame. Usually, that timeframe tends to be unrealistic. For large buildings, there are several intricate nuances, all of which influence the completion of one thing or another. On top of that, the planning process usually starts with merely naming and trying to articulate what needs to be achieved, it’s either: “a house”, a “larger house”, or “some kind of a house”.

The beginning is often vague, to say the least. The process will then become more specific as plans will be further articulated, refined, and many plans changed as they progress. Therefore, what is planned at the beginning of the year will not usually materialize as expected by the end of the year. But that’s fine, that’s why plans are reviewed on an ongoing basis and changed as needed.

TIP: As a business stakeholder or Product Owner you should embrace the fact that plans will change and you should be prepared to deal with it (and even benefit from it!). You need to have that flexibility in your team/processes to manage change smoothly. Note that I’m not saying that planning is not necessary, it is indeed necessary. But plans itself are eventually kind of worthless. So you should always focus on creating value instead of meeting the established deadline, budget and scope.

When it comes to building that “some kind of a house”, the fact is that detailed construction projects or plans, that state exactly what and how is needed to be done, are missing. This is where creativity and uncertainty begin (and usually never end). The prospective homeowner may not even know what kind of house they want exactly, but they’re sure they want a house.

They might say they want it made out of bricks and painted red and have a certain number of floors, but that’s about it. And that’s where it gets complicated. It gets even messier when in reality you end up having to build a 25-story skyscraper instead of the 5-story house that was originally planned. For whoever is doing the construction, it’s essential to know, what the prospective resident looks for in their new home. But they can’t usually say that for certain until they have moved in. That’s also OK because construction work is gradual – one floor is built first, and then the other floors are added and interior design works started.

The lack of detailed projects leads to a situation where it is not known how long it will take to build a “red house made of bricks”. If this house is built and the next “red and brick house” is wanted, it will not help either, because you will usually never build an exact replica of the previous house and we all know how much time and money can be spent on interior design (and other “small things” that end up taking the bulk of the time). This is OK, because the context and environment are changing rapidly, as are desires and needs and hence, it is wise to be as flexible as possible. It is important to get the result you need, not to build a random house in the middle of nowhere. This adaptability and openness to changes is what we now call agility.

Two things to always keep in mind in a Product Development environment

In product development practice, there are a few things to keep in mind.

First, don’t ask the customer what they want, instead ask, what the problem is they want solved. This will help you focus on the actual problem instead of the dream. There will always be big dreams and demands for development. And these dreams and demands will always be greater than the supply of talent and time to meet them. Meaning, you never get to the point where you have enough people and resources to fulfill all those needs. Thus, you should focus on finding the next most important thing to do (from the value perspective).

Secondly, what a Product Owner can do to help find “the right things”, is to slice the work into meaningful pieces, as small as possible. This will help you and everyone involved in the project achieve that flexibility to respond quickly to change of plans and also get faster feedback. When you get this in place you will eventually build a better product.

Being an owner means having to take responsibility

Problems also arise when the owner can’t decide which house they want most or which one they want next and the construction team has to build two (or more) houses at once. Then it takes an awful lot of time to move between sites, and of course, the completion date of both houses will consequently be delayed. Also, if we are already building one house and it turns out that a smaller shed needs to be completed in the meantime, it will take additional time to move all the equipment between building sites. And when the team gets back to the first project, they’ve already forgotten where or what they used to be working on exactly.

If, for some reason, there is a definite deadline for building a “blue and brick” house and it is known that all the remaining time will be spent on it, but the owner still insists building “red and wooden” in the meantime, it will be, for some reason, incomprehensible to the owner that if “red and wooden” will be built, then “blue and brick” can not be completed in time.

One of the biggest wastes in software development is parallel work. In other words, there is this pervasive illusion that if we are doing multiple projects at the same time, we get to squeeze more out of the team. This is not the case. Parallel work is often the bi-product of the Product Owner being unable to decide which project is the next most important to be done and thus they start multiple projects in parallel (because everything needs to be finished yesterday). The more stuff you have on that table, the more time it will take to complete it, and as a result, the completion time will grow exponentially.

As a product owner you should be aware of the consequences and avoid that trap at all costs.  

Of course, several additional things affect the completion of a building – how much the owner is present and involved and how well they express their wishes, and how often the wishes change. Sometimes the team members get sick and sometimes some even leave to go work for another construction company. Then you need to find a new person and you need to do it fast. It is complicated because there is a lot of work to be done and a random builder off the street often just doesn’t cut it.

The Upgrade and Maintenance Projects

Another third of the time spent goes to upgrading existing houses. This is an essentially unpredictable activity and the needs to be tackled can come from anywhere – the owner wants to change something in their house or there is a policy change that says we need to replace all windows. In essence, this is a job that falls on you when you own a house, with little chance of you deciding what or when to do. But that’s OK because a good owner knows where their priorities lie. Right?

The last third of the time is spent on maintenance and repairs. If icicles hang from the edge of the roof in the winter, they must be removed. Regular cleaning is also generally required, otherwise, no one wants to live in that house. Sometimes you have to fix the foundation or even replace parts of it. Or take, for example, security. For critically important houses, the fact is that security systems should be renewed often. These systems need to be constantly upgraded, or else someone can break in and steal the residents’ property. That could have tremendous consequences. But that’s OK because a good owner knows that everything has to be in order and will invest in that work. Right?

Don’t underestimate the cost of having a software system.

Software systems need constant maintenance as a building and a car does. If you don’t invest in maintenance and upgrades, you’ll end up building technical debt which may eventually make the house unusable. If you keep ignoring technical debt, it will just grow.

Technical debt won’t disappear as I’ve seen too many times business owners dream of. Eventually, you end up in a situation where you need to do something (business-wise) but you can’t do it before you have removed the technical debt which literally blocks you from doing the thing you need to.

Simple questions don’t always have simple answers

Despite everything mentioned above, there are notable differences between product development and house building. For example, in product development, there are no detailed projects, but rather sketches and details are decided on a rolling basis. These things are so for a reason. It is not easy to see the progress of completion with your own eyes as there are no “rising walls”, and when it is finally “done”, 2/3 of the time will be continuously spent on upgrades and maintenance. Building a product is a complex process – it’s creative and unpredictable. If buildings were built as products, most of them would not be standing.

There is certainly more flexibility in product development, but it will also result in more opportunities to build things you don’t need or want to use. That’s why soft factors are important in achieving good results – from collaboration, communication and team physical presence to collective intelligence and ways of thinking. Also, following a textbook does not usually lead to a good result – what works for one does not work for another. It is important to learn, test and find techniques that work in your context, with your people and your products.

So how much does a “red house made of bricks” cost, you ask? It depends. But when can you consider the construction project finished? Honestly, when nobody uses it anymore.

About Rainer Tikk

Rainer is the Head of Software development at LHV, a mid-size bank based in Tallinn, Estonia. He has 15+ years of experience in the areas of software development management, product development, team leadership, and software engineering.

Over that time he has collected deep knowledge in strategic management, organizational design, agile methodologies, full SDLC and in different FinTech and banking domains (payments, cards, core banking etc).

Rainer believes in value-driven product development, building good software (high-quality, secure, sustainable), continuous improvement, automation and autonomy for the teams that develop the software.

He’s interested in growing teams and organizations, developing strategy, agile product development.

In his free time, Rainer travels, hits the road with his motorcycle, likes to breathe fresh air on a golf course, hits the slopes with his trusty snowboard, and searches for treasures underwater, but most importantly, his biggest project is raising his 2 children.

You can link with Rainer Tikk on LinkedIn.

BONUS: Does Agile play well in Leadership teams in organizations? – Diana Larsen and Jutta Eckstein

Diana and I were kicking around a few topics for this episode, and we ended up selecting “Agile and Leadership, friends or foes?” The idea is to talk about how Agile and Leadership play together (or not)

In this episode, we talk with Diana Larsen and Jutta Eckstein about what problems Leaders try to fix with Agile, what challenges they have when they try to adopt Agile, and we will do this with the focus on the Scrum Master role, and what they can do by working with the leaders of the organizations they work within.

Let’s start by defining some of the major challenges we see happening out there.

The 3 biggest challenges on how Agile plays (or not) with Leadership

Some of the challenges we mention in this episode are not new. You are probably familiar with many of them. We talk about how Agile requires us to think about leadership as a distributed responsibility that team members need to take on, which is itself a major challenge for Scrum Masters as they help their teams understand what that means in practice. 

We also discuss how important it is to understand that leadership is not simply a “role”, but also something we need to earn, including Scrum Masters.

Finally, we talk about the important role that leaders play for the teams they work with. Specifically in setting the direction that helps the teams adopt quicker processes like Hypothesis-Driven-Development, for example.

How Scrum Masters can cope with these challenges

We then discuss how Scrum Masters can understand, and learn to cope with these challenges. Not surprisingly, Agile Retrospectives come up as a critical tool for Scrum Masters to use when working with teams and their leaders. 

Regarding collaboration with leaders, we discuss how Scrum Masters can help teams focus on the right goals, which need to be defined in cooperation with leaders in the organization.

But there’s a second tool we discuss that complements perfectly the work we do with the retrospectives and helps the teams and leaders understand where they can contribute the most: visualization as a way to establish a shared context.

Do Scrum Masters really need to protect the team from their leaders? 

Stop me if you have heard this one before. Way back when I was taught that Scrum Masters need to protect the team from interference. Although it made sense to me at the time, with the passing of time, and after collecting more than a decade of experience, I have come to value a different approach. 

In this segment, we talk about the need (or not) to protect the team from Leadership interference. 

The goal, of course, is to generate a real collaboration between the team and the leaders in the organization.

The key resources on leadership and Scrum by Diana Larsen, Jutta Eckstein and Vasco Duarte

Given that leadership, and the collaboration between teams and leaders is a critical topic for Scrum Masters, we discuss some of the resources (books, podcasts, articles) we’ve found useful and informative on how to tackle that collaboration. 

Here are the resources we mention: 

 

How about you? What have been your major challenges when working with leaders in your organization? Leave a comment below and share the tools/books/podcasts you’ve found useful. 

About Diana Larsen and Jutta Eckstein

Diana Larsen co-founded and collaborates in leadership of Agile Fluency™ Project. Diana co-authored the books Agile Retrospectives: Making Good Teams Great; Liftoff: Start and Sustain Successful Agile Teams; Five Rules for Accelerated Learning; and the seminal “Agile Fluency Model: A Brief Guide to Success with Agile” article.

You can link with Diana Larsen on LinkedIn and connect with Diana Larsen on Twitter

 

Jutta Eckstein works as an independent coach & consultant. 

As a developer, she started with XP in 97/98, started scaling agile in 2001 (and published about that in 2004), and am now Jutta focuses on company-wide agility.

You can link with Jutta Eckstein on LinkedIn and connect with Jutta Eckstein on Twitter

You can learn more at Jutta Eckstein’s website, and check out Jutta’s books on Amazon and LeanPub.

Jutta’s Agile Bossanova book is available here.

How metrics, used right, can drive learning in your organization: Measure to learn – The Bungsu metrics code

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.

There’s a lot more to talk about metrics, and how simple practices can transform your organization. The book shares a lot about that, of course, but here’s a podcast episode where I talk with Vasco about the same practices.

Do you need the one metric that matters to engage your team? This booklet is for you!

In the Bungsu’s Pirate Code for Visualization downloadable booklet I will go into details on how we made this “one metric that matters” engaging, kept it relevant and ultimately saved the hospital by keeping our focus there – using what we referred to as the Bungsu Pirate Code. Click here to download your guide to using the “one metric that matters” in your own team.

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!

About Marcus Hammarberg

Marcus is the author of Salvation: The Bungsu Story (available on Amazon), an inspiring and actionable story about how simple tools can help transform the productivity and impact of an organization. The real-life stories in The Bungsu can help you transform the productivity of your team. Marcus is also an renowned author and consultant in the Kanban community, he authored the book Kanban in Action with Joakim Sundén.
You can link with Marcus Hammarberg on LinkedIn, and connect with Marcus Hammarberg on twitter.

The value that Agile coaching and Scrum Masters bring to your organization – Q&A with Jeff Campbell

Jeff is the author of Actionable Agile tools (available on Amazon, and direct from the author at bit.ly/aatbook). He joins us on this series of Q&A shows to answer questions you’ve submitted. You can submit your questions via our survey (short, about 2 min to fill-in) or by tweeting us @scrumpodcast with #agilejeff.

In this episode, we talk about the importance of technical excellence and how to help teams adopt that mindset.

How to explain the need for Agile coaching and Scrum Masters

Continue reading The value that Agile coaching and Scrum Masters bring to your organization – Q&A with Jeff Campbell

How focusing on a single metric improved team performance – Guest post by Marcus Hammarberg

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 third 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?

How focusing on a single metric improved team performance

Now that we had a metric that mattered to everyone and this truly was the “talk of the hospital”, we experienced a wave of change.

Not surprisingly the first groups to engage was the people in charge of bringing more people to the hospital; the marketing team.

It turned out that making the “number of patients served”-metric visible throughout the hospital, was what was needed to get them activated. But when we did, the lid of their passion and creativity jar was blown off! We started to see real ownership in their behavior. As if The Bungsu was their very own hospital.

Before I knew it, I found myself in a workshop where the two ladies of the marketing department blurted out 25 ideas on how to get more patients. And 3 or 4 of them were really low hanging fruit that we could do the very next day. For example:

  • Go to the nearby clinics and advertise our availability for surgery and treatments that the clinics could not handle
  • Offer free transport from the big hospitals to our hospital for treatments that the big hospitals had a waiting list for
  • Suggest that our freelancing doctors would do all their surgery in our hospital

These were very simple changes that had been dragging on in decision-making boards. Now the decisions were quick to make – because the need and impact were clear to see.

Just a few days after we started to track “number of patients served per day” these actions brought the metric up to a whopping 133 patients served per day! Twice the normal number of patients and a level that has not been seen in a long time.

This taught me, in a very impactful way, how a single metric can transform the performance of a team. In this case, the marketing team.

Do you need the one metric that matters to engage your team? This booklet is for you!

In the Bungsu’s Pirate Code for Visualization downloadable booklet I will go into details on how we made this “one metric that matters” engaging, kept it relevant and ultimately saved the hospital by keeping our focus there – using what we referred to as the Bungsu Pirate Code. Click here to download your guide to using the “one metric that matters” in your own team.

This is a very actionable tool that you can you use today in your organisation 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!

About Marcus Hammarberg

Marcus is the author of Salvation: The Bungsu Story (available on Amazon), an inspiring and actionable story about how simple tools can help transform the productivity and impact of an organization. The real-life stories in The Bungsu can help you transform the productivity of your team. Marcus is also an renowned author and consultant in the Kanban community, he authored the book Kanban in Action with Joakim Sundén.
You can link with Marcus Hammarberg on LinkedIn, and connect with Marcus Hammarberg on twitter.

How to help Self-organization get started in the team – Q&A with Jeff Campbell

Jeff is the author of Actionable Agile tools (available on Amazon, and direct from the author at bit.ly/aatbook). He joins us on this series of Q&A shows to answer questions you’ve submitted. You can submit your questions via our survey (short, about 2 min to fill-in) or by tweeting us @scrumpodcast with #agilejeff.

In this episode, we talk about getting management to understand and learn how to support and promote self-organization by the team.

Helping teams and managers adopt self-organization as a way to improve the team’s impact

Continue reading How to help Self-organization get started in the team – Q&A with Jeff Campbell

How to help Self-organization get started in the team – Q&A with Jeff Campbell

Jeff is the author of Actionable Agile tools (available on Amazon, and direct from the author at bit.ly/aatbook). He joins us on this series of Q&A shows to answer questions you’ve submitted. You can submit your questions via our survey (short, about 2 min to fill-in) or by tweeting us @scrumpodcast with #agilejeff.

In this episode, we talk about getting management to be involved and buy-in to the agile transformation.

Helping teams and managers adopt self-organization as a way to improve the team’s impact

Continue reading How to help Self-organization get started in the team – Q&A with Jeff Campbell

How a single metric can help the team members engage and become a real team – Guest post by Marcus Hammarberg

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 second post on a series by Marcus Hammarberg about how metrics can help engage, motivate and ultimately push a team towards success!

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?

Click to learn more about how you can help your PO

Keeping engagement when the bad news hit – Becoming a team!

Continue reading How a single metric can help the team members engage and become a real team – Guest post by Marcus Hammarberg

Breaking the skill silos: how to help teams become cross-functional – Q&A with Jeff Campbell

Jeff is the author of Actionable Agile tools (available on Amazon, and direct from the author at bit.ly/aatbook). He joins us on this series of Q&A shows to answer questions you’ve submitted. You can submit your questions via our survey (short, about 2 min to fill-in) or by tweeting us @scrumpodcast with #agilejeff.

In this episode, we talk about getting management to be involved and buy-in to the agile transformation.

How to help teams share knowledge and become cross-functional teams

Continue reading Breaking the skill silos: how to help teams become cross-functional – Q&A with Jeff Campbell

How the right metric, communicated the right way can engage your team. By Marcus Hammarberg

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)

When we first started to work with the Bungsu hospital they were in a devasting situation. Their finances were at an all-time low after years of decline in patient visits. Their operational permit had not been renewed and they were operating on probation, the staff was disengaged and blasé … oh, and one more thing: the roof of the entire second floor had collapsed.

Still, to my great surprise, not many people were upset, engaged or even cared about the survival of the hospital.

Fast forward 1,5 years and you would see a hospital that was making money every day, had not only an operational permit but also got awards for their services, happy and engaged staff … oh yes, and they had a newly renovated roof.

We didn’t hire or fire a single person during this time – and all the work to save The Bungsu was done by the people in the hospital, I merely acted as a guide for new ways of working.

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?

We soon realized that the scary state of the hospital’s finances was not only our number one priority but it was also too vague for the staff when expressed in numbers. Billions of rupiah in deficit didn’t mean a thing for the staff.

First of all, those numbers were unrelatable for the average employee, even if we broke it down per day. Saying “we need 18.000.000 rupias per day” to someone that earns 1.000.000 per month doesn’t spark engagement.

We need 18.000.000 rupias per day!

Secondly, and perhaps most important, the staff in the hospital was not interested in budgets, forecasts or financial plans. They worked with patients! We needed something more concrete and closer to their day-to-day reality.

Armed with those two realizations we started to track “the number of patients we served per day”. We hoped this concrete metric would engage the staff. The numbers of presented were truly awful; our financial target was 134 services sold per day and we were averaging on 60-70. Half of what we needed to be able to improve the financial situation!

our financial target was 134 services sold per day and we were averaging on 60-70. Half of what we needed to survive!

I was shocked but the reaction in the room was something very different. Indifferent, unfocused or the occasional shrug. Almost angry, I got up and added a new line, for the number of patients required to break-even; 120. In my upset mood I blurted out:

Below this line we lose money by having the hospital open and we may need to close it!

That got their attention. The jaws of the 70 people in the room dropped to the floor at once. We now had our one metric that matters and most importantly: everyone understood it.

In the next blog post, you will see how this metric, visualized and understandable not only helped us focus on what is important but also made us into a team.

Do you need the one metric that matters to engage your team? This booklet is for you!

In the Bungsu’s Pirate Code for Visualization downloadable booklet I will go into details on how we made this “one metric that matters” engaging, kept it relevant and ultimately saved the hospital by keeping our focus there – using what we referred to as the Bungsu Pirate Code. Click here to download your guide to using the “one metric that matters” in your own team.

This is a very actionable tool that you can you use today in your organisation 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!

About Marcus Hammarberg

Marcus is the author of Salvation: The Bungsu Story (available on Amazon), an inspiring and actionable story about how simple tools can help transform the productivity and impact of an organization. The real-life stories in The Bungsu can help you transform the productivity of your team. Marcus is also an renowned author and consultant in the Kanban community, he authored the book Kanban in Action with Joakim Sundén.
You can link with Marcus Hammarberg on LinkedIn, and connect with Marcus Hammarberg on twitter.