Salvation: The Bungsu Story

A few months ago I had the great pleasure to meet Marcus Hammarberg in person, when he came to my company’s office for a talk called ”The Bungsu Story”. This is an inspirational presentation how agile and lean principles saved a hospital in Indonesia. The speech was based on his experiences that are also covered in the book, that I’m now about to review: Salvation: The Bungsu Story

Salvation: The Bungsu Story - Cover

The book has six parts, 21 chapters and 326 pages. The subtitle is: ”How Lean and Kanban saved a small hospital in Indonesia. Twice. And can help you reshape work in your company.”


”This book is not based on a true story – it is a true story.”

We enter the story right after a major disaster happens to the hospital. During the rain period the partly renovated roof has fallen in. By all means everything is at risk from this moment on. Marcus and his small team from the Salvation Army steps up to the challenge to help the management team of the hospital. But first he digs in, literally, cleaning up after the disaster with the roof. Theory of Constraints is used to improve the process, when the buckets are given up for rice bags (to get rid of the debris).

Part II is called ”The rebuild”. Now the work starts to save the hospital using agile and lean. Example of things that are introduced:

  • The Not List (to keep focus during discussion)
  • Limit WIP (minimize the number of concurrent work in the process to enable flow)
  • Three stages of coaching.
  • Definition of Done -> Gives common understanding.

Things start to move in the right direction, but not as swift as anticipated, but a motivation speech (fully covered in chapter 5) takes care of that!

”Measure to learn – not punish!”

In part III, named ”The backsliding”  the momentum from the start ends up in the inevitable plateau or decline. The war cry from mob programming: ”Turn up the good”  is one of the tools used to push forward. At one point Marcus jokingly says: ”If only there was another emergency for us to handle. That would be great for morale!” You should be careful with what you wish…

Circumstances running a hospital in Indonesia forces the management team to lower the income at the same time as increasing the cost, it is time to get down to business again for Marcus and his team.

”What is the smallest step you can take to see if you’re moving in the right direction?”

Visualizations are used throughout the whole story in Bungsu. Marcus advice is not to overdo the board, keep it simple to let the visualization evolve over time! Chapter 18 is called ”Trust, Transparency, Accountability”. Here the lovely story of Ibu Elsye is told (she is the General Manager of the hospital, taking care of everything else but health care and finance at the hospital). She is totally stressed out over her situation, but with some encouragement and guidance she makes wonders…


I can totally recommend this book! Here are my main reasons why:

  • This book is authentic (see the first quote above), it shows that lean and agile principles works even in a hospital (a context outside of IT)!
  • This book is the perfect sequel to ”Kanban in Action” (which Marcus co-wrote together with Joakim Sundén), which is more theoretical.
  • The chapter with the story of Ibu Elsye (that alone is worth the money buying this book)!

I had the huge honor to help Marcus out as a beta reader for this book, and it was really rewarding to revisit the text when 100% completed!

All the best,
 Tomas from TheAgileist

Philosophy – One Step Ahead

If you are one step ahead of things, life is so much easier. Its like in chess, where you have the next move already sorted out. If a problem occur, you already have a solution, or at least a strategy on how to solve it. One step ahead means that you are in the driver seat of the car, and not pinned down in the back.

One step ahead

”One step ahead” – Slightly better prepared or more successful than someone else (taken from TheFreeDictionary)

Being alert and looking forward is also more fun than looking backward. Therefore one step ahead is the philosophy that I vouch for! It’s also very easy to remember and visualise in your head, three simple words:

  • One
  • Step
  • Ahead

Ok, maybe this is enough of ”selling my theory”, let’s get a little more concrete.

You can visualise my philosophy like traveling along a road. Your road can be straight or with a lot of curves. But on that road there will be a number of obstacles, impediments that needs to be dealt with. If your sight is narrow (close to blindfolded), you will bump into EVERY obstacle and need to deal with them reactively. But if you are one step ahead of everything, your sight is longer (aiming for the horizon) and you can see the obstacles ahead, and can be able to turn for them (i.e., do something actively about them). It is always easier to deal with problems you can see coming (when they are ”small” and further away), than when they have happened (and have become ”large”).


Figure 1 – One step ahead philosophy. The project is like a truck with cargo (tasks) traveling along a road with obstacles.

The truck in previous picture symbolises your project or other larger work at hand. The truck is loaded with a lot of stuff, that is your tasks or work items.

To be one step ahead you need to keep your eyes open (talk to your project team members, find out what they are worried about), and to have your view on the horizon (with that I mean a time perspective of weeks or months ahead, rather than days or hours).

If you sense a problem or challenge (picking it up when you discussed the project with Ed, the lead programmer, in front of the coffee machine in the morning) you should not give up before you can sort the it into one of the following categories:

  • Immediate action needed – You need to understand the problem in detail (in so much detail that you understand it, and can make a decision about it). If you don’t understand the problem, you simply need to keep digging until you do (book meetings with key persons, read the specification once more, etc.). When you understand and can see the impact, you need to take the proper actions to solve the problem.
  • Needs to be dealt with later – You have done your homework and understand the problem and its impact, but it doesn’t need your immediate action. You still need to ”own” the problem and follow-up on it, i.e., by adding it to the AP-list and the time plan (if it is affected), more about that later.
  • Harmless / no action required  – Your investigation shows that the problem is harmless to you (i.e., it will not affect your project or task at hand, you can pass it on in the organisation) or ”it will solve itself” (i.e., the problem can be fixed without your involvement, or even simpler, there was no problem).

Next section will tell you a little more about how to face problems or challenges.

Reactive management

In reactive management (a.k.a. ”fire fighting”) you act on things that HAS happened. Your data storage has run out of free space, your largest customer has found a fatal bug in your software that is already in production, or your best programmer has left you for your competitor. That’s why it is also called ”fire fighting”, your are dealing with the symptoms, and can do nothing about the cause of the problem (at this point of time).


Figure 2 – Reactive management. You are running behind the truck to pick up the stuff that has fallen out, i.e., fixing problems that have already happened.

You as a leader are running after the truck to pick up the stuff that has fallen off because hitting the bumps in the road. Most of the things that falls out is possible to fix (like adding more disk to the data storage), but it slows you down. Some things are broke and lost forever (like the lost of your best programmer). The truck must stop while you fix things, i.e., your project moves slower or is even stopped from time to time. This will lead to delays, that in turn makes frustration among all the projects’ stakeholders.

In reactive management you are one step behind, lying in the backseat of the car. Interested to hear how you can grab the steering wheel?

Active management

In active management you have a preparation for things that can happen.


Figure 3 – Active management. You are running in front of the truck to remove impediments as they come along.

Visualise this by you running ahead of the truck to push the stone away or to fill the hole in the road, or to tell the driver to steer away from the hurdle. The more problems or challenges you can fix, the faster you truck (project) can move. In theory you can clear the road all the way to the finish line (the project goal), but in practice its about ”clearing” a reasonable distance in front of the truck (after all, it can be very hard to look into the future). It’s all about removing of impediments before the truck (project) hits them.

You must also have an awareness of the problems you can’t see, they might be too far away for the moment or they are hidden. Like when it’s around Zero degrees Celsius and a spot of ice appear in a steep curve (that can make your truck run off the road). To have that humble insight that it can be even more problems is a good start.

”Why do you need to spend time on problems thats has not happened?”, someone might ask. Because you then have a chance to call for meetings, find the proper solution or minimise the impact. You don’t want to end up under time pressure, because that will force you into bad decisions. With bad decisions you will end up in reactive management and you are stuck in a catch-22 (i.e., going round in circles).


  • Management is like traveling along a road with a number of obstacles.
  • Active management – You try to do something about your problems before they occur, or if not possible to solve, to minimise the impact.
  • Reactive management – You bump into problems and act on them after they have happened.
  • Active management is to prefer over reactive, to be ”one step ahead”.
  • Go from reactive to active management A.S.A.P!

Top Ten List – Books

Today I visited Stockholm Lean Coffee. It was my first visit in a long time, and the discussions were very giving as usual! The question that I brought to the table was the one of tips of (new) Agile books to read. I got a few suggestions that I can come back to later, when I’ve read them. For now, I will share with you my top ten list of the most inspiring Agile/Lean/Management-books that I have read. Here it goes, in reversed order for most excitement, of course! 🙂


Top Ten List – Books

10. #Workout (Managing for Happiness)

I start off with the one and only book that yours truly have contributed to. 🙂 It’s the “#Workout”- book that Jurgen Appelo self-published. See my short review here. It has now been withdrawn from the market, and replaced by “Managing for Happiness: Games, Tools, and Practices to Motivate Any Team”. Most of the chapters from the first book was transfered over to the new one that is available for purchase.

9. Scrum and XP from the trenches, 2nd edition

My Agile journey really kicked-off by reading this book back in 2008 (it was then the 1st edition, released 2007). It gave me the understanding that it was possible to build software without using the waterfall model! The 2nd edition is annotated by Henrik Kniberg, sharing eight more years of his experience. Here is my review of the 2nd edition.

8. Creativity, Inc.

Ed Catmull is an astonishing leader! This book is his biography, but also tells you the story on how to build an innovative and creative company, like Pixar (nowadays a subsidiary of The Walt Disney Company). In his career he made art and technology come together. Here is my review of the book.

7. Soft Skills

Before I started this blog I had a strong desire of writing a book myself. But I had no idea on how to do it. Via Manning I got involved in a MEAP (Manning Early Access Program) providing feedback to this book “Soft Skills”, to get me “into the world of book writing”. It turned out that John Sonmez are a quite nice fellow! 🙂 “Soft Skills” clarifies personal kaizen.

6. This is Lean

This is my Lean-bible! It taught me the “secret sauce” of flow efficiency (work moves fast through the process) over resource efficiency (people to be busy at all times). I read this book long before I started blogging, therefore I don’t have any formal review, instead you can read this blog post that sums up my thoughts regarding this.

5. Moments of Truth

This book I first read in Swedish (then it is called “Riv pyramiderna!”). The author Jan Carlzon states that a leader of a company can’t be an isolated and autocratic decision maker. Instead, he or she must be a visionary, a strategist, an informer, a teacher, and an inspirer.The values presented in this book are well inline with the agile thinking, talking about empowered teams that are cross-functional and customer focused. Here is the review.

4. Agile Project Management with Kanban

I immediately bought this book after I heard about it, since I’m both into project management and Kanban! And yes, the book fit me like a glove! It’s a true gem, a perfect Agile book in 160 pages. Read more about it here.

Ok, we are approaching top three now…

3. The Innovators

”The Innovators” is Walter Isaacson’s followup book to the ”Steve Jobs”-biography that I think many of you have read. The book holds 500 pages plus, that covers the whole history of the digital revolution from the 19th century to present time. The main takeaway from this book is that creativity is a collaborative process. That innovations comes from smart people working together as a team, rather than from a lone genius. Here is my review.

2. Kanban in Action

This is my personal favourite amongst the books about Kanban! I’ve read it several times. It sort of changed how I see things, and even how people anticipate me, as you can read in the review that I end with: ”I can truly recommend ’Kanban in Action’ to anyone that wants to know just the slightest bit about managing knowledge work. From the first moment I started reading it, this has been my holy bible of Kanban!”.

And the winner is…

1. The Nature of Software Development

This book is written by Ron Jeffries, one of the original Agile Manifesto signatories. It was published 2015 and is a truly agile book with 150 pages full of wisdom! And questions. That can raise wisdom. If you ask me, I think this book is fantastic! Since the chapters are so short and to the point, it’s almost like reading poetry. Agile poetry. This is the ”true north” or ”guiding star” in Agile we all should aim for! Read my full review here.


I hope you liked this top ten list of books! If you did and tell me, I can make more of this type of lists in the future. It was quite fun compiling it. 🙂 Until next time!

All the best,
 Tomas from TheAgileist

Doing It

I first learned about Ralph van Roosmalen and his work when I participated in a video chat about ”Exploration Days”, hosted by Jurgen Appelo. Ralph is passionate about Management 3.0, and now he has written a book about his learnings called ”Doing It – Management 3.0 Experiences”. The book has 157 pages, with foreword by Jurgen Appelo, and was released in 2017.



The book consists of 13 chapters, and I thought that I should give you a short description to each and one of them.

1. Management 3.0? Huh, what?

Ralph starts out with setting the arena and tells what Management 3.0 is. In short: ”Management 3.0 is about engaging people, improving everything, and delighting the customers.” This short and to the point introduction also have references for more information.

2. What is the role of a Manager?

Management 3.0 highlights six areas for you as a manager to focus on:

  1. Energizing people
  2. Empowering teams
  3. Aligning constraints
  4. Developing competence
  5. Growing structure
  6. Improving everything

3. Move your Motivators

This chapter introduces The Moving Motivators game. This is connected to the first management area: energizing people. It has ten motivators (the CHAMPFROGS model):

  1. Curiosity
  2. Honor
  3. Acceptance
  4. Mastery
  5. Power
  6. Freedom
  7. Relatedness
  8. Order
  9. Goal
  10. Status

4. Surprise your team during their next review?

When it’s time for the review meeting, the first question you ask your team member is, “How are you doing?” They respond, “Er … good…” Then you say, “Okay, why good?” “Just good, you know … good.” Does this sound familiar?

Do you recognise yourself in the quote above? Then this chapter can help you make the review meeting fun again.

5. Traditional HR combined with Management 3.0

Here you will learn more about Delegation Boards. ”In short, just think of them as a spreadsheet that vertically lists the decision areas that you want to delegate to others, while the horizontal axis sets the amount of independence a team lead has.”

6. Implementing Cudo Cards

Next up is an introduction to Cudo Cards, a peer-to-peer rewarding system.

7. Visualise values and name your team

To get a team together you need to find the team values and then visualise them. Here you find concrete tips on how to do that.

8. Team 1 and Team 2, boring

Let the team themselves decide on their team name. Even better let them find a symbol that they can associate with the team! For example Yoda from Star Wars to symbolise mastery.

9. Getting your guilds going

Don’t feel guilty if you haven’t tried it out yet, but guilds are the thing! 🙂 Guilds to nurse craftsmanship is a common practice within Agile.

10. Things I learned about Exploration Days

You want learning and innovation to take place within your company, right? In this chapter the concept of Exploration Days are described.

11. Giving feedback without fear

Are you upset with a colleague? Don’t give them a slap, instead prepare for them a delicate feedback wrap! 🙂

12. I don’t want to implement the Spotify model!

Don’t imitate, innovate! This chapter tells you not to just copy a successful model without tailoring it to your context and unique needs.

13. To finish up

Time to wrap up! 🙂 Some last words from Ralph on where to go next.


If you are new to Management 3.0, ”Doing It” is the perfect starting point! Read the well-written introduction texts, and then use the references to go further. Do you want to try Management 3.0 out? Perfect, use this book to guide you. I can truly recommend ”Doing It – Management 3.0 Experiences”! Best of all? You can download the book right here. Happy reading, and see you next time!

All the best,
 Tomas from TheAgileist

The Power of Project Leadership

According to the list of blog posts in my WP-Admin this is my 25th book review! I guess you know by now that I like to read books. Hopefully you like my reviews and find them useful. This time I’ve read a book that is called ”The Power of Project Leadership” by Susanne Madsen. It was published in 2015, and the subtitle is ”7 keys to help you transform from project manager to project leader”.


”In other words, managers are concerned with doing things right, leaders with doing the right things.” – Susanne Madsen


The book has four chapters and they are:

  1. The world is changing and so must you
  2. Your hidden drivers
  3. The 7 keys to project leadership
  4. Making the transition happen

Throughout the book many questions are raised for the reader to think of and reflect upon. Are there more questions than answers? It’s a fine balance, and it is up to the reader to put effort in to get the most out of this book (by doing the exercises for example).

In the first chapter Susanne introduces the three common mistakes that project managers make:

  • Mistake #1: Managing tasks and events at the expense of leading people
  • Mistake #2: Being reactive and focusing on the urgent rather than the important
  • Mistake #3: Believing that we have to know all the answers

These three reflects very well with my own experiences. So how to avoid these mistakes? The key to good project leadership is to be proactive and to keep a good balance between task focus and people focus. As a help to this, the 7 keys to project leadership are introduced:

  1. Be authentic
  2. Lead with vision
  3. Improve and innovate
  4. Empower the team
  5. Get close to stakeholders
  6. Establish a solid foundation
  7. Work with intent

As you see, this resonates with the agile values. To be able to lead people you need to know what motivates them. Personal development experts lists six human needs: Certainty, Variety, Significance, Connection, Growth and Contribution.

People comes together in teams to perform the work. Energy, engagement and explorations are keys for team communication.

”Organizations are no longer built on force but on trust. The existence of trust between people does not necessarily mean that they like each other. It means they understand one another. Taking responsibility for relationships is therefore an absolute necessity. It is a duty.” – Peter Drucker


Basically the book is about the transition from a project manager to a project leader, and the 7 keys that helps you to get there.  The book is solid with nice layout, good structure, informative stories, many exercises and pictures and a pleasant length (250 pages). If you are into agile and are working with projects, you should check this book out!

All the best,
 Tomas from TheAgileist

To team, or not to team – That is the question

Teams are the holy fundament that agile resides on. Teams should be autonomous and cross functional. Teams should be kept together over longer periods of time to become good at what they are doing, to be high performing. This is sort of ”common sense” in the agile world today, we all know this. But what if the team model doesn’t fit your needs?

To team, or not to team?

It happened during one of our biweekly meetings that discuss continuous improvements to the process. The question ”Why can’t we split the team?” was raised. The discussion started and soon the more general question ”Why do we work in teams at all?” was brought up. I was sort of defending it, teams are the way to go and we should not change that, but afterwards I started to think. This blog post holds those thoughts.

Questioning teams

Some background first. We have a relatively small development department. It is currently divided into three teams. Each team has their own set of responsibilities. Personnel has stayed fairly intact over time so everybody knows each other in the department. Each developer has a broad competence, meaning that most of them can do all types of work. Some of the developers have ”special competence” regarding certain areas.

Back to the question about teams. It was raised because only two persons is allocated to work with one of our responsibility areas. Two persons are not a team. Why not have a kanban board for that responsibility area, and have a daily meeting where people that has an interest in this responsibility area can participate? The kanban board then don’t belong to a team, but rather to a responsibility area (this could be one of your products for example).

This thought is not new. I recall that I have read in a David J Anderson book that they had a kanban board and a daily meeting with 50 participants (yet the meeting took less than 10 minutes). I hardly think those 50 persons thought they belonged to the same team, more that they shared interest and participated in a work flow (depicted on the kanban board). I also know that Spotify makes many small organizational changes. On a regular basis (quarterly?) they form the teams (they call them squads) needed. Afterwards they evaluate and re-forms the teams if needed.

”Temporary groups”

I have an example of this that I would like to share with you. We needed to make a new release of one of our old products (that is not in our main focus anymore). Before when that have happened, we have spread out the work on the individual teams, to be fair to the persons that holds the ”special competence” needed to make the release. Work has then not become prioritized and have been dragging for months before it got completed.

This time we thought to try something different. Why not setup a ”temporary group” (I call it so in lack of a better name) and take out those ”specialists” needed from their current teams. We prepared a kanban board and set a time for a daily meeting. Work started and the focus was really good, the ”temporary group” completed the release work in 13,5 working days! The same type of release took two to three months in lead time to perform when working the old way. After the release was done, the persons in the ”temporary group” re-joined their former teams.


What I am trying to describe is to have ”temporary groups” that forms some sort of task force to come together to solve a particular mission, then they are scattered to be able to join in on something else. Do you have experience in working in this manner when it comes to software development? I would really like it if you can share your stories!

All the best,
 Tomas from TheAgileist

Smells like team spirit

During my vacation I had a great talk with two of my wife’s relatives. They are both into team sports; one is a youth soccer coach and the other is a professional ice hockey player. My main question to them was: How do you get good team spirit?


(Picture taken from http://www.fotbollskanalen.se)

UEFA U21 2015

Earlier this summer Sweden won the European championships in soccer for players under 21 years (UEFA U21). How could that happen? Sweden is a small country with only nine million inhabitants. Large parts of Sweden are covered with snow during parts of the year, not making ideal conditions for practicing and playing soccer. During the tournament Sweden competed against more respected ”soccer countries” like England, Italy and Portugal. They had teams packed will already well established players with ”star status” in their respective clubs.

Not having the best players on the individual level, there most be something else that made this possible. My take is that it was the team spirit. A strong force that is created when a team comes together as one. Like the following quote:

”The whole of the ant colony is greater than the sum of the ants.” – Andrew Stellman & Jennifer Greene, taken from the book ”Learning Agile”

Factors for team spirit and thereby success

Back to my question about team spirit, here are the answers I received:

  • Trust – A team can’t function if the individuals don’t trust each other. Without trust you don’t have a team, what you have then is individuals grouped together. Trust is the fundamental base for a team.
  • ”Högt i tak” – A Swedish phrase that roughly translates to ”height up to the ceiling”. This means that there is a climate in the group that allows different opinions to be expressed without fear of them being turned against you. This may sound a bit fuzzy, so let’s break it down a bit:
    Questioning – If only one or a few voices are to be heard in a team there is no questioning. Without questioning not all brains are used to make the best decisions possible. Utilizing all brains in the groups is better then just using one! The climate in the team must be that everyone has the possibility to discuss and influence important decisions before they are taken.
    Dare to fail – Without trying out new things and thereby risking failure, no learning takes place. Without learning there is no moving forward. Barely holding up status quo is not an option anymore, your competitors will destroy you!
    Dreaming – Months before the UEFA U21 tournament started no one thought it was possible for Sweden to win! All except one person, John Guidetti, one of the key players in the Swedish team. He thought it was possible, he even said it in media. By formulating the dream, the others in the team bought into it, and made it happen! John Sonmez has a great saying for this: ”Act as if, them become!”.
  • Humble – For the team to be truly successful each individual needs to put the goals of the team first, before any individual and more ”egoistic” goals. The team players needs to be humble to the greater course of the team. This comes very natural for Swedish people, it’s part of of DNA to be part of a group/team and to put the goals of the team first. You can even say that is part of of our social democratic legacy (however now the society is being more and more focused on the individual, like in many other countries). There is another Swedish phrase for this, ”laget före jaget” (translates to ”the team before my own needs”).
  • Acceptance of roles – In a team, different roles and competences are needed. When you are assigned to a role, you need to accept that and not complain that you want to do something else. In a soccer tournament this is especially true for the players that are substitutes and get very little time to play in the matches. They need to hold their head high, not whining, and still contribute to a good team spirit.
  • Time limit – For a team to come together the ”extra effort” needed has to be time limited, like during a tournament. A ”bubble” can only exist a certain time before it pops.
  • Underdog – Swedes like to be the underdog, with no initial pressure, building up confidence for each match and then finally winning it all. It seems to be very suitable for our mentality. Other countries may need the pressure of being favorites from the beginning to be able to ”get that little extra” to win.

How this translates into the world of software development

Some great answers above, but I guess you wonder how they can be translated to our world of software development? Here is my take:

  • Trust – This is a basic foundation for any team!
  • ”Högt i tak” (Everyone is free to express their opinions without repercussions)
    Questioning – As stated, the right level of questioning needs to be present to reach the best decisions in a team. If not, we a back in an old ”command & control”-manner where only one or a few persons make all the decisions.
    Dare to fail – Without the courage to fail sometimes we have no experiments that in turn leads to continuous improvements (kaizen).
    Dreaming – Any team needs a visionary person. Might it be a person in the team or someone ”external” that can influence and ”sell” the bigger picture. However, the ”dream” must be seen as reachable, otherwise the ”dreamer” will just be neglected.
  • Humble – The goals of the team must be treated over the personal interests of the individuals.
  • Acceptance of roles – If you are a developer that is your primary focus. But if testing skills are needed at a certain time, the same person shall not turn those tasks down. Even if you are a striker in soccer, you have to participate in both offense and defense.
  • Time limit – In an organization that works day out and day in, it’s harder to find natural time limits. However, a project is naturally time limited and the time boxing aspect also exist in Scrum with the sprints. These can be used as time limits to create focus.
  • Underdog – What we can take away from this is to set the right expectations for the team. The right motivation will make the team perform better. If the expectations are unrealistic, they will be neglected as stated earlier.


I hope you have got some more ideas on how to create team spirit. It all starts with trust, then humble team players will come together and reach the challenging goals set for the team!

All the best,
 Tomas from TheAgileist

Agile captains

This blog post will tell you about how we define the role of agile captain, something that I know stands out a bit after discussing with others in the agile community.

In Scrum, three roles are defined:

  • Scrum Master – Leads the team and work with removing impediments to get the work forward.
  • Product OwnerReceives, handles and prioritize the requirements for a product.
  • Team members – Persons that are part of the team that shall be cross-functional and self-organizing.

We are in a transition phase from Scrum into Kanban and what roles shall you have then? Looking in the Kanban literature, it only states:

Respect the current process, roles, responsibilities and titles” (taken from Wikipedia)

It feels awkward to call the team leaders for Scrum Masters when we are not using Scrum. We looked to the world of sports for inspiration.


In most team sports, the concept of captains are present. Like in ice hockey for example. The captains are players with extra leadership qualities that leads the others on the ice. They interact with other ”stakeholders”, like the coaches (to discuss game strategies) and the referees (to discuss decisions that are being made). The coaches are not playing the game themselves, they supervise and make adjustments (enforcing different game tactics, shifting players, etc.) trying to win the game.

Agile captains

For me, an agile coach it not necessarily part of the team. This is how we define agile captains:

  • ”C” – The head captain. A servant team leader with some extra responsibilities.
  • ”A” – The assistant captain. Also a servant team leader with a few extra responsibilities. However we don’t really make any difference in status between ”C” and ”A”, they are equal.

One of them lead the daily standup meeting. Why have two? Maybe the captain is sick or working from home one day, then it is more convenient to have the assistant stepping in. It’s also good to be two persons, to have a natural part to discuss with before making a decision. The captains also work as a interface from the team to other stakeholders. Comparing to Scrum the role of captain has similarities to the ”Scrum Master”-role.


  • Redundancy – If one captain is not present, the other one can step in and for example conduct the daily standup meeting.
  • Sharing work load – An example, each team needs to be represented on a high-level planning meeting. Then the captains can decide between each other, given the tasks they have at the moment, who shall participate.
  • Better decisions – Not one single person being responsible for a decision. There is always another person (the other captain) to discuss with, before making any type of decision. Two brains are better than one!


  • No one solely responsible for the team. Since we are not giving the ”C” captain more status, we don’t have one single person responsible for the team. It could be a problem, leading to a ”blame game” between the captains, but we have not experienced this.


The role of agile captain is working really well for us, what do you call your team leaders in Kanban?

All the best,
 Tomas from TheAgileist

Moments of Truth

Now I have done quite a few book reviews. They have all been reviews of fairly new books, released in the last couple of years. This one will be different since the book I’m now going to write about was released already in 1987, but it’s still relevant today. I’m talking about ”Moments of Truth” by Jan Carlzon, it was first released as ”Riv pyramiderna” in Swedish 1985.



Some years ago me and my family lived closed to the place where the SAS headquarter was located between 1987 to 2010 in Frösundavik, Solna, Sweden. When I was on parental leave I would often take a walk with the stroller around the office. It is beautifully located in a surrounding park next to a lake. I would daydream and think of the glory days of SAS (Scandinavian AirlineS) in the eighties when Jan Carlzon was the president and CEO.


This is a fairly short book, no corporate bulls**t, compactly told in 135 pages, and divided into twelve chapters. Here is a walkthrough:

1. A Moment of Truth
By ”moment of truth” Jan Carlzon means the few seconds or minutes a customer contact may last, but that reflects the ”functionality” of the whole organization. A customer-driven company is one that recognize that its only true asset are satisfied customers. A leader of such a company can’t be an isolated and autocratic decision maker. Instead, he or she must be a visionary, a strategist, an informer, a teacher, and an inspirer.

2. The Vingresor and Linjeflyg Turnarounds & 3. The SAS Turnaround
These two chapters tells the success stories of Jan Carlzon’s turnarounds at three Scandinavian travel companies.

4. Profession: Leader
In the summer of 1981, the first year he became president of SAS, Jan Carlzon decided to take a two weeks’ vacation during the summer. At his summer house, he immediately got disturbed by the phone ringing and eventually he gave up and went back to the office. Next year he was interviewed by a newspaper on the subject ”taking it easy”. He agreed on one condition, that the article should be published one week before his vacation. In the interview Jan stated that he believed that responsibility should be delegated and so that individual decisions are made at the point of responsibility, not far up the organizational chart. He stated ”If my phone doesn’t ring, that is a proof that I have succeeded”, and then he went on four weeks’ vacation. And the telephone remained wonderfully silent!

5. Setting the Strategy
First assess the business climate and determine the needs of your customers. Then based on that knowledge, outline a business strategy to meet the customers’ needs within the context of the marketplace and organize your company to intelligently carry out that strategy.

6. Flattening the Pyramid
A SAS office in Stuttgart was given three challenges/goals: 1) cut cost without sacrificing quality 2) increase efficiency 3) give the organization more flexibility. Werner Tarnowski, the man in charge, started with closing down one of the two offices (the workload was unevenly spread). He created one cross-functional team that was responsible for all SAS activities in Stuttgart (cargo, passenger sales etc.). This lead to better service because the organization became more flexible (people with different professions now working as a team and stepping in for each other to solve customer demands immediately).

Jan admits one mistake when flattening the pyramid at SAS. They missed out on the middle managers that felt demoted in the new organization, when ”the frontline people” became empowered. Their new servant leadership felt unusual and they needed to learn new ways to handle this.

7. Taking Risks
Here is a quote from this chapter that I really like:

”Wrong decisions should be used as the basis for training; right decisions should be used as the basis for praise and positive examples. A person who is admonished for his mistakes should be entitled to appeal his case without fear of retribution.”

8.  Communicating
In 1981 to prepare for many organizational changes a booklet called ”Let’s Get in There and Fight” was distributed to all employees of SAS (20.000 persons). The booklet was a tool to present the overall vision and strategy, but most important, set the expectations on the employees themselves. Communication, especially with employees, has always been a top priority for Jan Carlzon. During his first year he spent exactly half of his time ”out on the field” talking to SAS people. Another good quote:

”A leader’s ways are watched carefully and adopted by others in the organization.”

Setting a good example is truly the most effective way of communication, and setting a poor one is disastrous!

9. Boards and Unions
The trick here is to share the knowledge about where the company is and where it should be heading to the boards, unions and employees. For the vision to become reality, it must be their vision too.

10. Measuring Results
One of the most basic mistakes that a service-oriented business can make is to promise one thing and measuring another. You will always steer behavior towards what you measure. If you measure ”the wrong thing”, you will also get ”the wrong behavior”.

11. Rewarding Employees
Unfortunately, in many companies (especially in Sweden) the only thing that gets attention is a mistake. To reward employees can be done in a number of ways, some will be good and others will be bad (it’s the same thing as for measuring, see above), but in the end, the richest reward of them all is being proud of your work!

12. The second Wave
How should you continue when you have reached all your goals, is it then time to settle down? No, because ”Everyone wants a challenge”! I end this chapter with a final quote:

”A true leader is one who designs the cathedral and then shares the vision that inspires others to build it.”


What has this old book have to do while lean and agile, you may wonder. First and foremost the values in this book is well inline with the agile thinking, talking about empowered teams that are cross-functional and customer focused.  Secondly this book is for good and bad still as relevant as it was back in 1985. It’s somewhat sad that we haven’t come further in more companies in the world today. If you are an agile person in Sweden I assume you have already read this book 🙂 For you others in the rest of the world, pick up a copy right now!

I should also say that ”Riv pyramiderna” (the version in Swedish, seen to the right in the picture above) is longer, 213 pages and holds more content (a summary and afterwords written by Jan Carlzon in 2008).

All the best,
 Tomas from TheAgileist

Turn the Ship Around

I was really excited when I got the package from my favorite online bookshop and started to unpack ”Turn the ship around” by L. David Marquet. I have a thing for modern management and submarines (more about that later). I can’t imagine a more hierarchical and ”command & control”-dominated world than the one onboard a nuclear driven submarine! Therefore it’s very fascinating to read how David Marquet was able to turn this strict leader-to-follower paradigm into a new way of thinking with a leader-to-leader approach.



Ever since I was a child I have been fascinated by submarines. I can’t really explain why, and I have never been inside one of them. It was ”close” once when I visited Fisherman’s Wharf in San Fransisco, where USS Pampanito from WWII is tied up, but I bailed out, being a little claustrophobic. That originates from when I was accidentally locked into a closet when I was seven years old (me and a friend was playing with a flash-light and I wanted it to be total darkness and closed the door but the lock was jammed). At the age of eleven I watched ”Das Boot”, it’s a tv mini-series that is an extended version of the movie ”Das Boot” directed by Wolfgang Petersen from 1981. I think the summary from imdb.com pretty much nails what it’s all about: ”The claustrophobic world of a WWII German U-boat; boredom, filth, and sheer terror.” The sounds from the sonar still gives me the creeps! Looking around a bit on the Interwebz I’m not alone saying that this is the best movie around about submarines!


Picture taken from ”Das Boot” found at http://www.guesswhichmovie.com

I just had to re-watch ”Das Boot” once more when I started to read this book! The movie is even more claustrophobic than I remembered it to be, a true recommendation of course! I guess the life on a submarine nowadays doesn’t look like it was during WWII. Another more modern submarine movie is ”The Hunt for Red October” from 1990 with Sean Connery in the leading role. In fact, on the backside of the book it says ”It’s the Hunt for the Red October meets Harvard Business School”. Do you want to hear more about submarine movies, or shall we start to talk leadership and my review of ”Turn the ship around”? I’ll continue with the latter.


In the introduction of the book the structure of Leader-Leader is introduced. I’d like to quote that text.

”The leader-leader structure is fundamentally different from the leader-follower structure. At its core is the belief that we can all be leaders and, in fact, it’s best when we all are leaders. Leadership is not some mystical quality that some posses and others do not. As humans, we all have what it takes, and we all need to use our leadership abilities in every aspect of our work life.”

The book is divided in four parts and they are:

  • Part I – Starting over
  • Part II  – Control
  • Part III – Competence
  • Part IV – Clarity.

First chapter of Starting over is appropriately called Pain. There are seldom any change without pain. Why change if you can’t see any benefits of it? Remember the old saying ”If it ain’t broke, don’t fix it” from Bert Lance. Davids failure, and subsequent pain, came from his unsuccessful attempt to empower his team on USS Will Rogers in 1989. They wished the old engineer back that just ”told them what to do”. Why is top-down, leader-follower still the dominating structure? It’s because it can be effective if you are measuring performance over a short run. Leaders are rewarded for being missed when they quit. When performance goes down after their departure, this is taken as a sign of good leadership. But in fact it should be noted as a failure, not training the people and building a culture that ”survives” on it’s own. Are you asking questions to your colleagues to make sure you know, or to make sure that they know? The part ends with the turning point for David Marquet, it happened when he approached one of the crew members with a simple question ”what do you do onboard?” and got a cynical ”whatever they tell me to do” back. That was rock bottom, from this point on everything could only be better.

Second part Control starts off with an inspiring quote:

”Don’t move information to authority, move authority to the information.”

This means that information should not ”move up” in the hierarchy for make a decision, instead empowerment shall ”move down” as close as possible to the source of information. I.e., everyone shall become managers of their own work. As a leader how do you make this happen? David stated the ”caring but not caring”-paradox. That is, caring intimately about your subordinates and the organization but caring little about the organizational consequences to yourself. One great thing to ”move down” control in the hierarchy is the ”I intend to …”-mechanism they started to use. Don’t tell your  subordinates what they shall do, make them think for themselves and the formulate their thought by using for example ”I intend to submerge the ship” and the captain gives an ok by saying ”Very well”.

Moving on to the third part, Competence, that focus on the mechanisms they employed to strengthen technical competence, first one being ”take deliberate action”. This means that, prior to any action, the person pauses and says what he or she intends to do. The benefits are twofold; 1) It forces you to think before an action and 2) persons around you can stop you if you are about to make a mistake. Competence needs to be in place before you can give control, otherwise it will just be chaos.

Final part Clarity introduces the mechanisms devised to implement leader-leader practices by stressing clarity. To mention a few of them:

  • Achieve excellence, don’t just avoid errors
  • Build trust and take care of your people
  • Begin with the end in mind.


I let the author summarize the book:

”The core of the leader-leader model is giving employees control over what they work on and how they work. It means letting them make meaningful decisions. The two enabling pillars are competence and clarity.”

I can truly recommend ”Turn the ship around” to everybody that wants to ”submerge” into modern management in general, and the leader-to-leader philosophy in specific. This is the best book around about ”sub optimization” (get it? 🙂 ).

All the best,
 Tomas from TheAgileist