Your Teams Work is Hiding


There is a good chance that the work your team is doing is hiding. If you find that you often ask for something to be done but the time it takes to be delivered does not meet your expectations, this may be the case.

It is very common for a member of the management team to ask someone to complete some task. The person tasked with the work may say he or she is really busy but will be able to perform the requested work nonetheless.


The problem is that work like this piles up in an invisible black hole, and no one really knows much about it.

Toyota Figured This Out for Us

In the late 1940s, Toyota studied how to improve its manufacturing process, and thus a process called Kanban was born. Kanban is a scheduling-based system that identifies a set of queues and moves work through the queues based on need. Kanban was originally developed for a manufacturing process and has been modified to support software.


The above diagram depicts the simplest Kanban board possible, which contains three columns or queues. Tasks are added to the ToDo column. When tasks are being worked on, they are pulled into the Doing column. When a task is completed, it is pulled into the Done column.

All tasks, which are often represented by cards, must be placed on the Kanban board, or they will not be worked on. The Kanban board is visible to everyone on the team. The cards in the ToDo column are prioritized based on the needs of the organization. The Doing column is constrained to only contain a predetermined number of cards—in this example, it is two. There is a short, fifteen-minute meeting each day, where the Kanban Board is reviewed by the team. From time to time, a longer planning meeting is scheduled.

The above paragraph contains some very powerful practices that can dramatically improve the delivery of work and the happiness of the team. Let’s spend more time discussing each of these points:

  • All Tasks Must Be on the Board – People requesting work quickly realize that it will not get done unless it is placed on the board, and thus a process is developed to facilitate this. This is typically some sort of planning meeting where new tasks are discussed and added to the board when the team agrees that it is appropriate to do so.
  • The Board is Visible – Transparency has an amazing effect. If the board is visible, people requesting new work see how much work is in progress, which may cause them to limit trivial task requests. The team doing the work also sees what is in progress. The tasks on the board often have the name of the person performing the work, and other team members are encouraged to help overloaded team members.
  • Pending Work is Prioritized – It is the responsibility of the team members who understand the business to keep pending tasks prioritized. Tasks are pulled from the top of the ToDo column into the Doing column. This prioritization is determined at a planning meeting. 
    This approach stops random requests of tasks that “have to be done right away” from occurring. Remember that all work is on the board, and the board is visible to everybody.
  • The Columns are Constrained – The columns that contain tasks where work is performed are constrained. In our example, the Doing column can only have two tasks in it. The only way another task can be added is if one is moved out, normally to the Done column. 
    A column’s constraints are devised based on the size of the team doing the work and experimentation.
  • Daily Standup Meeting – There is a daily, fifteen-minute stand-up meeting. Everyone on the team actually stands, and everyone makes a short statement about what they are doing and whether anything is blocking the completion of the task.
    It is common for longer planning meetings to be scheduled, where additions to the board and their prioritization are discussed.

Why Does This Work

In order for you to consider trying this approach, you need to already be experiencing considerable pain. Your customers and employees must be complaining enough for you to try something completely new.

This process mitigates the normal human nature of all busy, anxious people. Some of the points I make require a leap of faith and may seem counter intuitive. I provide links in the Learn More section of the article, but unless you are truly convinced, you are probably not ready for this approach.

If you decide to switch to this approach, be sure to have buy-in from senior management. It is also a good idea to hire a good Agile coach who can provide guidance to Agile processes like this.


Transparency makes all things visible. This causes the team to do the right thing without being directly asked. A good Agile coach provides guidance and asks probing questions when he or she notices issues.

The board is posted in a visible location—this could be a central white board or a big-screen monitor. It should be visible to everyone all the time so that everyone can see all the work. They can see what is being worked on and what is planned to be completed next.


The columns on the board that involve performing work are constrained. This is one of the most powerful aspects of Kanban, as it causes people to focus on work and get it completed.

“Stop Starting and Start Finishing”

Multitasking is evil. When someone works on more than two or three things at once, task-switching causes tremendous delays and inefficiency.

Identifying the constraint for a column is not an exact science. It is based on the number of people on the team performing the work. We do not want to “schedule” work at 100% utilization. We do not want to have the team perpetually busy: we want them delivering high-quality work, and we want them productive.

My advice is to start at a utilization percentage well under 100% and experiment with it, measuring how long it takes a task to go from ToDo to Done and not the utilization of individuals’ work.


Meetings are evil. Have as few meetings as possible in order to get the job done.

One meeting I recommend is a short, daily stand-up for the whole team. This should happen at the same time and place each day. Scrum uses this approach. Each person mentions what they are working on and any blocking issues they may have.

Other meetings are completely up to the team. Meetings may be required to add and prioritize tasks in the ToDo column or to address issues that arise at the stand-up. It is also useful to have a retrospective meeting from time to time where the team identifies two or three things they agree to improve on. Make these meetings optional and limit them to 30 minutes.

Getting Started

The columns on the Kanban Board are the workflow steps necessary to get tasks to a Done state. The first thing you need to do is define this workflow. The image below depicts a Kanban board with a simple workflow for delivering software.


The easiest way to do this is to meet with a representative portion of the team and draw the workflow on a white board. Once the workflow has been defined, draw the Kanban board on a whiteboard. Identify the constraints for the columns that require them.

Assemble the team and use post-it notes to identify all work the team is doing. Place the post-its in the appropriate Kanban columns.

For some teams, a Kanban board with post-its works fine. If this is not the case for your team, you will need to select a tool that better supports your Kanban board.

The final thing to do is to schedule the daily meetings and any planning meetings that are needed.
Future articles will discuss how to track progress, so stay tuned.

Learn More

For those of you who still need to be convinced of this approach, I have included links to some articles I have found that prove the points I mentioned.

  • Two good articles on the myth of 100% utilization can be found here and here.
  • Two good articles on the evils of multitasking are here and here.
  • You can read two good articles on making meetings optional here and here.
  • An article on Kanban is here and a good short video is here.

Kanban Software to Consider

All full-feature ALM tools support Kanban as well as Scrum. Most are free or almost free for small teams, so you can pilot something before committing any large sum of money.

A good article that compares Kanban tools is available here


Think Differently When Infrastructure is in the Cloud


If you are fortunate enough to be using cloud based resources, it is cost effective to configure Production Like Environments for load testing. The combination of Infrastructure as Code and the Pay as You Go price model in the cloud makes this possible.

Let’s assume that your cloud based production infrastructure is distributed world-wide and has a cost of $70,000 per month. It is not feasible to replicate this infrastructure in other environments full time at this cost.

The above example equates to about $100 per hour. We do not need load test environments full time. We only need them a fraction of that time. Since is it easy to create infrastructure, we can delete it when we do not need it, and thus we do not pay for it. If we run our load test each night for two hours, the cost of a load test on an environment like production is $200 per day.

So, there is really no reason these days to skimp on lower environments.

Simple Technique for Strong Passwords


This is a short and simple blog post that solves a modern challenge. It is important to have strong passwords for our many accounts. These passwords should include a mix of upper and lower case characters, numbers and special characters.

The password should not be any meaningful string either. Spouse names, cities or super hero's should not be used. for example 1r0nman! is not a good password.

It is also important to never record our passwords anywhere. Is someone sees our list, the know our password.

So how can we remember complex passwords that have no meaning without writing them down? I recently have started using a phrase as the basis for my passwords that I will not forget. I use the first letter of each word in the phrase for the password. For example:

I love to walk in the woods and look at the birds

This becomes:


This gives us a strong password that people are unlikely to guess. 



Agile and Dev Ops Links


Over time I have found a number of useful articles and videos on Agile Practices that I have included in this blog post.  I have also included some articles I have written that are posted on the Scrum Alliance site. I hope you find them useful.

From the Web

  • Product Ownership in a Nutshell - Excellent video on Product Ownership and agile delivery in general. We also learn a very useful way to track progress of software projects. This was produced by Henrik Kniberg who has a very creative way of visualizing processes.
  • Spotify Culture - Part 1 - This was also created by Henrik Kniberg. He works at Spotify and describes the culture there. Hendrick describes how large teams successfully work together to deliver complex software. Spotify Culture - Part 2 completes the story.

My Articles

  • What Does The Agile Manifesto Mean - This article covers the four main points of the Agile Manifesto and my view of how they relate to the real world.
  • The Agile Manifesto Principles - This article continues exploring the Agile Manifesto and covers the twelve principles.
  • Scrum is Simple but not Easy - When I was at the Global Scrum Gathering® New Orleans in 2014, they handed out t-shirts that had "Scrum is Simple but not Easy" printed on it. This article explores why we should stick to the tenants of Scrum and what happens when we diverge from them.

    My current assignment involves using Dev Ops to a large degree. I have learned that Dev Ops is a logical extension of Agile software delivery. Software has no value until it is in the hands of users and Dev Ops helps do this faster.

  • Devops Where do I Start Cheat Sheet - This is a very comprehensive set of links to articles and videos on Dev Ops. It is very Microsoft and Azure focused but will be useful to anyone attempting to understand where to start on this huge topic. I particularly liked the book The Phoenix Project. It is a fun and easy read similar to the One Minute Manager.
  • Lead an autonomous DevOps team at Scale: a true story - This presentation was done at the Microsoft Ignite 2016 conference. It describes how Microsoft was able to change from a delivery cycle of every two years to delivery into production every three weeks. 

Best of luck to all of you in your delivery of great software.