Retrospective with timeline

I hope you do your retrospectives regularly? That is a good way to learn about what you do, and to keep your continuous improvements (kaizen) going. In this blog post I will describe a variant of a retrospective we performed, with a timeline to visualize what have happened during the time period we discussed. We used stickies in different colors for Good (Green), Bad (Red) and Improvements (Yellow) that we put up on the timeline. Why did we use it? The timeline helped us remember better.



Before the actual retrospective meeting, you need to prepare the timeline. Basically remember on a high level what was done during the time period. I sat down and did this on a piece of paper.


In our case the time period spent over 6 months and I draw boxes for the main activities that happen. I also added numbers to each activity that was used as reference (see more information about that below). That was all the preparations I did before the meeting.

Retrospective with timeline

This is how the “retrospective with timeline”-meeting was performed.

  1. Some 5-10 minutes before the meeting started, I went to the meeting room and draw on the whiteboard the timeplan that I’d prepared. I also brought my stickies in different colors.
  2. The meeting started with me explaining the procedure. That each participant should think for 10-15 minutes and write stickies categorized as: Good (Green), Improvement (Yellow) or Bad (Red) and also add the number to reference the activity. A certain number (in our case 7 – Common) was used to specify common things that couldn’t sort under a activity, or covered the whole time period. The numbering made it easy to put up the stickies on the whiteboard.
  3. After all the stickies from the meeting participants were added to the whiteboard, they were discussed individually. We used the numbering to do all “Good, Improvement and Bad”-stickies for the activity in question. It becomes very visible if an activity was successful or not (a lot of Green stickies, versus a lot of Yellow/Red ones).
  4. After the meeting I always take a picture of the whiteboard using my mobile phone. The numbering on the stickies makes it easy to take them down and move them to your desk, where you preferably produce some sort of documentation of the meeting.


This retrospective is the one we used back in the days we had Scrum as our agile framework, but now with the timeline as a twist. The timeline adds value if the time period discussed is long (in our case 6 months, but can be both shorter or longer depending on the context), or if persons have been “in an out” for the activities (not participating for the whole time period).

All the best,
 Tomas from TheAgileist

I got ninety nine problems but the blog ain’t one

I’ve made it! This is blog post number 100! I could never imagined that this would happen when I started this blog two years ago. My first blog post was published on the 11th of October 2014, and was called ”Welcome”. In that post, I claim myself to be an agileist, with the following definition:

To fully define an agileist – he or she helps and coaches other people, thinks a step further, and is also realistic and know that there is a long way to go to ”reach for the stars”.

I have tried to think a step further and to share this with you. Hopefully I’ve made some valuable contributions during these two years, but you are really the one to tell me if I have fulfilled my promise or not.

Most popular blog posts

Here is the top ten list:

  1. The Arrow – Advanced kanban board
  2. Priority pyramid
  3. Trello as ”whiteboard simulator”
  4. Scrum and XP from the trenches, 2nd edition
  5. The Volcano – Enterprise kanban board
  6. The Nature of Software Development
  7. Soft Skills
  8. Applied Capacity Planning
  9. Personal Kanban in Favro
  10. Lean and Agile in three pictures

I’m very honored that two of my visualizations are in the top! Visualizations have been the topic where I’ve done most work, and hopefully contributed the most. Are there any blog posts that I think deserves a bigger audience? Yes, here is that list:

  1. Google Docs, Sheets & Slides in remote meetings
  2. Bug Triage
  3. Agile captains
  4. Feedback Loops 2.0
  5. The Circles – Products´ lifecycle visualization

Monthly statistics

After a slow start, the blog has pretty solidly reached over 1000 page views per month, for which I am super happy! The best month (February 2016) reached 2276 page views, thanks to the post about using Trello as a ”whiteboard simulator”.


Visitors from all over the world

The picture below shows that this blog have had visitors from an amazing 128 countries! This is totally mind blowing! It is difficult to grasp that people from as remote places (from me) like Lesotho, Mongolia, French Polynesia and Nepal have visited my blog.


When it comes to countries with most visitors the top 20 looks like this:

  1. Unites States
  2. United Kingdom
  3. Sweden
  4. Germany
  5. Brazil
  6. France
  7. Canada
  8. Russia
  9. Australia
  10. India
  11. Spain
  12. Poland
  13. Netherlands
  14. Italy
  15. Belgium
  16. Ukraine
  17. Denmark
  18. Ireland
  19. Finland
  20. Norway

In the future to come

What will happen now? To be honest I don’t really now. I’ve kept track on how much time I have spent on blogging during these two years and the total is 400 hours. Given that I’ve written 100 blog posts, that gives 4 hours per blog post in average. In the beginning they took a bit longer to write, nowadays that time is shorter (hopefully it’s because my writing has improved, not me being lazy). I have not earned anything on blogging, apart from the experience and fruitful feedback from you (that makes it worthwhile). So in one form or another I will hopefully continue, despite that I have 99 (literately) other things going on. I have a full time work, a wife and two kids that have their activities that I support, and I also have my own other interests. The time for blogging is limited to say the least.


What do you think of this blog? Does it bring value to you as a reader? I would really like if you could take some time to give me feedback. Maybe you have some ideas on topics that you want me to cover?Thank you very much for reading! Arrivederci!

All the best,
 Tomas from TheAgileist

Värdefokuserande teamarbetssätt / Value focused team working

I first got in contact with Joakim Holm and Jagannath Tammeleth (the authors of the book I’m about to review) at Agila Sverige (Agile Sweden). Actually, this year the conference was kickstarted by Joakim, dressed up as a punk rocker talking about ”Agile is not dead – It only smells a little”. Via Twitter I found out that the book with the Swedish title ”Värdefokuserande teamarbetssätt” was released. That roughly translates to ”Value focused team working”, the subtitle is ”A guide in eight steps for teams that wants to master the basics in agile system development”.

This is actually the second time I do a review on a book written in Swedish, my native language. I realize that many of you will never get a opportunity to read the book, but according to my blog statistics Sweden is in third place when it comes to visitors (after USA & UK). The book has 154 pages and was released in 2016.


“Agile is ordering tapas til you’re full ‒ not ordering a 10-course meal.”  ‒ Neil Killick


The team ways of working selected for the book are (each covered in a chapter):

  1. Small batch sizes
  2. Maintaining a backlog
  3. Common planning
  4. Agreed guidelines
  5. Visual guidance
  6. Sync meeting
  7. Demonstrate the result
  8. Continous improvements

Does those ways of working make a good representation for a team? Yes, I think so. I can’t come up with anything that should have been added to the list. Each chapter has sections for: purpose, description (i.e., more details), learnings from the reality and references to further reading. All topped up with recommendations and tips!

Small batch sizes are fundamental in agile. And the ambition to go from large batch sizes (enormous waterfall projects that are doomed to fail) to small batches (handling customer deliveries in a continuous flow). Large batch sizes gives delays that in turn hid process problems that never will surface. On the other hand it’s not easy to shift to this way of working if you are coming from waterfall.

The backlog is something very familiar for an agile team. To produce a backlog is not a one time job (you do it and then you are finished). The backlog needs to be looked after all the time. A way for the team to understand what is important is to have a common planning.

It may not come as a big surprise that visual guidance is my absolute favorite thing about agile. It’s said that ”a picture says more than thousand words” and it’s really true. What you ”see”, you can do something about. What you don’t ”see”, well, there is nothing you can do then.

The sync meeting is usually the first ”aha moment” and most valuable thing, when starting with agile ways of working (being a team using Scrum and Kanban). Starting off the days by sorting out what is most important, who needs help, etc., has been done before but with agile it has really got high-lighted.

When first starting with agile ways of working (being a team using Scrum and Kanban) the first ”aha moment” and most valuable thing is the sync meeting. Starting off the days by sorting out what is most important, who needs help etc. has been done before, but with agile it has really got high-lighted.

The get feedback on your work, one good way is to demonstrate the result to others. I think the demo is a good thing, but sometimes it represents a too long feedback loop (to get input on your work when you are done, not when you are doing it).

Finally the fundament in lean, the continuous improvements (also known as kaizen). I’ve heard a story about an agile coach that was hired to ”implement agile” within a company. He started out with implementing just one practice, the retrospective meeting. With that in place he could steer continuous improvements to set the other principles and practices in place.


I really enjoyed reading this book! It is short, well structured, and to the point. The illustrations are awesome! I also really liked the fact that it took the standpoint from the team’s view, when describing good agile ways of working. If you can read Swedish and want to have value focused team working, you should definitely check it out!

All the best,
 Tomas from TheAgileist

Feedback Loops 2.0

Earlier on in this blog I have written about feedback loops. Time has come to revisit that topic, and also to talk a bit more how we do it right now.  


One of the six Kanban core practices is “implement feedback loops”. Short loops gives the possibility for fast feedback. Our feedback loops are mainly implemented as a set of meetings with different cadence.



The purposes of the meetings with different cadences are the following:

  • Improve quality – By giving early feedback on work, errors can be found and corrected when they are “small”, and not later when they become “disasters” (i.e., found in production by customers).
  • Reduce context switching  – By giving feedback fast, the context is still “active” and no context switching is needed (that takes time and reduces the overall productivity).
  • Implement feedback loops – As mentioned earlier, it’s one of the six core practices in Kanban.

Meetings with daily cadence

Daily standup

The purpose is to enforce all six Kanban core practices. The team captain conducts a daily standup in front of the kanban board, with all team members present. Other stakeholders can listen in. Focus is to get tasks to flow through the process, and taking care of and removing impediments (bottlenecks that are preventing the flow).

Bug Triage

We believe that over time more brains makes better decisions than just one! To prioritize between bugs is an activity known as “bug triage” in the software industry. All new bugs entered in the ticket system shall pass this meeting for decision. Fix or not? If fix, when – current release, upcoming or future? Is the bug valid, if not close.

The bugmaster (yes that’s the name!) conducts the meeting and goes through the list of bugs currently in the state “Dispatch”. Afterwards the ticket system is updated with all the decisions made on the meeting.

Meetings with weekly cadence

Status, Planning & Prioritization

The purpose is to follow up on already made commitments, but also to be agile and be able to act fast on changes from customers or in the market.

This weekly meeting has the following agenda:

  1. Action points from last meeting.
  2. Discuss the overall planning, currently we are using “The Circles”.
  3. Discuss and prioritize activities in “The Volcano”.
  4. Any adjustments needed in time, cost or scope? We work in teams, but team members can move between them to where they are needed the most for the time being. If we can, we cut the scope for a release (we work in priority order, starting with the things that are promised to customers so it is possible). A last outcome is to postpone the release (change the release date).
  5. Any other business. Sometimes we use “The Shooting Target” to focus when we get closer to a release for a product.

The Head of Project Management is conducting this weekly meeting together with other stakeholders and the captains from the teams. A written protocol is produced and made available after each meeting.

System architect group

The purpose of this meeting is to secure that we have an architecture for our products that is sustainable and can live a long time. General topics around the architecture is discussed (security, scalability, redundancy etc.), as well as all tickets marked “Sysarch” in the ticket system. The Head of Development leads this weekly meeting together with all system architects.


The purpose is for developers to show their work on regular basis and to get early feedback on it (before it is “too late to change”). The demo is conducted on Friday afternoons together with “fika” (Swedish phenomena – like an extended coffee break) in the control room.

Meetings with monthly/quarterly cadence

Release planning

The purpose is to produce a prioritized scope (specified on high level) together with a time plan (release date) for the coming release of a product. Stakeholders meet in one or several meetings to discuss:

  • Targets – What do we aim for with this specific release? The targets must be meaningful and understandable to ALL! They shall also be helpful in the daily work. “Shall I do A or B?”, the targets shall guide the decision.
  • Scope – What shall be included in the release.

Ad hoc/when needed meetings

Team planning

The captain calls the team for a planning meeting anytime needed. Usually this is done when the team starts to work with a new thing (fetched from “The Volcano”).

Kaizen meeting

The purpose is to secure that we improve the teams and the process a little step every day (continuous improvements). Before we had this meeting regularly (bi-weekly), but we sort of lost momentum. Now the meeting is called upon when needed (something in the team or process needs to be improved). We use a channel on Slack to bring up the topic with two possible outcomes:

  1. The topic is discussed and solved on the channel directly
  2. The topic is extensive and a meeting is needed (or some smaller topics are collected before a meeting is called).

The Agile Coach and the captains together with other persons with interest in the topic(s) perform the meeting. The outcome is documented on the Slack channel.


There you go, these are the meetings we conduct to implement feedback loops. We also have some other channels for feedback, but I save them for another blog post. What type of feedback loops does your organization have? Don’t hesitate to contact me if you have any questions!

All the best,
 Tomas from TheAgileist

The Circles – Products´ lifecycle visualization

Before the Summer I introduced the “Circle of Life” to my teams, a way to visualize the whole lifecycle for products. How did that go?

Background and introduction

The first (and most obvious) comment was that they didn’t understand and wanted me to explain more. This type of visualization is quite rare, I have not seen or heard about it anywhere else in the Agile community. Teams are used to work with boards (Scrum and Kanban) for their short-term work. This is a visualization that is much more long-term and therefore questioned. After that I have explained more, some saw the benefits and others didn’t (someone even thought it was a complete waste of whiteboard space…).

However, one person thought it was good but needed a representation of time, a timeline if you like. I remembered an old idea, the “Product radar” with circles. The circle closest to the middle represents “now” and circles further out from the middle represents “later”. I combined the two visualizations on top of each other and The Circles was born!


The Circles

The metaphor I was looking for are the tree rings seen when sawing off a tree trunk. They surely represents time! In the following paragraphs I will introduce the concepts and functionality of The Circles.

Post-its usage and colors

Try to use the same color on the post-its to group ”product families” together. Put up intended releases, with version number and intended release date, on smaller orange post-its on your products (I cut them to that size with a scissors).


We have a number of products in the example above going through different phases. Some products are ”young” and in the early phase of their lifecycle, while others are ”old” and phasing the end of their life. The way you work with them is really different depending on which phase in the lifecycle they are.

We have divided The Circles into three different phases:

  1. Build-up – Your product is brand new and you have started to build it up. You add feature by feature to make it compelling to your customers out there.
  2. Serving – Your product is so ready that you can start to make money on it, you have your first customer! You continue to add functionality to attract more customers to make even more money. You want your product to be in this phase as long as possible!
  3. Retirement / termination – For some reason it’s time to retire your product. You take it off the market, minimize the maintenance, and migrate over customers to other (new) product(s).

Movement and timespan

How does the products move within The Circles? We have set up the following rules:

1st Customer – When the product have the first customer, it moves into the ”serving”-phase.

End of Sales – When we stop selling the product, it moves into the ”retirement”-phase.

Products with releases that are planned in the ongoing quarter are placed in the “inner circle”. Things for the next quarter are placed in the “middle circle”. Product releases for the next half year are placed in the “outer circle”. This way we can visualize all product releases for a full running year! You can of course alter the timespan to suit your needs.  


This is the current version of The Circles we have visualized inside our “control room”. As you can see (with sharp eyes) we have also added team avatars (magnets) to high-light which team that is working with which product/release.  



No-one is questioning The Circles anymore! To discuss and update it is a natural and appreciated thing we do on our weekly planning & prioritization-meeting. Would you like to try The Circles? I would love to hear more about your implementation and don’t hesitate to contact me if you have any questions!

All the best,
 Tomas from TheAgileist

Essential Kanban Condensed

Six years have passed since the ”blue book” was released (the book about Kanban, written by David J Anderson in 2010). To meet up with the competition, Scrum has its own ”Scrum Guide” available for download, I assume that David and Andy Carmichael (the co-author) wanted to release a guide for Kanban as well. That is ”Essential Kanban Condensed”. The book has 100 pages and was released in 2016.



The book consists of 9 chapters starting with ”What is Kanban?” (a method for services that deliver knowledge work) to more advanced topics as ”Forecasting and Metrics”. Instead of going through the book chapter for chapter, I will give you the essentials condensed (pun intended) :).

Kanban Values

Kanban have nine values and they are: transparency, balance, collaboration, customer focus, flow, leadership, understanding, agreement & respect.

Kanban Agendas

There are three agendas:

  • The Sustainability Agenda
  • The Service Orientation Agenda
  • The Survivability Agenda.

The Foundational Principles of Kanban

There are six foundational principles of Kanban, divided into two groups.

Change Management Principles:

  1. Start with what you do now
  2. Agree to pursue improvement through evolutionary change
  3. Encourage acts of leadership at every level.

Service Delivery Principles:

  1. Understand and focus on your customers’ needs and expectations
  2. Manage the work; let people self-organize around it
  3. Evolve policies to improve customer and business outcomes.

The General Practices of Kanban

There are six practices:

  1. Visualize
  2. Limit work in progress
  3. Manage flow
  4. Make policies explicit
  5. Implement feedback loops
  6. Improve collaboratively, evolve experimentally.

Implement Feedback loops

To implement feedback loops seven cadences are suggested for a typical enterprise or multiple-service context:

  1. Strategy Review
  2. Operations Review
  3. Risk Review
  4. Service Delivery Review
  5. Replenishment Meeting
  6. The Kanban Meeting
  7. Delivery Planning Meeting.

Kanban Roles

Kanban is and remains to be the ”start with what you do now” method, however in later years two roles have emerged:

  • Service Request Manager
  • Service Delivery Manager.


You should definitely read ”Essential Kanban Condensed” if you want to get up to speed in what Kanban stands for and represents today (as of 2016). Do you want to read it right now even? Currently, it is being offered as a free eBook at this web site.

All the best,
 Tomas from TheAgileist

Control Room 2.0

I have previously written about the “Control room” we are using. That blog post became quite popular, so I thought I should do an update showing what we have in the room today (all in the name of kaizen – I hope you don’t forget to do your continuous improvements?).


Team Kanban boards

The yellow circles shows some of the Kanban boards for our teams (not all are visible in the picture). They are pretty standard, except for one that is mirrored! You can read the story about why right here.

Shooting Target

Next up is our “shooting target” shown in the red circle. Here you can read more about that. Currently we use the “shooting target” to focus the work at the end of a product release. We put the release date in the middle “to aim for”, and then everybody sees what has to be done.


In the middle of the room and in the blue circle we have our TV. This 4K TV shows status from our automated tests and bug tracking system. Here we can always see the current situation. Basically green means ”good” and normal, and everything else is deviances that we need to act upon. A desktop is connected to the TV to be able to show demos and support other discussions.

Circle of Life

In the grey circle our products lifecycle visualization is shown. Read more about it here. The “Circle of Life” started out very challenged (what is this really needed for?) but then the understanding of it, and thereby importance, has grown!

The work you do on your products differs a lot depending on which phases they are in. Now this is visualized. There might even be more changes to come, watch out for upcoming blog posts on that!

The Volcano

The Volcano shown in the green circle is our oldest visualization (apart from the team Kanban boards). It is the successor of The Arrow.  

Initially we had one swim lane per product within the volcano. That didn’t quite work out since a story (represented by a sticky) could in our case span several products. Now we have two swim lanes showing origin/ownership. Features are driven by product management, and foundation/platform are driven by the system architects group.


In total we have eight whiteboards in the room (not all of them are shown in the picture). Also present in the room is a sofa (for coziness), chairs and and a small table. Meetings in the ”control room” tends to be more informal than in a ordinary meeting room.

If I compare the “control room” now with the previous blog post (posted in May 2015), all visualizations have changed (apart from the Kanban boards)! That feels very comforting to know that we are able to add new stuff as we learn more, but also to fine-tune the existing things. What does your ”control room” look like?

All the best,
 Tomas from TheAgileist