Agile

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.”

Content

”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…

Recommendation

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

Advertisements

Democratic retrospective

When a new member started in my team, he brought with him this interesting format for a retrospective. We have fine-tuned it together over a couple of iterations, and now there is time to write a blog post about it 🙂

Democratic Retrospective

Introduction

This format for retrospective have five steps to execute during the meeting:

  • Warm up
  • Zoom in
  • Feedback
  • Voting
  • Discuss & Assign.

Below I will go through each and one of them, in some more detail.

Warm up

We always start with a short warm up exercise to “wake up our brains”. As a facilitator I will put out a statement, like the following, to the meeting participants:

  • “Think one minute for a movie character that, for you, represent the last two weeks.”
  • “Think one minute of a car manufacturer or car model that, for you, represent the last two weeks.”

After a minute or so I address each meeting participant individually, and they have to tell their choice + shortly motive it.

Zoom in

After we have gotten our brains going, we start to “zoom in” on the past time period that the retrospective shall cover. This we do using something we call “Pass the pen” (named as a homage to the good old “Pass the pennies”-game 🙂 )

Preparation: Draw a timeline, vertically (NOT horizontally!), on a whiteboard with three points: “Start”, “Middle” and “End” (see the picture above). The timeline is drawn vertically to make it easier for the meeting participants to write in events (from left to right) during this exercise.

Exercise: All team members are asked to stand in front of the whiteboard, with the timeline drawn onto it. A team member ask to  “pass me the pen” and write one thing/event that did happen during the time period. When done, he or she holds up the pen in the air, and another person can ask “pass the pen” and so on. Let this go on for about 3-5 minutes, or events are stopped being added.

This exercise is used to, as a group, remember what did actually happen during the time period that the retrospective shall cover. It’s very easy to forget.

Feedback

This step is where most of the time shall be spent during the retrospective.

Preparation: The facilitator draws sections on the whiteboard (see the picture above) for the following five categories:

  • 🙂 – Positive.
  • 😦 – Negative.
  • ? – Questions without a solution.
  • <flower> – Positive words to share with a colleague, within, or outside of the team.
  • <lightbulb> – Ideas/solutions.

Exercise: The meeting participants are asked to spend 10-15 minutes on writing post-it:s fitting the five categories presented above.

When everyone is done, one meeting participant at the time, steps up to the whiteboard and puts up their post-it:s + give a short verbal description for each one of them.

Note! Different colors on the post-it:s can be used to separate out each participant, if wanted/needed.

Voting

The retrospective now starts to come to an end, only two steps remain. In this step post-it:s from 😦 , ?, and <lightbulb> are grouped together on the whiteboard. The positive ones are of course great, and we shall be happy of them, but we don’t need to bring them further in the retrospective. For the <flowers>, those are collected by the facilitator and handed out to the ones that received them, after the meeting.

For the voting, the famous agile method of “dot voting” is used. Each participants gets three (or any other suitable number) “dots” to use how they want on the post-it:s.

To not bias each other (that much), all the participants gather in front of the whiteboard, with one pen each, and place their dots “at the same time” (after a “Ready, Set, Go”-call).

The (group of) post-it:s are now rearranged a bit again. Place the one(s) with most votes at the top, followed by the second most votes and so on.

Usually it’s quite easy to sort out the top 3-5 ones. The rest is abandoned, democracy have spoken and they have been decided “not important enough to take further at this point of time” (of course they can, and will, emerge again in a later retrospective).

Discuss & Assign

Time is soon up for the meeting, and the last thing we do is to discuss the top 3-5 activities/tasks that we select to take forward. This is done by discussing them to find concrete actions, and also to assign them to persons (that will own them).

Summary

What do you think about this format for a retrospective? To me it’s a nice mixture of “writing feedback on post-it:s” and Lean Coffee (democratically decide what is most important, in this case, to bring further). This retrospective can (and shall) be combined with an activity to follow up on actions from previous retrospectives. Best of luck with your next retrospective!

All the best,
 Tomas from TheAgileist

Remote Retrospective using Lean Coffee

Do you have any problems with your retrospectives? Is there a few people with “strong voices” that gets their saying every time, talking about what they consider to be the problems, whilst others remain silent (and no light is shred on what they think is wrong)? We had that problem, and it kept me busy thinking for a better approach to perform retrospectives, where we discuss what everyone in the team agrees are the most important.

”Coffee

Lean Coffee & remote team

Since I’ve been attending a few Lean Coffees arranged in Stockholm, I thought that would be a good format to use, also for a retrospective. I fired off some searches on the interwebz, that made me confident that it would work (more information to be found here and here)!

However, there was one more challenge to solve. The team was a remote team, with two individuals not working from the main office. How to solve that nicely? Since I’m a huge fan of digital boards, my solution was a shared board in Favro!

”Board

(Digital Kanban board in Favro with four columns: ”To Discuss”, ”Discussing”, ”Done” and ”Actions”)

Introduction to Lean Coffee

If you don’t already know about Lean Coffee, I will now shortly introduce you to that. So, what is Lean Coffee?

”Lean Coffee is a structured, but agenda-less meeting. Participants gather, build an agenda, and begin talking. Conversations are directed and productive because the agenda for the meeting was democratically generated.” – http://leancoffee.org/

It was created 2009 in Seattle by Jim Benson & Jeremy Lightsmith. If you happen to be in Stockholm and wants to experience the real thing, you can click here for more information.

How does a remote retrospective using Lean Coffee work?

Preparation prior to the retrospective meeting

  1. In your favourite digital tool (we use Favro), set up a simple Kanban board with four columns:  ”To Discuss”, ”Discussing”, ”Done” & ”Actions”. See the picture above for how it can look like.
  2. Provide access to the digital tool for all the meeting participants.
  3. If several of the meeting participants sit together (in a meeting room), bring a laptop and share the screen on a TV/projector.
  4. Use Skype/Slack/other phone conference solution for audio.

During the retrospective meeting

  1. Generating topics – Each meeting participant starts to write 1-2 sentences on for each topic in the past time period (scope of the retrospective) that they would like to discuss. Either they add the ”stickies” directly to the digital board themselves (using their laptop), or the meeting moderator can take the physical stickies and write them into the digital board, using his or her laptop. Remote participants will of course add to the digital board directly. A set amount of time is spent on this step (like 3-5 minutes for a one hour retrospective). All ”stickies” are placed in the ”To Discuss”-column.
  2. Presenting topics – Each topic is shortly introduced by the one who wrote the ”sticky”.
  3. Dot voting – Each participant is given three ”dots” to freely distribute amongst the topics. On the digital board dots (.) (or better *) can be added after the describing text. For convenance, it’s easier if one or two meeting participants do this at the same time (to avoid conflicts and confusion).
  4. Order the topics – The topics are ordered in the ”To Discuss”-column, most ”dots” comes first.
  5. Start to discuss – The topic with the most ”dots” is selected to the ”Discussing”-column. It’s discussed for 8 minutes (a timer is set).
  6. When time is up, participants vote with their thumbs:
    – ”Thump up” – Continue to discuss the topic for 3 more minutes (then vote again).
    – ”Thump side” – We can go on with this topic or take the next, it doesn’t matter for me.
    – ”Thump down” – This topic is discussed enough and set to the ”Done”-column. Move on to the next.
    (Participants in the meeting room uses their physical thumps, remote participants can just say what they are voting, or paint a thumb on the shared screen, this is possible in Slack).
  7. Documentation – During the discussions the meeting moderator shall write comments & actions in the digital Kanban board directly, this information can be taken further.
  8. When to end – Discussion continues until meeting time or topics are out. But what about meeting time ends before all topics are discussed? Well, the team have voted and what they considered the most important topics are hopefully already sorted out. If not, call for a new meeting, or let the topics stay in the ”To Discuss” column for next retrospective (maybe it then gets the votes needed to be discussed, if not, well it’s not that important after all, the team has considered).

After the retrospective meeting

If you (I assume you are the meeting moderator 🙂 ) have played your cards well, you don’t have to do anything afterwards! Actions are nicely put in the ”Actions” column to take further. For reference the topics with detailed comments can be transfered to a more permanent storing in a wiki or Confluence-page.

Summary

I hope you now have a way to perform democratic remote retrospectives! One thing to mention, if the team is not used to this format, is to be a bit flexible with the timer and the thump voting. The timer can be seen a bit stressful and limiting for the discussions. Usually you can ”feel” when a topic has been discussed enough, then you can go on to the next. That goes for the thump voting as well, You can ”see” the level of engagement for a topic, and thereby know when it’s time to move on.

if you have any questions don’t hesitate to contact me. Good luck with your future retrospectives!

All the best,
Tomas from TheAgileist

More Agile ahead!

Hello dear readers,

Long time no see! I haven’t published a new blog post in a very long time… Partly I’ve been occupied with other things, but I’ve also felt that I don’t have anything exciting to write about. Now I have started a new job as Agile Project Manager at Quickspin, a Swedish gaming company. Now I will hopefully be involved in more Agile stuff that I can write about. I also got the spark back for writing again, when I read that another blogger had picked up some of my old stuff!

”Formula”

(Picture borrowed from www.jile.io)

My top 5 blog posts

In the meantime, before I get some new stuff out, I would like to recommend my top 5 blog posts (that continues to attract readers, with a high steady state of page views per year):

  1. The Arrow – Advanced kanban board (This is my evergreen, I wonder if I ever can write another blog post that becomes as popular as this one…).
  2. The Phoenix Project (A book review, that gains awful lot of traffic, and I don’t really know why. I have now started to read a new book by Gene Kim called ”The Devops Handbook”. Stay tuned for that book review!).
  3. Retrospective with timeline (A neat way to get feedback on, for example, a project).
  4. Priority pyramid (My very first visualisation, that also got acknowledged by the Agile community!).
  5. Context switching – Public Enemy No. 1? (This is actually the second blog post I wrote, after the first standard ”Welcome to my blog”. Truly honoured that it still gets so much attention 🙂 ).

Summary

Which one of my blog posts are your favourite? What do you want me to write more about in the future? Don’t hesitate to contact me!

All the best,
Tomas from TheAgileist

Focus & Flow

Travelling on a train that got delayed, I started to think about flow & focus that resulted in this blog post.

”Formula”

Focus <-> Flow

If you can focus (i.e. limited the work done in parallel), you will get flow through your system. If you can show a track-record of  flow (i.e. continuous deliveries), it becomes legitimate to focus. Just like the opposite is true. If you can’t focus you will not get flow. If you don’t have flow, you need to start work earlier (to meet the delivery) and you end up with multiple parallel work activities and you become unfocused. If you can’t focus the flow is gone, and downwards it goes.

So focus gives flow, and the other way around. That gives this simple “formula”:

Focus <-> Flow

Theories is one thing, but I bet that you long for an example that you can start to use right away? Well, here it is a visualisation that creates focus and gives flow in the end of a larger effort when everything shall ”come together”!

Shooting Target

Nowadays we have everything in Jira, including the team’s Kanban boards. Atlassian, that makes Jira, claims it to be ”The #1 software development tool used by agile teams”. That’s very good, but it’s hard (is my opinion at least) to visualise an overview to actually ”see all the work”, especially if you are using multiple projects in Jira, like we do. So when we are approaching the end of a major release, we use a good old whiteboard to ”get everything together”.

”Shooting

At the end of a larger release we use the shooting target that I have blogged about before. It’s a very straight forward metaphor that everyone understands. We aim for the target in the middle, and all the work needs to proceeds in a ”To-do, Doing, Done”-manner from the outer circle to the center. The circle can be subdivided to show different “parts” (like products) that need to come together to make up the release. The shooting target in the pictures has four subdivisions.

”Shooting

Explanation (where to coloured “circles” in the picture above corresponds to the bullets in the list below):

  • Visualization of the needed work – As mentioned we have everything in Jira, residing in several projects. To actually see the work needed to ”tie a release together” this visualization is essential. It better depicts work in front of us, than work already done that Jira shows (and that everyone already have an understanding of, since they have been part of it).
  • Target date – We put up the target release date in the middle to communicate to everyone in team team, as well as outside stakeholders, what we are aiming for. A part from communication, a target date helps prioritization. An example: ”If we shall be ready end of next month, there are no way we can take this work on, it have to wait for the next release!” We can use crystal clear communication, when we say ”we need to hit the target”, we actually mean it 🙂 .
  • Responsibility – As on a ”normal” Kanban-board we use avatars to show who is working on what. This time I simply collected the pictures that the persons uses in other systems (like Slack) and printed them out and glued them on regular square-sized magnets (that I in turn have longtime borrowed from my daughter 🙂 ). Avatars showing who works on what also communicates something else that is very important, what we are NOT working on! As in ”We are focusing on this for now, and leave that to later” or ”Why are we not working on this? We need to start doing that now!”. This type of overview you can’t get in a digital tool like Jira (is my experience).
  • Dependencies – To highlight dependencies (for example to other departments within the company) avatars are used for that as well.
  • Other information – Other parts of the whiteboard are used to keep track of other information, like who is on vacation.
  • Operation of the board – The board is “walked” regularly, and two questions are used by me (as the facilitator):
    1. What have moved since last time?
    2. What is hindering us the most today from “hitting the target”?

Summary

I hope you liked this blog post and that you have a better understanding that you need to focus to get flow. In doing so you achieve a positive spiral where focus and flow enforces each other. The shooting target is one visualization to support focus and thereby flow. Good luck with your implementation of this!

All the best,
 Tomas from TheAgileist

The Goal

It’s a trend that young people don’t read books anymore. Instead they spend time on social media or playing computer games. I, who read a lot of books, see this as a problem. Therefore I really like the initiative from Goldratt Books, to re-publish the legendary book ”The Goal” from 1984, but now as a business graphic novel! Hopefully this format will make the Millennials get the invaluable information about Theory of Constraints.

The full title of the book is ”The Goal: A Business Graphic Novel”, and the original was written, as you all may know, by Dr. Eliyahu M. Goldratt. Dwight Jon Zimmerman and Dean Motter have made the adjustments to this new format of graphic novel, and the book has 143 pages and was released in August 2017.

”The

Content

The book starts with an introduction by Efrat Goldratt-Ashlag (daughter of Dr. Eli Goldratt). Back in 1984 Eli wanted to present his new idea (Theory of Constraints) in a way that would stand out from the normal ”boring” management books. He choose the format of a business novel (or, as some say, a teaching novel). The publishers were sceptical but one of them believed in the format of a novel, and published it. 7 million copies sold, and translation to 32 languages showed that the decision was right! Now Efrat wants to do the same thing her father did, using the graphic novel format to appeal to the readers of today!

What is the story? It’s about a factory (the Unico plant) that has run into severe problems (like late shippings) resulting in layoffs. Alex Rogo, a newly appointed plant manager, is put in charge to fix the problems. Alex spends his time in numerous and seemingly meaningless management meetings. He struggles to find out what the problems for the factory really are, but he finds no answers. One day, at the airport, he runs into his old professor Jonah and asks his for advice. Jonah becomes the mentor to Alex, in his pursuit to fix the problems to save the Unico plant. As the story goes along, the ”bits and pieces” of Theory of Constraints are explained in order to help Alex. I will not give away anything more about the story, you simply have to read it yourself! 🙂

However, I end this review with ”The 5 focusing steps of Theory of Constraints”:

  1. Identify the system constraint(s).
  2. Decide how to exploit the system constraint(s).
  3. Subordinate everything else to the above decision(s).
  4. Elevate the system constraint(s).
  5. Go back to step 1. Warning: Do not allow inertia to cause a system’s constraint.

”The

Recommendation

First of all, ”The Goal” is one of the classics. If you haven’t read it, you should really pick up a copy. I really like the graphic novel format. It appeals to me, and hopefully to numerous of others. This is a must read that I can highly recommend!

All the best,
 Tomas from TheAgileist

The Journey

Right now, when I start to write this blog post, I’m on my way back from the best journey I have ever done! We have been four families, with an age span from 4 to 54, travelling to various locations in the United States (like Hawaii, San Francisco & Los Angeles). We all come from Sweden so it’s a long journey, both in distance and time for us. In this blog post, I will tell about which tools and Agile practices we used to make this journey successful!

”TheJourney

Picture 1 – Sunset seen from Santa Monica Pier

Pre-planning

Google Hangouts

Since the four families lives in different places in Sweden, we needed a tool for our planning meetings. We choose Google Hangouts, mainly because some of us use it at work. The planning meetings had no real structure, but screens we shared to for example show interesting hotels that we could book in the different locations we were visiting. The messaging function of Google Hangouts was also used heavily, to send information and URL:s back and forth. This planning meetings started out already in March (nine months prior our departure).

”TheJourney

Picture 2 – Conversion on Google Hangouts planning the trip

Airtable

After a while, we had agreed on a travel plan and we started to do bookings of flights and hotels. We took help from a Traveling Agency for some of the bookings (they were for example able to book cheaper flights). With a lot of information gathered that we needed to keep track of, we selected Airtable as the tool. It is an online tool, and it is easy to invite members to use it. It can be seen as a cross-over between a spreadsheet and a Kanban-board. We used Airtable to store information about our booked flights and hotels as well as suggestions of tourist attractions we wanted to visit.

”TheJourney

Picture 3 – Collection of tourist attractions we wanted to see, gathered in Airtable

The actual journey

The framework for the journey was set with all the bookings we had made. We knew how many days we had planned to stay at each location.

Planning meeting for activities

When we arrived at a new location I hosted a planning meeting to have everyone to agree on what activities we should do the upcoming days. Given the span in age and different interest in the activities, we of course sometimes splited the group of four families into other constellations. Overall, we kept a general plan for each location that everybody agreed upon.

Board for activities

To capture and visualise the planning I put up a simple board with post-its on whatever I found suitable (pro-tip: bring your own tape to make the post-its stick better 🙂 ). One column for each day at the location, and three rows dividing a day into three sections: Before lunch, afternoon and evening. This showed to be pretty sufficient for our needs.

”TheJourney

Picture 4 – A planning board on a glass table

Google Maps

All four families rented their own car for travelling in California, US. The traffic in Los Angeles can be pretty hectic, so it was nearly impossible for us to drive together as a group. To solve this problem we planned routes using Google Maps. We did that at the hotel, while having access to wi-fi. The good thing with Google Maps are that routes can be downloaded (the person who planned the route shared the link using Google Hangouts, and all the other ”navigators” in the separate cars downloaded it to their phones, while having wi-fi access). This way we saved money, not to use roaming to get mobile data. The one thing you miss navigating after an offline route, is traffic updates. Normally this is no problem. But it becomes obvious during rush hours, then Google Maps can offer alternative routes depending on the traffic situation. Sometimes we turned on mobile data when driving in rush hour, to get these traffic updates. 

Overall, we had a very positive experience using Google Maps on the phone for navigating, compared to an ordinary GPS. Actually, the car rental firm wanted 197$ for GPS in the car. Way to expensive!

”TheJourney

Picture 5 – Navigating using Google Maps, shown in offline and night time mode

Summary

The stuff described above helped us to have the structure needed to be able to perform a trip of this kind, without any major disappointments. Travelling a large group together can be quite challenging, and I wouldn’t recommend doing it without any pre-planning/structure (carpe diem may work if you are a smaller group).

All the best,
 Tomas from TheAgileist