Agile Conversations

Today the book “Agile Conversations” by Douglas Squirrel and Jeffrey Fredrick is released! I was kindly given the opportunity by the publisher IT Revolution to read a beta copy, to be able to provide you with a review. IT Revolution is an upcoming publisher for IT related books, and also the “home” of Gene Kim (whose books I’ve blogged about here, and here).

Agile Conversations

Content

This book is divided into two parts and seven chapters, they are:

  • Chapter 1: Escaping the Software Factory
  • Chapter 2: Improving Your Conversations
  • Chapter 3: The Trust Conversation
  • Chapter 4: The Fear Conversation
  • Chapter 5: The Why Conversation
  • Chapter 6: The Commitment Conversation
  • Chapter 7: The Accountability Conversation

First chapter starts off by “setting the scene”: The agile transformation is complete, the organization has bought in, the teams are trained and the processes are in place. Why aren’t things better? The key to success in not only adopting practices but having the difficult conversations that foster the right environment for those practices to work.

“When we change our conversations, we change our culture” – Douglas Squirrel & Jeffrey Fredrick

Taylorism (as Frederick Winslow Taylor wrote about 1911 in his book “The Principles of Scientific Management”) is described. Where managers told their workers exactly what to do, and not sharing any knowledge. In software, the equivalent was documentation-driven development (Waterfall). Then came Agile software development, Lean software and DevOps to disrupt and transform the software industry. 

The second chapter starts by going into details about our human conversations i.e., our “super power”, that made us the dominant species on the planet. We all have conversations, many times every day, but most people don’t take the time to actually learn from them. This book tells you how!

The Four Rs are introduced:

  1. Record – Start by recording your conversation with another person (or group of people) in writing.
  2. Reflect – Look and start to learn from your recorded conversation by using the tools that are introduced in this book.
  3. Revise – Revise your conversation to try to produce a better result. 
  4. Role Play – Find a friend who is willing to help, and try saying your dialogue aloud, with your friend taking the part of your conversation partner.  For even deeper learning you can do 4.1 Role Reversal, and you will get to “hear yourself speaking” 🙂 

Chapter 3 to 7 then in depth covers the five different types of conversation. 

Takeaways

My main takeaways from reading this book, are the five types of conversation: 

  1. Trust“We hold a belief that those we work with, inside and outside the team, share our goals and values.”
  2. Fear“We openly discuss problems in our team and its environment and courageously attack those obstacles.”
  3. Why“We share a common, explicit purpose that inspires us.”
  4. Commitment“We regularly and reliably announce what we will do and when.” 
  5. Accountability“We radiate our intent to all interested parties and explain publicly how our results stack up against commitments.”

Recommendation

This book comes with a bold statement, to fix your broken agile transformation! I think it can, but it requires a lot of hard work! I sincerely hope people will read this book and practice, at least I will, but I’m worried people will only reach for the “quick fix”.  

All the best,
 Tomas from TheAgileist

Remote working

Given the extraordinary situation we have now in the world, more and more companies look into remote working. Now I’ve been part of a geographically distributed team for 1,5 years. In this blog post I share my experiences working in a remote team.

Remote working

Remote Team Setup

We have one person working from home almost full time, only traveling to the office for important meetings (a few times a month). The rest of us works mostly from the office, while WFH (Working From Home) a few days a week.

Daily Standup

For the Daily Standup we use Slack. We have a private channel just for the team members. The call is made using voice (video doesn’t really add anything, since we all know each other so well in the team). The leader of the meeting (usually me) shares the screen and we look at the team Kanban board in Jira. Then we talk in the same turn every day, to avoid the little delays created by wondering “Who’s next?”. Sometimes a person wants to discuss/show something, and then that person shares their screen instead. 

Retrospectives

I’ve written about remote retrospectives earlier. Then we used a shared digital board in Favro to drive the meeting. Currently we use a shared Excel file to have a slimmed down version of “Democratic Retrospective”. Hopefully I will find time in the future, to blog about this in more detail!  

Internal Workshops

For workshops you really need to go the extra mile when performing them remotely. Ideally a workshop is a meeting room full of engaged people sharing thoughts on a whiteboard. To mimic that remotely, is to be fair, not easy. 

There are digital online whiteboards that you can use as a substitute. We have used webwhiteboard. Be prepared that participating in a remote workshop requires you to be fully focused, and to listen very carefully. More than if you are sitting in a meeting room. This to not lose out on any nuances. We use Slack and call in a separate team channel for internal workshops. 

Charge your batteries before entering a remote workshop, and also give yourself the time to rest a bit afterwards, since they have to be intense to be productive. 

Communication during the working day

During the working day most of the communication is happening by using text messages in Slack. Normally each initiative/project has its own separate channel. If needed, persons or groups call each other up to also talk about work, if that feels easier than writing. 

Partner/Customer Meetings

To have a meeting with a partner or a customer, meaning another company, you can’t decide tools to use just by yourself. You have to align, and that lowest common abbreviation seems to be Skype.

For this type of meeting I always prepare a Powerpoint presentation. First page is the agenda, and then one page per point in the agenda to drive the meeting. I share my screen to show this presentation for the other meeting participants. This presentation is important to “drive the meeting”, while I take meeting notes on paper, or on the laptop using a different screen (with dual monitors). 

All Hands

We have a monthly All Hands meeting where people from all offices (or home workers) call in. For this type of meeting we use Zoom.  

Discipline and routines

Here are some tips and tricks how you shall behave when working remotely: 

  • Always be ready a few minutes before a remote meeting starts, so you can connect on time! At an office the meeting host can always “run around and grab people that are late for the meeting”, that option doesn’t exist when working remotely. 
  • Do not call in to a remote meeting from your workplace, if you are sitting in an open landscape. The background noise the microphone picks up will negatively affect the meeting. If you have to, use a proper headset with microphone (not the built in microphone of the laptop).
  • Clear communication is key! You have to put extra effort into explaining what you mean, since your whole body language is usually left out of the equation when working remotely. Sure you can use a video call, but then you usually look at a presentation on the screen, and the video of your face will be lost (or only seen in a tiny part of the screen). 
  • All tools and resources you have access to from the office network have to be reachable from physically everywhere, either directly, or using VPN
  • Have proper equipment, and know how to use it! Spending the beginning of EVERY remote meeting sorting out technical issues is not a good start. 
  • Have routines, and stick by them. Set the alarm the same time every day. Eat lunch the same time every day, don’t do it in front of the computer just because you can. Go for a walk during lunchtime instead. Have food prepared so you don’t have to cook from scratch every lunch, or you love cooking and want to spend that extra effort, go ahead. Find the routines that work for you! 

Summary 

As you can see there are a lot of different tools involved when working remotely. Is this a good thing? Maybe not, to use one or a few tools is of course preferable, and maybe that is the case in larger corporations? The rest of us may just have to face the fact that we need a large number of tools installed on our computer to be able to work remotely!

All the best,
 Tomas from TheAgileist

Team Planning day

Once in a while, we decide to take a whole day with the team to look forward, but also to get some new inspiration. I’ve been running this workshop as a facilitator, and the format has been very appreciated, so I thought I would share it with you!

Introduction

We separate the day into two parts, before and after lunch. The idea is to “zoom out” and get inspired before lunch, and then “zoom in” on the work closest in time for the team.

Before lunch

Before lunch the focus is to look ahead (maybe 2-3 years) to set out the direction for the team. All team members also get their chance to speak up on what they think are the most important things for the team to do in the near term future (1-6 months). Just before lunch, it’s time for some inspiration! That could be an external speaker coming in, some in the team that want to share an interesting topic or even watch an educational video together. The topic chosen shall be related to the team’s work, but not be about actual work (that is covered in the afternoon).    

After lunch

This blog post is mostly about explaining this section in the workshop, that will be done below. But first, let’s look at the agenda in total (so you can copy and use it yourself 🙂 )

Agenda for the day

  • 09:00-09:05 Welcome (Facilitator)
  • 09:05-09:50 Direction for the team, 2-3 years ahead (Manager from mid- or top-management, dependent on your company size)
  • 09:50-10:00 Fika break
  • 10:00-11:00 All participants to share (10 minutes each, again dependent on team size), what they see as the most important things to get done in the team 3-6 months ahead (All)
  • 11:00-12:00 “Inspirational talk” (External speaker, Team member or Youtube video)
  • 12:00-13:30 Lunch (All, take the opportunity to take a longer lunch to socialize)
  • 13:30-16:30 Planning for 1-6 months ahead (All + Facilitator)
    • With the information given before lunch, all things are listed on a whiteboard. Then we go through each item in the list and place them in a matrix (with “complexity” on the X-axis and “value” on the Y-axis).
    • When everything is placed out, what shall be part of the coming 1-3 months is decided.
  • 14:30 Fika break
  • 16:30-17:00 Summary and closing of the workshop (All)
    • Summarize what has been decided (see above).
    • Mini retrospective – Let everyone share their thoughts about what they have gotten out of the day.

Execution of the planning part

Ok, the team is inspired and not hungry anymore, let’s spend some time on how to execute the planning part of this workshop. 

List the work

With every team member given the opportunity to share their mind, it should be fairly easy for the facilitator to start to write down work items in a list on a whiteboard. The key for this part is to NOT go into discussion of each work item added in the list, that should be kept for later. Usually this step takes 20-30 minutes to perform. 

Example of list of work:

1. Work item X

2. Work item Y

N. Work item Z

Try not to add more than 20-25 work items. If you add more, you will not have the time to discuss them enough in the next section. 

Discuss each work item (“complexity” and “value”)

(Example of references to work items added to the chart) 

Now comes the tricky part, that needs to be carefully facilitated. Each work item from the list is added in a chart with:

  • Effort/Complexity on the X-axis – How easy (or hard) something is to do, is usually quite simple for the team to understand and have an opinion about.
  • (Business) Value on the Y-axis – Here the team has to give their opinion on the value the work item will bring. Value is very subjective, one rule of thumb is that it shall mean some sort of business value for the company. When you have added a few work items to the chart this part gets easier and easier, then you can ask “Will this work item Y bring more value than work item X?” (work item X already added in the chart). If yes, you will place work item Y higher up than X, if not, you place it lower and so on.   

Write the reference number to the list in the chart, if you have the work items on post-it:s, you can place them in the chart. If you are successful you should end up with something that looks like the picture above. 

Select work items for the near future

Final part, before wrapping up, is to discuss and decide on the work items to pick up for the near future (1-3 months). This is how you should think:

  • Upper left corner (“high value, low effort”): This is the “low hanging fruit” that you obviously shall pick first! These work items bring “high value” to a “low effort”.
  • Upper right corner (“high value, high effort”): Your next focus shall be to look here for work items that bring high value. Maybe you can also discuss them in a bit more detail to bring down the effort needed (start by doing small pieces of the work item).
  • Lower left corner (“low value, low effort”): You might want to consider work items here, since they are “low effort”, but not before any work items “above the X-axis” (giving “high value”).
  • Lower right corner (“low value, high effort”): Any work items ending up here you should not consider at all!

You can see above in the picture what we selected (circled) as next work items to do in the two coming releases of our product.

Summary 

Did you find this blog post interesting? Here is another blog post I wrote about value. Our goal is to revisit this planning within 3 months, and update with new work items and to review what we should focus on next.

All the best,
 Tomas from TheAgileist

The Unicorn Project

Today the book “The Unicorn Project” by Gene Kim is released! Since I had written a review about his previous book “The Phoenix Project”, I was kindly given the opportunity to read a beta copy to be able to provide you with a review. Here it is!

The Unicorn Project

Content

In this new book Gene Kim re-visits the successful novel format from “The Phoenix Project”. Once again we are back at the company Parts Unlimited, and the main character of the story is Maxine Chambers, a Lead Developer and Architect.

Throughout the story, The Five Ideals are explained to the reader, with a lot of good examples. 

The Five Ideals are:

  1. Locality and Simplicity
  2. Focus, Flow, and Joy
  3. Improvement of Daily Work
  4. Psychological Safety
  5. Customer Focus

Back to the story, what happens during the 19 chapters this book consist of? First there is a major payroll outage, and the management needs to find a scapegoat, guess who? Maxine is punished by being reassigned to the Phoenix Project, which feels like a prison. Heck, Building 5 at corporate campus where they sit, even looks like a prison.

To start, Maxine wants to get a Phoenix build running on her laptop. But this seemingly easy task is nearly impossible, to get through endless layers of bureaucracy. Hope is almost lost when she meets Kurt Reznick (a QA Manager at Parts Unlimited) and joins the Rebellion (a group of likeminded people that wants to work in a different way, by living the The Five Ideals).  

They start off in small scale, overcoming some setbacks during the way, and in the end they manage to turn the company successful again! Read the book to find out how they did it.

Takeaways

My main takeaways from reading this book are: 

  • The Five Ideals are a nice addition to the “Agile arsenal”. Especially Psychological Safety, that I see as a cornerstone for innovation.
  • There is a lot of talk about unicorns (“A unicorn is a privately held startup company valued at over $1 billion”). This book shows that an old large company also can, and inevitable must, be like a unicorn to survive. 
  • A story based on good vs. evil never goes out of fashion. This particular one is also packed with references to things like Star Wars and Game of Thrones 🙂

Recommendation

Gene Kim have a very good sense for knowing what is going on, and to see the trends, in the IT business. That compared with his writing skills, creating a very interesting story, makes this book a solid recommendation! You have not read “The Phoenix Project”, and think it’s needed? No worries, “The Unicorn Project” can be read as a standalone book.

All the best,
 Tomas from TheAgileist

Design Thinking

This week I was invited by a former colleague to attend a breakfast seminar with the title:
“How to create Business Value through Design”

To be honest I barely know anything about this subject, but I was drawn to it by my former colleague’s words how it can “co-exist with the Agile world”, that I’m much more familiar with.

The presenter for the day was the professor and author Jeanne M. Liedtka, apparently her first visit to Sweden.

The Customer

(Picture taken during the presentation)

Introduction – What is Design Thinking?

Jeanne stated that there are as many definitions as there are experts in Design Thinking, but the one she is using was the following:

“Design thinking is a systematic approach to problem solving. What would be different if managers thought more like designers? Problem solving would be driven by three core beliefs:

  • Empathy – Start by establishing a deep understanding of human needs
  • Invention – Discover new possibilities
  • Iteration – Use the first solutions only as stepping stones to a better one”

Interesting quotes

During the presentation Jeanne said some interesting sentences that I wrote down, below I have tried to expand on them:

  • “Innovation is the new quality” – I couldn’t agree more. Everywhere you hear talk about innovation, we really need to innovate and so on, but many doesn’t seem to have figured out how yet. Maybe Design Thinking have all the answers?
  • “Don’t take data from the past to guess the future” – Nowadays you need to be “data driven”, but using existing data you can only take your product or service further in a predictable way. You really want to know your customers unmet needs.
  • “Innovation is not disruption” – This also strikes me alot. Whenever there is talk about innovation, the iPhone is brought up. Like there is only a small amount of people or companies that have the capability to make innovations, where it should be the total opposite (see next bullet below).
  • “Everyone can create better value” – You want every person in your company to feel that they can add to the whole, even “tiny steps” are a way forward to the bigger goal. 

Value delivered by design thinking

Jeanne ended her presentation by summing up the values delivered by design thinking:

  • Toolkit for producing more creative ideas
  • Risk management strategy
  • Facilitator of behavioral change
  • Vehicle for empowering local capability building
  • Way to convene conversations for change across diverse stakeholders.

Summary

Are you an agileist like me and have started to learn more about design thinking? Maybe you are an expert already? Whichever it is, I can now add CX (Customer Experience) to my list of known abbreviations 🙂

All the best,
 Tomas from TheAgileist

How to eat an Elephant?

Hello, let’s talk about the Elephant. Which Elephant, you may ask? I mean the elephant in the room. First of all, what is meant by that? A quick Googling give:

“If you say there is an elephant in the room, you mean that there is an obvious problem or difficult situation that people do not want to talk about.”

”Elephant”

(Picture borrowed from sw.wikipedia.org)

Introduction

Have you had an elephant in the room? We have, for sure. For us it was building a new GUI. That task itself is possible to predict, plan and eventually execute. But given that the GUI is a very central piece in our product, there is tons of dependencies to it. So the impact a new GUI have on other components is very hard to predict, and “touching the GUI” becomes very risky. 

I was given the project that should, amongst other things, produce a new GUI. I had numerous meetings with people from all parts of the organisation, but got nowhere closer to a new GUI. We just went around in circles, until one day I realised, the organisation deems it’s almost impossible to build a new GUI. I, as being the project leader, was totally stuck… 

Story

I have a former colleague, his name is Alexander and he will soon retire after a long and very successful career. Alexander is extremely intelligent, a person that you come across once, or maybe twice, during your entire work life. If there was a question, he knew the answer, no matter what the question was about. I’ve learnt a lot from Alexander, but maybe the most important wisdom is the one I will now tell you about.

How to eat an elephant?

Once, Alexander and me, had the following conversation:

  • Alexander: “Tomas, how do you eat an elephant?”
  • Tomas: “Well I’m not sure… Usually I don’t eat elephants.”
  • Alexander: “You eat it in pieces, Tomas. IN PIECES!”

This, for me, is the most crucial part in Agile! In the project we now have addressed the first piece that was deemed most crucial, now we are planning to work on the next. I, as the project leader, feel confident again, and we are making progress! 

Summary

The learning from the conversation above, is that the only possible way to attack a huge problem is to break it down into pieces, and to work on the individual pieces. 

When you have done this for some time you have either “eaten the whole elephant”, or at least so much that you are satisfied.

All the best,
 Tomas from TheAgileist

P.S. I have never eaten a real elephant, and I never will… 🙂 D.S.

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

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

Humans vs Computers

I first learned about Gojko Adzic, who is the author of the book I’m soon going to review, when a friend told me about this presentation on YouTube ”GOTO 2014 – Adaptive Planning Beyond User Stories”. He is also the author behind other books, like ”Impact Mapping: Making a Big Impact with Software Products and Projects” & ”Fifty Quick Ideas to Improve Your User Stories”.

I let Gojko himself introduce you to this book, ”Humans vs Computers”:

”As a professional software developer, I’m much more guilty than the average person of driving civilisation towards a digital apocalypse. At the same time, I’ve been on the wrong end of a computer bug frequently enough to appreciate the pain that such a thing can create. This book is my attempt to raise awareness about some common and dangerous, but perfectly preventable, types of software blunders. I also want to help ordinary people fight back against digital monsters.”

Humans vs Computers - Cover

Content

As you now may imagine, this book is full of anecdotes about software working bad 🙂 The stories are divided into the following sections:

  • Artificial but not intelligence
  • The surprising facts about our world
  • Algorithms as fast as food
  • Wild wild tech
  • The inverse monkey rule

As an example I can tell you about the first story presented in the book, called ”Licence to void”. This is about Robert Barbour from Los Angeles that wanted a new licence plate for his car. Barbour was fond of sailing and selected as his top two choices BOATING and SAILING. But the form he was using had three mandatory fields, so he had to give one more, and wrote ”NO PLATE”. A few months later a computer at the Department of Motor Vehicles interpreted literally something that humans would easily understand as a missing piece of data. Barbour’s first two choices were already taken, so the licence plate was issued for his third choice.

A plate saying ”NO PLATE” sounded quirky enough so Barbour kept it. The problems started a month later, when he started receiving notices for parking fines from all over California. When a illegally parked vehicle did not have a licence plate, the officers still had to to issue a ticket and the computer system needed a plate, so they wrote ”NO PLATE” 🙂

Recommendation

If you are in the software business this is a fun book to read. The last section ”The inverse monkey rule” also gives you advice on how to avoid the errors described in the book.

All the best,
 Tomas from TheAgileist