How to improve Flow Efficiency with Scrum – #Agile2014 Q&A


Thank you all of you who attended my #Agile2014 session: How to improve Flow Efficiency, Remove the Red bricks! In this, and upcoming posts (part 2) I will answer some of the questions I have received after the session.

Q1: I was hoping to better understand how to improve flow efficiency when the number of resources varies on our scrum process. For example, we have more developers than testers. We typically have a bottleneck in the test step. Not sure I got my answer.

This question is not necessarily a flow efficiency question. It may be more of a balance demand to capacity question. Nevertheless, let us explore the flow efficiency side first, as this was the main focus of the session. First, a short description of flow efficiency.

Continue reading


Agile2014 presentations

I had the great opportunity to present at two separate sessions at Agile2014 in Orlando.Here are the slides.

My first session was called “How to improve flow efficiency, remove the red bricks”

The video recording of this session is available on Agile Alliance Video Learning Center

In these posts I try to answer some questions I received as feedback for this session:

The second presentation that I co-presented with Erik Schön was called “The Mental Leaps at Ericsson 3G”.


Visual WIP Beta 2 is now out!

New and improved UI and better custom visualization support

Visual WIP the Kanban visualization tool for Team Foundation Server that makes your Work In Progress (WIP) visible!



This is the second Beta release of Visual WIP as the API is stabilizing. Changes may be made to what framework Visual WIP will be built on and further UI changes will probably be made as well.

What’s new

  • Pan and zoom is reset when loading settings
  • Added support for work item type and size specific design
  • The TfsWorkItemWorkProvider now adds support to open and edit work items.
  • Work items looks more like sticky notes
  • Auto loading of settings on the command line
  • Auto refresh interval is moved to settings file

Implementation details

  • WorkItemViewModel now inherits from DynamicObject to simplify work item field binding and error handling.
  • Simplified event bubbling implemented
  • Some out of memory problems has been addressed

Find out more and download at

Some screen shots

A basic ToDo – Doing – Done board with no WIP limits.


A simple process with WIP limits. The Analysis and Development columns has to sub columns, Doing and Done, that share the WIP limit.


A three swim lane process with WIP limits


The settings window for a Team Foundation Server single query column. Team Foundation Server columns are populated based on Team Queries. Define your own or use existing ones.


Team Foundation Server work item editor. Double clicking on a sticky note on the board will bring up the work item editor for making changes and see more details.


Standard work in software development–part 2

In part 1 of Standard work in software development I described what Standard work is and how it is the cornerstone of continuous improvement in Lean. In the post I will describe how a software development team I have been coaching have been using Standard work for a few months.


This is a team that are doing a technology conversion from VB6 to .Net. They are in the process of converting a large number of batch programs with very different properties and implementations. Some are small, some are large, some are quite easy and some are very hard.

The process and visualization

To do the work we have identified some common process states that are used more or less for every batch. We use a Kanban board to visualize how work goes through the process. Below is our board with the process states we currently use.


The process states are written on the stickies at the top of the board and are:

  1. Prio
  2. Business analysis
  3. Business analysis done
  4. Technical analysis/design, development and functional testing
  5. Ready for deployment to test
  6. Ready for System test
  7. System test
  8. Done

The Standard work cards

About one third from the bottom of the Kanban board above you can see some white A5 cards hanging from hocks. Below are is a detailed photo of two the A5 cards.


These cards are our Standard work cards and here is an example translated to English:

From Technical analysis/design, development and functional testing

  • Code checked in to source control
              Should follow defined coding standard and architecture
  • Code review done
  • Database project updated
              Changes documented
  • Test cases should have been executed
              All functional tests are green
              All automated tests are green
              For bugs
                   Run tests in DST together with the tester
  • Update requirements document with dependencies
  • Update Team Foundation Server
             Document all significant changes
             Set State/Reason to Awaiting deployment/Fixed
             Set Label
             Set tester as Assigned to
  • Notify CM and testers that work is now Ready for deployment to test

How we use the cards

When a team member is getting close to finishing the work in a process state they take one of the card for that process state off the board.

They go thru the checklist ticking the items off.

If there is something on the checklist that is not applicable, it will be stricken.

If there is something on the checklist that is not correct, it will be stricken and a correction will be written on the card.

If there is something missing on the checklist, it will be added by writing the new item on the card.

When the checklist cards are completed they will be collected by the team manager.

If changes are made on the cards the team manager has an opportunity to discuss the changes. If the checklist has to be updated the team manager will update the checklist and print the new version and replace the cards on the wall.

We are making changes to the checklists on a continuous basis. The changes are often initiated by turned in checklists, suggestions made by team members, discussions at the daily standup and at retrospectives.

The evolution

We evolved our Standard work cards from the more common Definition of Done used in Kanban and Scrum. Instead of printing the Definition of Done on the board it self we are printing our Standard work on paper and cut them up to the A5 size.

The benefit of doing this is that every team member can get a copy of the Standard work and have it on their desk as they do the work and checking off the items on the checklist. The other benefit is that we can collect all the changes and corrections made to the cards. These changes are triggers for potential process improvements.

Future improvements

Possible future improvements I’m considering for the Standard work cards are:

  • Adding start and stop time for tracking purposes.
  • Adding work item reference number for tracking purposes.
  • Adding the name of the person performing the Standard work
  • Adding Takt time for every process state. This would be the normal time interval that this process state should take. If the time spent in the process state is outside the specified time interval a root cause discussion will be triggered to discover possible process problems or improvements.


You can implement Standard work in something as variable as software development. It is all about how abstract or concrete you get in defining your Standard work. You start out abstract and make it more and more concrete as you learn how your process really works. The most important part is to change the Standard work as you change how you do the work.

Standard work should continuously change!

Standard work is the cornerstone of continuous process improvement, even in software development.

How I visualize my weight loss progress


A friend and I have set out to lose 15% of our body weight between 15th of July to the 1st of December. If we reach this target condition we will go to Italy next spring for some vacation.

Because the feedback loop between food intake and changes to the body weight are quite hard to detect without measurement’s I have decided to keep track of two measurement’s:

  1. My body weight – On a regular basis I will measure my weight using Wii Fit
  2. Kcal spent during training – When ever I train and I have my Polar bike computer I will track Kcal burned.

Just tracking the last measurement’s don’t really give you the information if you are on track or the motivation. So I decided visualize the data.

You can the see a picture of the visualization above that I ‘m using. Here is a description what it shows.

  • The horizontal axis – the time in days
  • The left vertical axis – body weight in kg
  • The right vertical axis – exercise kcal burned
  • The upper dashed line – the upper control limit for my weight. I should never be above this line Smile
  • The lower dashed line – the lower control limit for my weight. I will probably not be below this line but it would not hurt Smile
  • The green solid line – this is the target weight for every day
  • The hand drawn ink dots and connecting lines – these are my weight measurement’s
  • The hand drawn ink bars – these are the number of kcal burned exercising per day

The idea is give me visible and visual feedback if I lose weight at the target rate or not. If I’m not losing weight is it because I don’t train enough or do I eat to much.

Wish me luck!

NDepend your guide to Kaizen your codebase

From time to time I have used a tool called NDepend to help me analyze the codebase I have been working on. Most of the times in the past I have been working in codebases where I was part of the project from the beginning or near its inception. This time I get to work on a codebase that has been developed for a few years and most of the people who started the development is long gone.

CQL the Sensei that let you find your way

When working with code I always try to follow “The Boy Scout Rule” and leave the code in a better state than when I started. I usually do this by refactoring and cleaning up when I touch the code for specific reason like a change request or bug fix. But some times you gets some slack or have quality improvement time scheduled. When this happens how do you know what part to go work on first? You need someone to guide you.

This is the area where NDepend really shines. NDepend really is like a Sensei that shows you the way. There are the standard reports and you get things like:

  • Methods with the most lines of code
  • Methods with the highest cyclomatic complexity
  • Methods with the most parameters
  • Methods with too many local variables

And the list goes on and on. The amazing and greatest thing however is that theses reports are not static. The reports are built with CQL – Code Query Language. This is more or less like having a SQL database that you can query, but the database is your codebase! In my case I needed to modify the most lines of code query to exclude the “InitializeComponent” method to see what methods to look into.

Here is the CQL query I used and the result(method names renamed to protect the guilty Smile ):

 WHERE !(NameLike “InitializeComponent”)  
methods # lines of code (LOC)
MethodName1 424
MethodName2 401
MethodName3 383
MethodName4 340
MethodName5 303
MethodName6 301
MethodName7 292
MethodName8 265
MethodName9 262
MethodName10 257
Sum: 3 228
Average: 322.8
Minimum: 257
Maximum: 424
Standard deviation: 57.844
Variance: 3 345

Here is one of the standard queries that gives me the most complex methods.

// <Name>Methods too complex (CyclomaticComplexity)</Name>
  CyclomaticComplexity > 20 
  ORDER BY CyclomaticComplexity DESC
methods Cyclomatic Complexity (CC) Full Name
Method1 147 Assembly.Class.Method1
Method2 125 Assembly.Class.Method2
Method3 119 Assembly.Class.Method3
Method4 118 Assembly.Class.Method4
Method5 107 Assembly.Class.Method5
Method6 103 Assembly.Class.Method6
Method7 92 Assembly.Class.Method7
Method8 91 Assembly.Class.Method8
Method9 88 Assembly.Class.Method9
Method10 88 Assembly.Class.Method10
Sum: 1 078  
Average: 107.8  
Minimum: 88  
Maximum: 147  
Standard deviation: 18.443  
Variance: 340.16  

With the standard reports and CQL I have Sensei that guides me in my Kaizen work on the codebase.

Visualize your codebase

Queries and tables with the results are very useful but with NDepend you can go to the next level by visualizing you codebase.


This visualization shows the number of lines of code per method in all classes analyzed. It is very easy to spot the problem areas in the codebase.


This is another diagram that help me spot potential problem areas of the codebase.

NDepend is really a great tool to give you a feel for your codebase and where your focus areas for you code Kaizen should be. Give it a try.  

Two previous post related to this topic: