Author: Tomas Rybing

I live in Stockholm, Sweden and have been working in IT since 1996, starting as a consultant and programmer. From 2007 my focus has switched to team leading, project leading, product management and development methods. You can find my blog at theagileist.wordpress.com. You can also follow me on Twitter @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

Advertisements

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

Philosophy – One Step Ahead

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

One step ahead

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

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

  • One
  • Step
  • Ahead

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

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

”One

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

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

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

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

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

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

Reactive management

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

”One

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

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

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

Active management

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

”One

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

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

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

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

Summary

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

Top Ten List – Books

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

”Top

Top Ten List – Books

10. #Workout (Managing for Happiness)

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

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

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

8. Creativity, Inc.

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

7. Soft Skills

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

6. This is Lean

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

5. Moments of Truth

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

4. Agile Project Management with Kanban

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

Ok, we are approaching top three now…

3. The Innovators

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

2. Kanban in Action

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

And the winner is…

1. The Nature of Software Development

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

Summary

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

All the best,
 Tomas from TheAgileist