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.

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!
Advertisements

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

Agile Metrics in Action

Time flies! It’s been a while since I did some blogging, but now I’m back with a book review ”Agile Metrics in Action” from Manning Publications. The subtitle is ”How to measure and improve team performance”. This is an interesting topic I must say! If you do a change in your team, how do you know if it was for the better, or for the worse? You need to have some information, to be able to compare before, and after, the change. Voila, metrics comes in! The book is written by Christopher W. H. Davis and has 270 pages, it was released in July 2015.

”Agile

Content

The book consist of 10 chapters divided into three parts. The chapters are:

  1. Measuring agile performance
  2. Observing a live project
  3. Trends and data from project-tracking systems
  4. Trends and data from source control
  5. Trends and data from CI and deployment servers
  6. Data from your production systems
  7. Working with the data you’re collecting: the sum of the parts
  8. Measuring the technical quality of your software
  9. Publishing metrics
  10. Measuring your team against the agile principles

In software development we need measurement of what we produce, of course, but also measurement of the impact of the changes we make to improve delivery. Collect, measure, react & repeat – these are the steps in the feedback loop that we want to use.

”A method of measuring something, or the result obtained from this” – metrics defined by Google

In the software development lifecycle (SDLC) data to use as metrics can be obtained from the following sources:

  • Project tracking
  • Source control
  • Continuous integration
  • Deployment tools
  • Application monitoring

Development teams should be responsible for tracking themselves through metrics that are easy to obtain and communicate!

From your project tracking system (PTS), like JIRA or Rally, you can get the following:

  • Burn down chart
  • Velocity
  • Cumulative flow
  • Lead time
  • Bug counts

But why stop with only this? The book has a tip about tagging your tasks with as much data as possible. Tag for example all tasks that get automated tests written for them with:
#automated

With a clever query in your PTS, you can use this tag to create a new metric, representing the percentage of the tasks that are covered with automated tests. Store this metric over time, and you can see trends, to answer the question ”Are my automated test coverage going up or down?”. Another useful thing, is called recidivism, which is the measurement of tasks as they move backward in the predefined workflow. If a task moves from development to QA, fails validation, and moves back to development, this would increase the recidivism rate.

Source control is where your code is being written and reviewed and is a great source to complement the PTS data for better insight into how your team is operating. Continuous development starts with continuous integration (CI), the practise of continuously building and testing your code as multiple team members update it. Also use data from your deployment tools and application monitoring to combine everything into powerful metrics, that can tell the team and other stakeholders a lot about the current situation!

To calculate a custom metric you need two things:

  • Data to generate the metric from (as mentioned above)
  • A function to calculate the metric (can be in a range from very simple to super advanced. But remember you should be able to communicate your metric to other people!)

Recommendation

The book ”Agile Metrics in Action” does a good job in thoroughly explaining the topic about metrics. This is done with informative texts, together with a lot of pictures! If your are interested in metrics to help you improve your team, you should definitely check this book out!

All the best,
 Tomas from TheAgileist

Self-Organization & The Planning Board

Last summer I wrote about how I used some agile principles and practices to handle three problems we faced when living four families together in a small summer house. You can find that blog post here. When my vacation started, I spent some time thinking on improvements for this year’s stay (bringing together in total 19 persons). When everybody arrived I had prepared some new ”tools” for self-organization, with the Planning Board as the major new idea!

”The

These are the ”tools” we used

The Planning Board

The planning last year was compelled of a to-do list, and a schedule for the daily meals put up on the most central place in the house (i.e., the fridge :)). This set up worked well enough, but I wanted to improve it this year, and ended up with the Planning Board as shown in the picture above. It’s a matrix for each day in the week (that consisted of our stay in the summer house) with time slots (before lunch, lunch, afternoon, dinner and evening). To fit on the fridge the largest pager I could use was in A3 format, so I had to do my own stickies to be able to fit it all (cutting pieces of paper and using tape). As you may recall, ruler, scissors and tape are amongst my favorite agile tools! 🙂

”The

Above is a picture of the completed planning board, before any stickies were added. As you can see, I took the opportunity to make it colorful. Some additional information was also added to the board.

Below you can see the planning board, before the week started placed on the fridge (as said, the most central place in the house, where everybody passes several times a day).

”The

Initiatives

A sticky on the planning board represented an initiative. Maybe we could have used the word activity as well, but initiative felt better and more generic to fit our purpose. Each initiative had a driver (marked with ”D: <Name/s>”) on the sticky. The driver was the main responsible person for the initiative. Some initiatives regarded all persons, so they were marked with ”D: All”.

Some of the initiatives were given from previous years (like some shorter trips we like to do), so I added them before the week started to the planning board.

So could anyone just add an initiative? The answer here is both yes and no! Yes, because there were no rules for who could add a new initiative and no because some ”secret rules of self-organization” applied. I will explain them now. First, the driver needed sponsor(s) for the initiative. I.e. person/s that agreed and would ”join in”. Since most of the initiatives didn’t involve any major costs, finding sponsor(s) for the driver was pretty easy (”Shall we do this? Yes, that sounds like an good idea, let us add that to the planning board.”). A few initiatives involved cost, and they had to be funded, i.e. agreed upon with the owner of the summer house.

”The flyer”

To communicate about the initiative the driver in some cases used a flyer. Those didn’t fit on the fridge so we used a door for that. On the flyer the following information was stated:

  • Name of the initiative
  • Short description of the initiative
  • Name of the driver(s)
  • A motto
  • If participation was mandatory or not (the children put up a show every year, and attendance to that is always mandatory 🙂 )
  • Preferred time for the initiative (maybe if it was best suited as an evening activity)
  • An inspiring picture
  • Additional information.

The door

”The

Here you can see the door in the beginning of the week with five flyers added. The door also contained some feedback boards, that gave the opportunity for anyone that wanted, to give feedback (whether it was positive, negative or suggestions for improvements).

The planning meeting

After the dinner when all the participants had arrived, we held a planning meeting. At the meeting, this years new ”tools” were explained and we also did the first version of the planning (i.e., putting up all the stickies) on the planning board. Later some stickies changed back and forth during the week, mainly because some of them were weather sensitive. So the planning was like a guideline that we could follow, not rigid, and given the possibility to be flexible. This worked out really well during the week!

Self-Organization

With the ”tools” describe above the ecosystem was set enough to allow for self-organization! No-one was forced to do an initiative. Naturally the driver started and others would ”dig in”. This worked out really well during the week!

Hey, so you mean no problems at all occurred? Well yes, of course some problems occurred and needed to be sorted out. Mainly those discussions were handled by the four siblings (representing the four families). They came to an agreement in consensus, and in all cases I am aware of, everyone else aligned to that decision. Metaphorically, you can see this as the driver seeking sponsors to fund the initiative.

What happened?

Initiatives (a lot of them)

A lot of initiatives, with high commitment and value! It felt like more activity than previous year. New initiatives emerged during the week (I’m super happy with this, that showed that the ecosystem for self-organization really worked). Here is an example: One of the first evenings, an adult conducted a music quiz, following evenings many of the children held there own quizzes (with their music, almost impossible for the adults to guess :)).  Another example is building of a new porch for one of the smaller houses. This was an initiative that kept going ”in the background” during several days of the week (first to tear down the old porch, get rid of that, and then building the new).

Committed drivers (most of them)

In most cases, pin pointing a driver was really beneficial for the initiative, and the outcome was much better than leaving this with ”handled by whom it concern”. For one initiative I had higher hopes on the driver. In reflection maybe I should have taken a step back to get more involvement (I produced the flyer for this initiative, while not being the driver).

Alignment

Very little arguments or problems occurred during the week (less than previous year). All the people were aligned in terms of them knowing what was going on (a child knowing what day the Aqualand visit is planned, to an adult knowing who is responsible for making the dinner). The whole week was pretty much smooth sailing all the way!

Agile things we used

Open Space

If you are unfamiliar with Open Space, you can read more about it here. Basically I thought of the week like a long open space where initiatives (instead of topics) where put into time-slots.

Visualizations

The Planning board and the feedback boards are examples of visualizations.

Feedback door

Jurgen Appelo have come up with the idea of a feedback door. That inspired me to our door, as seen in the picture below (depicted after the week had ended).

”The

Planning meeting

Like the sprint planning meeting (in Scrum), we had a planning meeting with all participants to get understanding and alignment.

Self-Organization

I got some new inspiration regarding self-organization from reading the book ”Team of Teams”, which is may latest book review that you can find here.

Summary

Reading the feedback that was given about the week, it seems like a success (the only thing people complained about, was the weather – which wasn’t as good as it can be). I’m happy that everything I’ve set up worked out well, and that we improved from last year (kaizen – continuous improvements, remember?). It was also great to see the high commitment in the initiatives! Hopefully you now have some ”tools” to use when you want to bring structure to many people living together in a limited area during their vacation, or if you can use them in your daily work!

All the best,
 Tomas from TheAgileist

Team of Teams

Time has come for another book review. The Summer is, for me at least, time for reading and reflection. I’ve seen the book ”Team of Teams” been recommended within the agile community, and therefore it caught my interest. I really liked ”Turn the Ship Around” by L. David Marquet, retired from U.S. Navy. This book is written by General Stanley McChrystal, retired from U.S. Army. The subtitle is ”New Rules of Engagement for a Complex World”. It holds some 250 pages, and was released in November 2015.

”Team

Content

The book consist of 12 chapters divided into five parts. The chapters are:

  1. Sons of Proteus
  2. Clockwork
  3. From Complicated to Complex
  4. Doing the Right Thing
  5. From Command to Team
  6. Team of Teams
  7. Seeing the System
  8. Brains Out of the Footlocker
  9. Beating the Prisoner’s Dilemma
  10. Hands Off
  11. Leading Like a Gardener
  12. Symmetries

So what is this book about? I find this quote in the foreword: ”Management models based on planning and predicting instead of resilient adaptation to changing circumstances are no longer suited to today’s challenges”. The main story told in the book is the one about General McChrystal’s experiences from leading the Task Force in Iraq in their war against Al Qaeda. How they were badly beaten and had to change the whole organization from silos to to a network, to be able to succeed. The primary lesson that emerged, was the need to scale to adaptability and cohesiveness of small teams up to the enterprise level. General McChrystal calls this ”Eyes On – Hands Off” leadership. Meaning supervising of processes ensuring that silos or bureaucracy that dooms agility were avoided, rather than focus on making individual operational decisions.

Some new vocabulary, for me at least, from the military is used throughout the book. One example is ”limfac”, that stands for limiting factor (the one element in a situation that holds you back). I will start to use that!

For a very long time the focus of management have been on efficiency. Getting the most of a desired output (y), with the least available input (x). Now the focus needs to be on adaptability.

”Efficiency is doing the things right; effectiveness is doing the right thing.” – Peter Drucker

Sadly, in many cases still, the opposite holds true. Greatly summarized in the sentence: ”Great landing, wrong airport!”, that I’ve seen heavily shared within the agile community.

How we set up physical space really matters, and is reflected in how people work and behave. ”If you lock yourself in your office, I don’t think you can be a good executive” is a quote by Michael Bloomberg found in this book.

I chapter 9, The Prisoner’s Dilemma is introduced. From a management perspective it has interesting implications. It suggests that there are circumstances in which cooperation is better than competition. This seems obvious, but many managers assume that the healthy competitiveness between companies (that is the lifeblood of the free market), also shall be used within companies. People and departments within a company needs to see the whole to be able to cooperate fully, without having their own ”hidden agendas” (that can be the case in many companies today). The infamous problems with the car models Chevy Cobalt and Pontiac G5 (where GM had to recall 800,000 vehicles in 2014) is summarized with the following sentence: ”It was a perfect and tragic case study of the consequences of information silos and internal mistrust”.

Instead the following quote from Alan Mullally, CEO of Ford, leading their successful return in the market during recent years, shall be a guideline:

”Working together aways works. It always works. Everybody has to be on the team. They have to be interdependent with one another.”

Sandy Pentland, a MIT professor, states the two major determinants of idea flow; ”engagement” within a small group like a team or department, and ”exploration” – frequent contact with other units. In other words: a team of teams.

Finally, how should a leader lead? General McChrystal belief is (and I totally agree) ”leading like a gardener”, meaning:

  • Shaping the ecosystem (instead of ”moving pieces on the board”).
  • Delegate decisions to subordinates.
  • Creating and maintaining the teamwork conditions (”tending the garden”), a delicate balance of information and empowerment.
  • Drive the operating rhythm, with transparency and cross-functional cooperation.
  • Shape the culture.
  • Focus on clearly articulated priorities by explicitly and repeatedly talking about them.
  • Leading by example (it is impossible to separate words and actions, so they have to ”be the same”).

Recommendation

”The leader’s first responsibility is to the whole.” – General McChrystal

In summary the ”Team of Teams”-book tells very many stories, from the Army and the industry. Some of them appeals to me, other don’t. Overall the message told in this book really resonates with my own believes regarding teams, and how they should interact in a larger context! If you are interested in teamwork, and the war against Al Qaeda, you should buy this book.

All the best,
 Tomas from TheAgileist

The Blooming Garden

Yesterday, Agila Sverige (Agile Sweden) 2017 ended. As usual, I’m full of impressions and ideas that I want to try out! Maybe I will come back to this years’ conference in an upcoming blog post, but for now I want to share with you a metaphor that was used, and that I now have written about.

Introduction

To develop software products is like having your own garden. In the garden you have trees, bushes, flowers and maybe a little pond with fish. All of this needs to be looked after, and you need to remove the weeds to get your flowers to blossom.

”The

I got a little help from my daughter with this illustration 🙂

In software development it’s easy to constantly add new features and functions to your product. This will make your garden grow and grow. A real garden has boundaries, maybe there is a fence to the next door neighbour, but these doesn’t exist in software development. In theory there is no limit, in practise there is.  How do you keep up with this continuous expansion? Hire more ”gardeners” you might say (in the form of architects, developers, testers and so on). That works for a while, but at some point in time the garden will grow wild, and will be impossible to handle. So to add things, you also need to remove things. Maybe that little pond needs to be filled with mould so that new tulips can be planted? In my experience with software, removing something is a much harder decision than it is to add something new.

Technical debt

Another term for this is technical debt. Adding new functions comes with a debt in the form of other work that needs to be done in the product (we can see this symbolically as to ”remove the weeds”). If this debt is not repaid, it will keep on accumulating interest making it hard to implement changes later on (hence your garden will ”grow wild”). All products always need a certain degree of ”gardening”. The problem is that this fact tends to be forgotten when you constantly want to add new functions and features to your product.

In the garden you will plant the seeds, pour over water, keeping your fingers crossed for good weather and then wait and see if it will grow. According to the law of nature, not all seeds will germinate. It’s the same in software development, where you implement a new function and see if it gets adopted and used by your customers. Some of the things you do will be successful, while others will fail. Beforehand it’s very hard to guess what will be successful, but don’t be afraid of failure. Without trial&error there is no innovation. If you always ”play it safe” you will become predicable and your competitors will eat your lunch (or even worse, your company)!

A product is a complex system, you can compare it to an ecosystem in nature. When a new species enter the ecosystem the balance is disordered. What I want to say is that even if your new function in your product is great, adding it can lead to unwanted consequences in surrounding systems/products. Maybe a bottleneck in the communication now shows up between the systems. Of course this goes internally in a product as well (seeing the product as a full ecosystem). Adding a high throughput import adapter to your product may all of a sudden make your history searches painfully slow. Going back to the garden example, planting of some new bushes may attract snails that eat up all of your tulips.

Seasons in software development

In Sweden we have four distinct seasons; spring, summer, autumn and winter. During the winter everything is on low heat literally, since it’s freezing cold! When spring comes along everything is wakening up to life once again. During summer everything is warm and verdant. Autumn is colourful and time for harvest. Maybe your industry has some kind of ”seasons” or repetitive cycles as well? Instead of fighting against them, use them to your advantage! During ”winter” when everything is going in a slower pace, use that for planning and thinking ahead, whilst also taking care of your technical dept. Develop the new functions during ”spring” and release them for customer usage in the ”summer”. ”Autumn” is time for reflection to be able to start a new cycle with ”winter” again. See it as a big wheel that keeps on turning!

Summary

You can’t just keep on adding new things without taking care of the stuff that you already have. This is pretty clear to us in general life, but in software development it’s tricky since there are no physical boundaries. If possible, try to use seasonal variations in your industry to take care of your technical dept. 

All the best,
Tomas from TheAgileist

King of Kanban

”King

I’ve seen that a poll function have been added to Twitter for quite some time now, but I haven’t tried it out. Until recently, when I used it to ”scientifically” (well…) investigate how common Kanban is.

”King

You can always question a result of a poll. During the years I’ve written quite a lot about Kanban, and maybe therefore gained followers that are also into it. The ”sample size” (16 answers) may not be representative either. However, Kanban is used by more than half of the responders, so there must be a lot of usage and interest out there!

Before we start, I must admit that the title of this blog post is heavily inspired by the great documentary ”King of Kong”. It you haven’t seen it, and you are into retro-gaming, you must do!

Alright, do you want to become King of Kanban (or Queen for that matter)? Continue reading!

Introduction

So how do you learn Kanban profoundly? There is a bunch of ways, and how you want to go about it, is mostly your personal taste, and how you pick up knowledge in the best possible way. You can for example read blog posts (maybe you have your own list of Kanban front-figures that you follow?), see videos from speeches (many conferences are very kind and publish them online afterwards), or look at presentations at Slideshare (that many use to share their material). Maybe I can come back and guide you in this arena in a later blog post, but for now I would like to focus on books, reading good old fashioned books!

Some years ago I made a challenge to myself. Search on Amazon.com for ”Kanban” in the books department, sort by relevance, and buy & read all books on the first page! I was about to make it, but I think you can guess what happened. The first page changed… So I had to buy and read more books. Nothing wrong in that, but my challenge could not be fulfilled. Now I’ve put that aside, and instead here is the list of books from Amazon that I have read and reviewed on this blog (the search referenced below on Amazon.com were performed May 14, 2017). In the headlines below – First is actual position in the listing, the title of the book and within parentheses the year it was released. Ok, so here we go!

King of Kanban – Books

#1 – Kanban (2010)

This is still, very rightly, the most relevant Kanban book, written by ”the father of Kanban” David J. Andersson back in 2010. Many books on Kanban have been released after this, but ”the blue book” still stands as the one must to read, if you want to learn about Kanban. As I wrote in my review: ”Is this the book about Kanban? Yes, it is. David J. Anderson is the undisputed king in Kanbanland.”

#2 – Real-World Kanban: Do Less, Accomplish More with Lean Thinking (2015)

This books holds four case studies in of improving using Kanban. I would go for this as a fist book if you want to learn Kanban, but when you have gained knowledge and want some tips to take Kanban further this is a good source of information. From my review: ”It’s always good to hear real-life stories, this is the most effective way to learn I think.”

#3  – Personal Kanban: Mapping Work | Navigating Life (2011)

Jim Benson (one of the authors of this book) worked together with David J. Anderson for a period of time. While most of the Kanban community focus on teams and larger, this book applies Kanban to your personal work, using only two of Kanban’s core practices: Visualize your work & Limit your Work-in-Progress (WIP). As I put in in my review: ”This book gets really personal about Kanban! I’ll recommend it to all knowledge workers that wants to get priority, productivity and efficiency into their work and personal life.”

#5 – Kanban in Action (2014)

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

#6 – Agile Project Management with Kanban (Developer Best Practices) (2015)

If you are into agile project management and Kanban (as I do), you don’t need to look any further. This is the book you should read! I’ve picked up quite a few tips from this book. From my review: ”If you are into project management and Kanban this is a true gem! The length is perfect for an agile book, 160 pages.”

#7 – Learning Agile: Understanding Scrum, XP, Lean, and Kanban (2014)

This is a book I only picked up, because of the challenge. It’s quite cumbersome and now as ”agile” I want a book about Agile to be. As I state in the review: ”If your are new to Agile, and have a lot of time to read, I can recommend this book to get more knowledge about Scrum, XP, Lean and Kanban. If you only want to know about a specific method, or have short of time, there are other more suitable books around.”

#9 – Kanban from the Inside: Understand the Kanban Method, connect it to what you already know, introduce it with impact (2014)

This books takes another angle into Kanban (than the other books), it uses nine values to introduce it. The nine values are: Transparency, Balance, Collaboration, Customer focus, Flow, Leadership, Understanding, Agreement and Respect. Actually, I met the author, Mike Burrows, at a conference and got my copy signed 🙂 . I end the review with the following: ”If you’re into Kanban you should definitely buy this book! I wish I’ve had it (and especially the knowledge from part III) when I implemented my first Kanban system.”

#11 – Essential Kanban Condensed (2016)

This is (to my knowledge) the newest book about Kanban. If you are totally new to Kanban, you may want to use this as a first starting point. Actually I end my review with: ”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).”

#13 – Lean from the Trenches: Managing Large-Scale Projects with Kanban (2011)

I read this book long before I started blogging so therefore I don’t have any blog post review of it. In this book Henrik Kniberg shares his learnings from the PUST (”Polisens mobila Utrednings STöd”)-project at the Swedish national police authority. Cross functional teams, ”Daily cocktail party” (with team- and sync-meetings) and the project board are for example described in this book. This book is a case study of a very successful project, however six years have passed, and things may be done differently nowadays.

#14 – Kanban in 30 Days (2015)

As hinted by the title, the chapters in this book are divided by days in in a fictive month (30 days) to learn and start using Kanban. It’s a nice angle, but there is no problem in reading the book from cover to cover (it has 106 pages). From my review: ”All in all, I was positively surprised by this book! It covers what you need to know to get Kanban stated and running.”

#19 – Kanban and Scrum – making the most of both (Enterprise Software Development) (2010)

This is the second book from Henrik Kniberg. His first (and the one that really started my Agile journey back in 2008) was ”Scrum and XP from the trenches”, my review of the second edition of this book can be found here. This book simply compares Kanban and Scrum. I’ve read this one also, before I started blogging.

#21 – The Scrumban [R]Evolution: Getting the Most Out of Agile, Scrum, and Lean Kanban  (2015)

This book covers a lot of topics, it has 384 pages! However, from my review: ”This book has good structure, well written texts and a lot of illustrating figures. However, I think the overall purpose, to explain Scrumban, gets lost when describing all the surrounding agile practices. Keeping it simple is a virtue.”

#22 – The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win (2013)

Compared to all the other books in this list, this one really stands out. It is a novel and the story starts when Bill Palmer gets promoted and become VP IT Operations at the company Parts Unlimited. The company is really struggling, and a gigantic project named Phoenix is launched in order to save Parts Unlimited. It’s not really a book about Kanban per say, but it is in there, from may review: ”A novel and the story presented in this book is a very pleasant and nice way to to learn new things. If you want to now more about DevOps I can really recommend this book!”

Summary

If you like reading books you should now have some ideas on what to read to become King (or Queen) of Kanban! Take care, and see you next time!

All the best,
Tomas from TheAgileist