Agile

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.

”Doing

Content

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.

Recommendation

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

Tachometer to find perfect flow

How do you obtain a ”perfect flow” of work tasks passing through your software development team? That question have been in my head for quite some time. I can start by admitting that I don’t have a solid answer to that question (yet). However, I have instead thought of a way to visualise if you are having ”perfect flow” or not. How? I’m thinking of a tachometer!

”Tachometer”

Tachometer to find perfect flow

First of all, this is just an idea that popped into my head (this is actually the first encounter with the ”outside world”, so please bear with me). The idea is however to use a tachometer to indicate ”perfect flow” on a kanban board for a development team. Just like a tachometer is indicating if you are using the sweet-spot of your engine at any given moment.

My little example is a kanban board with three columns:

  • Design – Given the value 1
  • Development – Given the value 2
  • Test – Given the value 3

The values are used to calculate the position of the needle in the tachometer. I will now give you three examples that hopefully explains it all!

Example 1 – ”Too early”

”Tachometer

In this example three tasks are in the ”Design”-column, giving a ”tachometer value” of:

1 + 1 + 1 = 3

Thus indicating that we are ”too early”, and that the later steps in the flow (”Development” and ”Test”) are not utilised. The analogy with a car would be to ”gear up” meaning that the team needs to take the ongoing tasks to the later steps of the process.

Example 2 – ”Too late”

”Tachometer

In this example three tasks are in the ”Test”-column, giving a ”tachometer value” of:

3 + 3 + 3 = 9

Thus indicating that we are ”too late”, and that the team soon will run out of things to do. The similarities with a car would be to ”gear down” and for the team to put focus on feeding in new tasks to the kanban board.

Example 3 – ”Perfect flow”

”Tachometer

In this example the three tasks are evenly spread between the columns, giving a ”tachometer value” of:

1 + 2 + 3 = 6

Thus indicating that we have a ”perfect flow”, and that the steps in the process are utilised in the best possible way!

Summary

I understand that the mathematical formula behind this idea must be improved if this should become a reality. There are also cases where a tachometer like this will not be useful, for example if the team has just started. Maybe this can act as a challenge to manufacturers out there of digital kanban tools to add a tachometer in their product!

All the best,
Tomas from TheAgileist

Planning with multiple timelines

You should all know by now that I’m very fond of visualisations, to say the least. 🙂 Recently I’ve told you about how we did a ”retrospective with timeline”. That thought stayed in my mind when we needed to do some more detailed planning for multiple projects spanning multiple products. This blog post describes what we came up with. Here we go!

”Planning

The idea is simple, the timelines highest up on the whiteboard are projects (or larger initiatives, whatever you like to call them). The other bottom half (or whatever suits your needs) are products or components within a product (depending on the level of details you want to plan for). Usage:

  1. The project timelines shows major activities and milestones. I.e. ”hard facts” that we need to consider. For example a promised customer delivery.
  2. The product (or component) timelines shall show activities (work that needs to be done) and is used to find, and sort out, dependencies (”To deliver project X on time, we need to do activity 1 in product A, before we can do activity 2 in product B” and so on).
  3. Color coding. The activities needed in products (components) have the same color as the project that need them to create traceability.

Preparations

Before the actual planning meeting, you need to find a suitable whiteboard. The larger, the better. Preferably the largest one in the office! But think carefully, you may want to spend some time doing your plan, and therefore keep it up on the whiteboard for some time after the meeting to be able to make adjustments. At least I did, so I found one in a meeting room that is seldom used and started drawing.

Planning with multiple timelines

This is how the “planning with multiple timelines”-meeting was performed.

  1. Some 15-30 minutes before the meeting started, I went to the meeting room and draw the timelines for the projects that we needed to plan (with major activities and milestones). In our case two projects (larger initiatives) and two other activities that were more like dependent on the outcome of the planning. This acts as the starting point for the planning, i.e. things that we intend to deliver.
  2. The meeting started with me explaining the procedure (described above). Then the actual planning started. An example: ”We have promised to do this in that project, for that to work we need to add this in product A and that in B. Wait isn’t this needed in product C as well? Hmm, it is, maybe we should do that first then.” and so on. In this step you can spend as much time as you like, depending on the level of details you want to discuss, and the complexity in what needs to be done. The more dependencies you have the longer time to solve them out. Actually we had one first meeting to get an overview of everything, saving the details for later sessions.
  3. After the planning meeting I always take a picture of the whiteboard using my mobile phone for documentation and the possibility to communicate the plan outside of the room.
  4. As mentioned in a previous point you may want to revise your plan. Preferably you may want do it regularly as long as the projects are running, or you do it in the beginning in a couple of sessions to ”set out the course”.

Example

This is an example of a whiteboard with multiple timelines for planning.

”Planning

Summary

Ok, that was some thoughts and examples on how you can use multiple timelines for planning. If you don’t have several projects (or initiatives) running simultaneously, or you don’t have a complex flora of products you don’t need this. One possible enhancement I can think of is to use a digital whiteboard tool, to be able to keep the plan stored and also to distribute it easier. But for our needs a good old whiteboard suited us just fine. Don’t make things more complex than what they have to be, remember that!

If you don’t like this at all, it feels to much like “MS Project all over again” (however I don’t agree, the key is in the interaction between people to find out dependencies in front of the whiteboard) you can use my other idea for ”visual planning”.

All the best,
Tomas from TheAgileist

Famban

What is Famban? That is my own abbreviation of Family + Kanban! In other words, our attempt to visualise and keep track of all activities within our family. Can’t an ordinary kanban board solve that need? Of course, but we have made some additions that we find useful. It’s also quite fun to come up with a new name for something, I admit  🙂 .

”Famban

Famban in Favro

Setup

We use a collection in Favro with three boards:

  • Ongoing week (with one column for each day in the week – Monday to Sunday)
  • Next week (same setup as above)
  • Further ahead (with two columns; Coming – To keep track of things that are 2-4 weeks ahead & Later – to store stuff even further away).

Why have a bi-weekly schedule? It seems to fit our needs best. You could have a one week rolling schedule or four weeks instead, depending on your needs.  

We use color coding (called Tags in Favro) to visualise different types:

  • Recurring activities (Green) – Used for all recurring family activities, for example ice hockey school on Sundays for my son.
  • Activities (Blue) – To cover all “one off”-activities.
  • Travel (Red, not shown in picture above) – To keep track of an “activity” that spans more than one day.
  • Food (Purple, not shown in picture above) – We had an idea to keep recipes in here to also plan our dinners. To have 10-15 of our favourites to be able to spread them out during the two weeks and have some variation. We had not really succeeded in this though.

Operations

The operations of Famban is easy! Since Favro has a very good web interface for computers, together with apps for iOS and Android we can reach it everywhere all the time. This is the number one benefit of having a digital board like this!

It’s mainly me that maintains the Famban board. Every time an activity comes up, it’s added to one of the boards (ongoing week, next or further ahead).

Once a week, usually on Sunday, the next week is discussed and planned in more detail. Basically I then make “next week” the “current week” by switching places on the two boards (a simple drag and drop operation in Favro). I also change the week numbering (week 47, week 48 etc.). A trick here is to have double of all recurring activities, so you don’t need to copy them between the weeks.

Famban on fridge

”Famban

Our first attempt of Famban, was to put it up on the fridge. That is the most “central spot” in our home, here it’s seen multiple times per day by all family members. I made a physical version of the Famban board using several papers that I taped together. One problem was that it couldn’t be wider than the door of the fridge, and at the same time have the needed seven columns (one for each day in the week) and to be able to fit standard size stickies.  Therefore the “To-do” and “Done” sections were placed “below” the board.

This incarnation of Famban worked well at home, and we had daily morning meetings in front of it. The problem came when not at home, not being able to see it. Often the question came up during the day while at work, my wife called me and asked “Do we have something on Tuesday evening, or can I make arrangements with my friend X?”. That question was not possible to answer, it had to be handled later when at home again, that was inflexible so after a while this Famban board was not used.

Improvements

Here are some improvements that I have thought of, but not yet implemented:

  • When the kids get older and probably get even more recurring activities an improvement would be to add swim-lanes, one for each family member. That is supported in Favro.
  • To get the food planning up and running, adding nice pictures to the recipes would probably help!
  • We have lost the visibility by having the Famban put up on the fridge. That could be fixed by mounting a tablet device on the fridge, showing the Famban board 🙂

Summary

Famban is visualisation and family planning combined! I hope you liked this blog post, and that it inspires you to try something similar! As always, reach out to me if you have something to share!

All the best,
 Tomas from TheAgileist

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.

”Whiteboard”

Preparations

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.

”Drawing”

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.

Summary

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

”Monthly

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.

”Visitors

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.

Summary

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.

”Value

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

Content

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.

Recommendation

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