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?

Keeping engagment 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

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.

Slicing work for Value, the lost art of #Agile that can transform your team’s productivity and predictability.

Agile is about adapting to change. Change is a reality, we can’t avoid it. How we react to change is what will make or break our product development efforts.

For us to be Agile and adaptable, however, we must be able to change direction quickly. Adjust the deliverables after we collect market/customer feedback. Many teams I’ve worked with were doing exactly the opposite!

Teams often get stuck in the “this story can’t be broken down any further” anti-pattern. They push themselves to deliver enormous User Stories, and therefore end up having to do a lot of upfront planning and estimation (both are needed when the work items are very large).

If teams were able to slice work down to very small increments – say, one day or less – then they would not need to spend so much time planning and estimating. They might even be able to adapt during a Sprint, instead of waiting for the end of the Sprint.

Continue reading Slicing work for Value, the lost art of #Agile that can transform your team’s productivity and predictability.

Making Agile Retrospectives Impactful – A Visualization Tool by Jeff Campbell

This is a guest post by Jeff Campbell, author of Actionable Agile tools (available on Amazon, and direct from the author at bit.ly/aatbook)

Visualizing Continuous Improvement

I am a big believer in continuous improvement, weather that be in the form of Retrospectives, a Kaizen approach, or something else that helps the team reflect regularly. But for the earlier years of my career as a Scrum Master I found myself frustrated by a lack of improvement despite all this reflection (retrospectives that have no impact…).

Often,what I was seeing was that we talked about the problems the team was facing, and then didn’t follow-through with the actions we agreed to take.

When we tried to change our behavior. We might have succeeded for a day or two and then would forget about it. This isn’t continuous improvement this is just continuous discussion!

We need a good way to make sure we are actually making the change we set out to make!

Continue reading Making Agile Retrospectives Impactful – A Visualization Tool by Jeff Campbell

Why Agile frameworks fail and what to do about it: #ToolsOverFrameworks, the context-aware solution

4 minutes read

I have worked at many organizations that were trying to adopt Agile using a framework as the starting point. SAFe, LeSS, or even Scrum were the frameworks of choice.
Scrum, for example, is a very simple framework. It stands to reason that it would be easy to adopt and therefore benefit from the value that Agile brings. Or is it?
If we look deeper, Scrum is a collection of patterns or thinking tools. The daily meeting pattern, the time box pattern, the single owner of the requirements pattern, etc. There are many patterns that were considered when creating Scrum, and together they form what we know as the Scrum framework.
As the Agile community, the problem we face is that Scrum (and other frameworks) did not make Agile adoption easy. The Scrum Theatre many teams play attests to that fact. Using a framework is a problematic approach for Agile adoption because it assumes a prescriptive solution would help us tackle agile adoption. However, Agile adoption is a problem that requires constant evolution and changes.
As the Agile community, the problem we face is that Scrum (and other frameworks) did not make Agile adoption easy.
We need a different approach. One that builds on what we’ve learned from others (books, podcasts, conferences), but also that adapts to our context and the specific reality we live in.

The patterns we’ve seen working before, fail later on

When we work with different teams, we start to get a “feel” for what works, and what doesn’t. We try to apply the same ideas to another team, and then start to understand what consultants mean when they say “it depends…”

When we work with different teams, we start to get a “feel” for what works, and what doesn’t.

For example, the star-fish retrospective may work great for one team, but it just bombs when we use it with another team. That’s ok. Nothing works all of the time. The good thing though, is that there’s always something that works, we just need to know what it is.

The solution is not a process or a framework, it’s a toolbox!

Having worked with many teams, I’ve come to value a few tools that I try to use often. Some retrospective formats are one example of that. But not every retrospective format will work, so I’ve collected over time a large set of “thinking tools” or retrospective formats that I use depending on the context.
As a Product Owner, I’ve successfully used Backlogs. But in some teams Backlogs get abused and create the “slave to the backlog” anti-pattern. With those teams, I’ve been using Impact Mapping and Story Mapping instead. Different situations require different tools. The challenge is collecting a good and large enough toolbox, and the stories to go with it.
Stories, when attached to a tool, help us define where the tool will work, and when it might not. Stories are our “labels” for tools.

Collect tools, not frameworks

No doubt you will be part of teams using different frameworks: Kanban, Scrum, Extreme Programming or Scaled Agile (SAFe), Large Scale Scrum (LeSS), etc.
Don’t fight the framework! Instead, use concrete tools that help you progress and achieve your goals.
As Agile Coaches, Scrum Masters, Product Owners and Team Members, we should be collecting tools, not frameworks. Our goal is to deliver something valuable to our customers/users, not be good at SAFe, Scrum or some other framework.

How we collect tools

We collect tools and stories by sharing our experiences, and listening to those that have solved the problems we are facing now.
For a while I’ve been collecting challenges and tools that product developers use to solve their most important challenges. I’ve collected those in the form of workshops that tackle specific types of problems.
In the #NoEstimates workshops, I share tools and techniques that have helped me and many others deliver on time. Sometimes you can’t fight the deadline. If the product must be out for Christmas, you just deliver. Period. How? That’s what we tackle in the NoEstimates workshop: tools, techniques and thinking models that help deliver on time. These tools are context specific, they come with stories and we practice those in the workshop. Click here to find out more and join the next #NoEstimates workshop.
In the Product Owner Success Toolbox workshop, we review, and practice tools that have helped teams deliver products and services that have a market impact. Impact for the users, customers and also the companies we work with. The biggest waste is that of human potential, with these tools we build our Product Ownership toolbox, and tackle the biggest challenges people have faced when trying to define and deliver products with market impact. Click here to find out more and join the next Product Owner Success Toolbox workshop.
In the Agile Strategy workshop (still in alpha, contact me to know more), we tackle the biggest challenges that companies have faced aligning the teams, and focusing larger number of teams on concrete value for the customers and the organisation. The Agile Strategy workshop collects tools related to funding of work, strategy definition, product strategy, strategy deployment, and progress follow-up at the organizational level. Email me to know more about the Agile Strategy Workshop.

Join the conversation

Have an opinion on the use of Tools vs. Frameworks? Join the conversation on Twitter/LinkedIn with the hashtag #ToolsOverFrameworks

Top 3 challenges we face as product developers – #PDevTOOLBOX

After running a survey of product developers, I collected the following 3 top challenges that product developers face in their work.
  1. Unclear specifications with missing information like acceptance criteria, and that require large amounts of rework after we start developing a particular functionality
  2. Finding out critical use cases too late (via bugs, real-user feedback, etc), which leads to long delays in the project.
  3. We don’t have a clear and measurable definition of value, therefore it is always a fight of opinions where the HIPPO (highest paid person’s opinion) prevails most of the times – even when it goes against survey results.

A toolbox to solve these problems

Given these 3 main findings, it is easy to understand why delivering on time is hard for many teams. No matter how much goes into planning and estimating, when the agreement on value is missing, and the specifications of what to do are too fuzzy, we will inevitably find big gaps that lead to massive scope creep and delays.
But it does not need to be like these. There are simple tools I collected in my product developer’s toolbox (#PDevTOOLBOX) that can help alleviate or remove these problems. Based on your input through the #PDevTOOLBOX survey, I’ve created a booklet (15 min read) you can download and read while on the run in your mobile phone or tablet.



2 major challenges I faced as a product developer

When I started developing software as a team member, and later as a project manager, I started to face some of the challenges that you are probably familiar with.

With the little experience I had, these challenges proved to be difficult to solve. During part of my journey, they even felt impossible to solve. I know better now…

The first and most important challenge for me was the need to meet a strict deadline.

We ended up calling it the Christmas problem.
Continue reading 2 major challenges I faced as a product developer

Agile Practices Retrospective – How to help teams get unstuck!

This is a guest post by Jeff Campbell, author of Actionable Agile tools (available on Amazon, and direct from the author at bit.ly/aatbook)

Keeping retrospectives impactful and fresh

We like to keep our retrospectives fresh. We find it helps to reveal things we might not otherwise have found if we alter the format frequently. With this goal in mind, we follow a simple system:

Once a month we use our ”normal” retro format. Everyone in the team is familiar with this, and we can perform them quite quickly, with minimal prep work and explanation required. Basically, effective with very little admin.

Once a month we have our ”experimental” retrospective. A little more set-up time required, but a good opportunity for experimentation and explorations.

This is the story of one such retrospective.

Agile Practices

Obviously, you can perform many Agile practices, but not be Agile. However, there are a lot of practices out there and sometimes teams can become focused solely on those that they are currently using, rather than looking at other tools they might bring to bear. This is where the Agile Practices Retrospective comes in.

Prep Work

In preparation for the retrospective, we created cards with various Agile practices as headlines, and a brief explanation of each listed on it. I also color coded them under various categories so they could be more easily identified from afar. Then we simply taped all these cards to a wall in their respective categories. There were about 50 cards in all.

Special thanks to Jurgen Appelo for providing the initial list I worked from:
http://www.noop.nl/2009/04/the-big-list-of-agile-practices.html

Here is a link to a google doc with the prep work I have done, to save you some time:
https://tinyurl.com/l8loec6

Reducing the complexity

With over 50 cards, there was a lot of information. We split into groups and started categorizing the cards under a new set of headings, it was made clear to all that they were not expected to read all the cards.

Headings:

  • Doing (Working Well): Things we are currently doing, and quite happy with the way they currently work.
  • Doing (Could be better): Things we are currently practicing but could use improvement.
  • Not doing (By choice): Things we are not currently practicing, but have made a choice not to use in our context.
  • Not doing (Not tried): Things we are not doing, and have never really tried.
  • WTF!?!: We have no idea what this is, or what it means.

Deciding what to focus on

We obviously cannot talk about all these things. So, we used dot voting to decide what topics to focus on. Each team member was given 3 ”dots” for each of these types of vote:

  • We should start and or alter this practice in some way. (Indicated by a dot)
  • We would like to learn more about this practice. (Indicated by a +)

I also printed out simple list versions of the same information, as I knew it would be hard for everyone to gather around the board when deciding how to use their votes. Despite this, this was still not as successful as we would have hoped. Part of this is because we are actually two teams and our 3 customer representatives, so the whiteboard was too crowded. I feel this would go better with a single team.

Discussions and action points

We had open discussions and tried to create action points/experiments around the topics we had discussed. I will just give a very brief of what we arrived at:

Root Cause Analysis/ 5 Why’s

Discussion:
We even arrived at the fact that without formal tools, we are still quite good at root cause analysis. But perhaps a formal tool might reveal something we would have otherwise been unaware of.

Experiments:
1)Focus on using our discussion time during retrospectives (Generate Insight) to use more formal tools like 5 why’s.
2) When events are added to our timeline at daily stand-ups, then we should also consider doing a more in-depth analysis of those items.

Product Vision

Discussion:
We felt that we very likely do have a product vision, and even a fair amount of impact mapping done for that, but this is not communicated to the entire team at a frequent enough rate. Also, we need to get better at following up these things.

Experiments:
1)Make the product vision more concrete and communicate it at a regular interval.
2)Follow the vision and impact map up at a regular interval.

Behaviour Driven Development (BDD):

Discussion:
This is a discussion point we wanted to learn more about. So, the discussion was brief. We basically arrived at the fact that it was intriguing and we want to know more.

Experiments:
1)The two team members who know something on the subject will provide some links and a quick intro for everyone else.
2) Some of the team will experiment with these concepts in our ”Brain Day” next week.

Conclusions:

The Good:

This retrospective was reviewed well by the team, everyone generally liked it.

It was a fairly active retrospective, because of all the moving things around and working in teams, so the energy level remained high throughout.

Probably the best aspect of this retrospective was the addition of fresh concepts into the team, the idea to focus on things we wanted to learn more about was a good one. In the future, we would probably recommend only focusing on these things.

The Bad:

There was a fair amount of prep work involved in this one, although I consider it worth the investment, it wasn’t free. Hopefully, a bit cheaper for you, as we have provided the work we have done. Once again: https://tinyurl.com/l8loec6

It was too hard to get an overview with so many items, this may have been due to team size, and might have been possible to mitigate by having the team read the list beforehand.

Despite there being so many items, the list was not even close to exhaustive, and it was hard to leave off some practices that really should have been included.



About Jeff Campbell

Jeff Campbell is the author of Actionable Agile Tools, a book with practical tools and practices to help you amplify your impact as a coach and Scrum Master

Jeff is an Agile Coach who considers the discovery of Agile and Lean to be one of the most defining moments of his life and considers helping others to improve their working life not to simply be a job, but a social responsibility. As an Agile Coach, he has worked with driving Agile transformations in organizations both small and large.

Jeff is also involved in the Agile community and is one of the founding members of Gothenburg Sweden’s largest agile community at 1500+ members , and he also organizes the yearly conference www.brewingagile.org.

You can link with Jeff Campbell on LinkedIn and connect with Jeff Campbell on Twitter.

How to amplify Agile Enterprise collaboration: The Internal Unconference how-to guide

  • Are you having trouble getting inter-team cooperation going?
  • Is it difficult to attack issues that require people from all over the organisation?
  • Do you find decision making to be difficult and slow?
  • Do you find it hard to just knuckle down and get things done?
  • Do you want to remind people in your organisation how many brilliant people they work with?

In that case, you might consider running an “Internal Unconference”.

Internal Unconference is an exclusive blog post by Jeff Campbell, author of Actionable Agile Tools, a book that includes 19 practical tools with step-by-step guides for Scrum Masters. Actionable Agile Tools is now available on Amazon.

Continue reading How to amplify Agile Enterprise collaboration: The Internal Unconference how-to guide

How to build trust with clients and stakeholders while getting what you deserve for your work: a story about trust

This is a guest blog post by Jacopo Romei. Author of Extreme Contracts, a book about how to build trust, and deliver value without traditional contracts.

How to build trust with clients and stakeholders while getting what you deserve for your work: a story about trust

Over the last ten years, I’ve experienced the direct impact of lack of trust in vendor-buyer and even colleague-colleague relationships. I’ve come to find that it is the main reason why collaborations in knowledge work fail.

I’ve tried to fix that in my own work as an independent consultant and when working with other colleagues. That’s why I ended up experimenting with a new type of agreements which are optimized for trust building. This experimentation resulted in a set of principles that I call Extreme Contracts. Now, all my customers and I use this approach to shape our collaboration and they have started using Extreme Contracts also with their customers.

Continue reading How to build trust with clients and stakeholders while getting what you deserve for your work: a story about trust