Intro

• What the goal of the organisation or workplace
• Empowerment (book reference)
• Tribal leadership (book reference)

Processes

• Frederick Taylor, Henri Fayol and Max Weber
• Taiichi Ohno and the Toyota Production System (book reference)
• Waste (blog post)
• Flow Efficiency, work of Niklas Modig (book reference) and slides from Hakan Forss (blog post). More about flow efficiency: how to measure it and when it is not so useful
• The agile way of working (blog post)
• Scrum (don’t do Scrum if possible. If you want to, here are some good posts about it.)
• Kanban by David Anderson (slides)
• Value stream mapping (blog post about how to do it)
• Staff liquidity by Chris Matts (blog post)
• Cynefin by Dave Snowden (blog post and further reading)
• Beyond Budgeting by Bjarte Bogsnes (metion in a blog post and further reading)

People

• Social sciences make a difference (slides)

I wasn’t talking much about programming because nowadays a programmer or software developer is expected to know and do testing, and keep in mind two things: quality and user satisfaction.

Here are the slides:

I also presented this older material from XP2013:

There are some more useful links below.

Related posts you may find also interesting:

• One Step Back In Testing
• How to Narrow Down What to Test
• Embedded Web Services For Testing Web Applications from JUnit
• The Purpose of Agile Software Development

I added information flow to the value stream mapping exercises because a long time ago we tried to improve the flow of a certain organisation but none of our efforts was successful. The reason was that the flow of customer requests and features covered only the 30% of the whole flow. The other 70% was communication, office politics, site politics, bug fixes etc. If you think about it, these work with information - even the features and bug fixes can be seen as some kind of information -, so it make sense to add them to the value stream map. With this approach we were able to see the whole, and finally it made sense why our efforts on feature flow improvement were unsuccessful: there was insufficient communication, therefore decisions were based on assumptions.

After we did the usual value stream mapping we added the information flow. It turned out that delivery management was out of the loop: no information went in and no information went out (no feedback loops). This means that they assumed certain important details just by looking at the package, and never gave feedback on it (practically, if there was an error they fixed it, but never pushed upstream). This was not visible on the usual value stream map but was immediately visible on an information stream map.

And this is something you can try. Do a usual value stream mapping and then add the information flow and see if the information flow follows the value (eg. features) flow. If not, or in a worst case there are information flow without feature flows you found a good place for improvements.

Related posts you may find also interesting:

• See the Whole Flow - An Exercise for Managers to Start a Transition
• My First Time With Cynefin
• Flow Efficiency
• Flow Efficiency Based Improvements Aren’t Always Useful

According to Dave Snowden, most of the knowledge workers are in the complex (connection between cause and effect is clear only in retrospect) and complicated (connection between cause and effect requires expert knowledge) domains, and in these domains the flow is not as visible and controllable as in the simple domain. Without having the proper - and not expert - view on the flow it is extremely difficult to improve the flow efficiency. This is a minor thing compared to the fact that in the complex and complicated domains we don’t even know for sure the connection between cause and effect (that’s why Snowden suggests to probe and analyze) and we add flow efficiency changes on top of that.

For example, we see that there is a buffer between two teams (buffer means waiting time). One way to improve flow efficiency is to merge the two teams or at least make them interact more frequently. This looks like a good idea, however there is no guarantee that it is going to work. What if the teams simply cannot communicate more or they cannot work together which slows them down and the waiting time increases?

Nevertheless, improving the flow efficiency is a good idea but knowing in which domain of the cynefin framework we are in is crucial. I had improved the flow efficiency of various teams in the past but in retrospect they were in the simple domain. I failed with my last team because we were in the complex domain and despite the huge effort we put into flow efficiency improvement nothing has changed. We should have moved to the complicated domain first where the connection between cause and effect are clearer and do the flow efficiency improvement as an experiment that we can analyse. My point is: don’t start with the flow efficiency improvement until you understand your flow and you have control over it (having a value stream map is a good start but knowing is different from understanding).

Related posts you may find also interesting:

• See the Whole Flow - An Exercise for Managers to Start a Transition
• My First Time With Cynefin
• Flow Efficiency
• Visualize Information Flow in Value Stream Mapping

I’m using an old idea from Chris Matts - a work item is put into a column that tells us when the it is supposed to be ready -, and the idea of organisational level Kanban boards. If this is week 13, team yellow is doing fine, whereas teams red and blue are in trouble.

Besides the nice overview the board points to the most problematic parts of the project regarding schedule risk: the oldest item (team red’s work item in week 11) and the team with the highest number of delayed work items (team blue).

The completeness attribute tells me something else: a work item with a 3/5 completeness (number of done items / number of planned items) won’t be finished this week if today is Friday, however a 2/3 might be finished. Moreover, team red has started to work on something that is supposed to be ready by week 15, but they haven’t finished their week 12 commitment. Team yellow might be delayed later: so far - in 3 weeks - they finished 6 of their work items (1/1+2/2 from done, 2/3 from week 13) and they committed to deliver 8 by week 14. That is very unlikely to happen.

These numbers are not accurate enough but they are a good basis of a discussion. Looking at the assigned team’s lead time and throughput can tell us more about the situation (more about this in a later post). Information about the completeness should automatically come from the assigned team’s board:

It is still early to say much more about this approach. I have two urgent things to solve. First, I cannot see dependencies between teams which would be important. Second, somehow I need to gather more data from teams and show it to them on the portfolio level, such as lead time, takt time and throughput, which would provide a good basis for predictions.

Related posts you may find also interesting:

• Kanban on Organisational Level
• See the Whole Flow - An Exercise for Managers to Start a Transition
• Visualize the Flow on the Highest Possible Level
• Visualize and Manage Team Dependency

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

class Foo
  attr_accessor :list

  def do_something
    @list = []
    action_1
    action_2
  end

  private
  def action1
    @list[2] = "a"
  end

  def action_2
    @list[1] = "b"
  end
end

I have this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

class Foo
  def do_something
    list = []
    action_1(list)
    action_2(list)
  end

  private
  #   self. means that this is a class level method (static in Java)
  def self.action_1(list)
    list[2] = "a"
  end

  def self.action_2(list)
    list[1] = "b"
  end
end

Similarly to my spike workflow I realised what I’m unintentionally doing after actually having done it. I switched to this method because of the Unix philosophy: “The Unix philosophy emphasizes building short, simple, clear, modular, and extendable code that can be easily maintained and repurposed by developers other than its creators.”

More precisely: I switched to this method because I was struggling with the Unix philosophy. When I’m writing code I don’t know what the shortest and simplest entity in my code is so I put everything into a class and when it is done, I may refactor it into smaller classes. This refactoring work is very hard when I have tightly coupled methods, but when I have methods that are not coupled by attributes (except dependency injection references) then it is easy. In the code above I can simply move action_1 and action_2 anywhere I want:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

class Foo

  # I have an attribute here: @actions

  def initialize(actions)
    @actions = actions
  end

  def do_something
    list = []
    @actions.action_1(list)
    @actions.action_2(list)
  end
end

# ----

class Actions
  def action_1(list)
    list[2] = "a"
  end

  def action_2(list)
    list[1] = "b"
  end
end

The action_1 and action_2 methods are no longer class level methods (no .self) because it is easier to code dependency injection with object level methods.

I do this even if my class has an actual “state”:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

class Foo
  attr_accessor :last_element
  attr_accessor :list

  def do_iterate
    last_element = action_1(@last_element, @list)
  end

  private
  def self.action_1(last_element, list)
    list[2] = "a"
    last_element = 2
    return last_element
  end

end

Anyway, this is the first time a large refactoring is no longer a difficult and long process. Furthermore, there are no more surprises in my methods: I know what is going to happen just by looking at the method definition.

Related posts you may find also interesting:

• The Refactoring only Constraint
• Cucumber JVM: More Scenarios
• Cucumber JVM: Mocking
• Path Reference in Gemfile
• Fast or Accurate Applications?

Each lane represents a certain severity using the visualization idea from Jeff Anderson. The severity (risk) comes from the correlation between time and impact: the later the team handles an issue the higher the impact is. Moreover, the cost or effort to “handle” a certain level is proportional to the area under the curve:

Level 1 category has an “infinite impact” and an unknown cost of delay. The problem of this level is that it is completely unpredictable. The costs can be extremely low or extremely high and this high uncertainty forces us to take care of it immediately. For example, the lead developer of the project cannot come to work any more. We can gamble and say that we’ll survive without him or we try to promote somebody else and train very-very fast. Level 1 doesn’t allow us to do proper risk management and mitigation, it forces us to do something. So it is better to take actions before a risk turns into level 1, but when it is on level 1, we have to take care of it immediately.

Level 2 category means that at the moment we know something is going to happen and we are aware of the consequences of a late action. For example, we know that the lead developer is leaving the company and we have 30 days to find a new lead. The more we wait with the promotion or the hire, the higher the cost of delay will be; it will be inversely proportional to the insufficient domain knowledge of the new lead developer. In other words: the more we wait the higher the risk reduced quality and delays in the project because of the domain knowledge of the new lead.

As you can see, if a level 2 item is not taken care of in time, it will turn into a level 1 item:

Level 3 is similar to level 2, but it has a free delay before turning into level 2:

Which means that there is a period of time when we can ignore the risk, but we cannot do it forever. Following our example, we know that the lead developer will leave the country later this year, so finding a replacement is not an immediate issue, but will be eventually.

Level 4 is a collection for nice to have issues or low risk level items. As I used to say: “this is the place where all the refactoring and code improvement tasks come to die”.

Like the other boards, this one also needs daily updates (the previously mentioned operations team did it twice a day). The risks (work items) have to be reviewed from top-right to bottom-left so that the team talks about the most “painful” risk first. The rest of the risks should be revisited and checked whether they have got closer to a level transformation or need to change level:

And finally, when a risk is sorted out - or a work item is done -, it gets into the done column. Similarly to other Kanban systems this approach provides measures such as lead time (time needed to mitigate a risk on a certain level) and throughput (number of risks mitigated) and needs to be continuously improved in order to be an effective system.

Related posts you may find also interesting:

• Be Aware of the Three Columns
• One Reason Why WIP limits Matter
• Wrong WIP Limits Will Kill Your Options

1
2
3

def is_prime?(number)
  (Math::Factorial.get(number-1)+1) % number == 0
end

And it was just fine for problem 3, where I had to find the prime factors of a certain number. There, the highest prime number I had to deal with was 6857 which is the 882nd prime number. Then I started to look for the 10001st prime, and my algorithm managed to find the 3000th after 2 hours.

I’ve observed before that my algorithm is not really fast, but why change something until it is not necessary, right? Wilson’s theorem is slow, because of the factorisation. Here is the factorial of 100 (100!):

1
2
3
4
5

>> (1..100).to_a.inject(:*)
=> -10384284350875615835879868794784780563948700682078952346418475
948982003462663882896989074486814358339575949818878047438776630877
0729164800000000000000000000
>>

It takes quite a long time and you can imagine how long it takes to calculate the factorial of 1000, or the factorial of the 10001st prime. So I needed something faster, and I found Fermat’s little theorem (setting a = 2):

1
2
3
4

def is_prime?(number)
   a = 2
   (a ** (number - 1) - 1) % number == 0
end

And it was faster, way faster (~86 seconds with IO operations, because I’m storing the primes in a file cache). But, Project Euler didn’t accept my solution. I thought I had screwed up the indexes and had submitted the 10000th prime instead of 10001st. So, I submitted primes in the range of +/-2, but none of them was good.

Since it would take ages to guess the right number, I took a different approach. I downloaded the first 1000 primes from the internet and compared them to my primes and there were differences. The first was 341. As it turned out, it is a pseudoprime. A pseudoprime looks like a prime according to Fermat’s little theorem, but actually it’s not: 11 * 31 = 341. The application became faster but less accurate. I didn’t go back to Wilson’s theorem, but changed the code quite a bit:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35

def is_prime?(number)
  a = 2
  if (a ** (number - 1) - 1) % number == 0
    if is_pseudoprime?(number)
      return false
    end
    return true
  end
  return  false
end

protected
def is_pseudoprime?(number)
  number_sqrt = Math.sqrt(number).to_i
  divisors = (1..number_sqrt).to_a.delete_if do |n|
    is_composite_of?(n, [2, 3, 5, 7, 11])
  end

  divisors.each do |n|
    # n > 1 makes sure that it works for actual primes in the recursion
    if number % n == 0 && n > 1
      return true
    end
  end
  return false
end

def is_composite_of?(n, base_primes)
  base_primes.each do |d|
    if (n % d == 0) && ((n / d) > 1)
      return true
    end
  end
  false
end

It is a bit slower, but more accurate (~89 seconds with IO). I think, it can be made faster (and cleaner), but for the moment I have enough primes and therefore I don’t need a different solution. Nevertheless, I learned a couple of things. First of all, playing safe and going for accuracy wasn’t a good choice because I didn’t improve and learn new things. Second, faster algorithms mea faster turnover times and faster development. And third, things like pseudoprimes finally make sense after 10 years I finished the University. Nevertheless, it was fun, solving Project Euler puzzles is fun, too. Give it a try, you’ll like it.

Related posts you may find also interesting:

• A Step by Step BDD Demonstration with Some Useful Insights
• We Need Realistic Coding Dojos
• The Empty Else Block
• Moving From Cucumber to Turnip
• Open Sourcing Emcalc, a Legacy Application

According to extremeprogramming.org a spike is a proof of concept: “Create spike solutions to figure out answers to tough technical or design problems”. Sounds great; it resonates well with my conclusions above (the next time it would be fantastic to find the science first and then the practice and not vise versa ;-)). And from now on - until I find something better - I’m going to follow this workflow in my projects:

If I know what I should do I’ll use TDD, if I don’t, I’ll write a spike. When I’m satisfied with the results, I write a test case (acceptance or unit). Next I delete the spike, and inject the new test case into the TDD cycle which will be red in that context (there is no matching code, remember: the spike is gone, so it should be red).

Here is an example. I have a nice algorithm that does certain things to numbers. I know the inputs and outputs of the algorithm, so it is TDD, no questions. However, an algorithm alone is worthless. Either I need an app, a command line interface, or an API. There are too many options and possibilities, so I’d make more progress by just writing spikes until I find the right solution. When I have it, I’ll write a test, delete the spike and let TDD do its magic.

As you can see the “spike turn” takes more time, and you should be prepared for that. If you aren’t prepared enough, you’ll do the same mistakes I did. I was writing spikes for days. From a certain point of view, there is no difference in writing spike code for a day and writing test code for a day. So my agreement with myself was that I have to sweat out at least one acceptance test in a day when I’m doing a spike.

After making progress with the new workflow in my project, I realised that I ended up with a nice test pyramid:

The “spike turn” produces one acceptance test case, but the TDD produces more, because the acceptance test case kind of covers the more likely scenario, whilst the unit tests cover all the possible scenarios and outcomes.

This workflow is very similar to a BDD workflow, but there are two important differences. First, BDD is a conversation tool between product and development. Second, the two parties (product and development) have an idea about how the application should behave. I’m using my main success scenario because I don’t have a clue how it should behave. Anyway, I’m happy with it, and if you give it a try, don’t forget to comment and share your experiences.

Related posts you may find also interesting:

• A Step by Step BDD Demonstration with Some Useful Insights
• Waste in Software Development
• There is a Difference Between Effective and Efficient

First, it is obvious but I have to mention that a very high CONWIP won’t cause very high throughput. There is an upper limitation of every system and if you go above this limit the overall lead time will increase and the throughput will decrease because the high CONWIP will allow aging work items in the system. Second, CONWIP has really nothing to do with the WIP that is applies to the columns (or phases) on a Kanban board, except that the CONWIP cannot be lower than the highest WIP. For example, if you have a WIP limit of 5 for testing and your CONWIP is 4, you’ll never have more than 4 items in testing, so why have a WIP of 5 and/or a CONWIP of 4? And third, the sum of WIPs won’t provide the ideal CONWIP. CONWIP is in connection with a desired throughput or capability.

Let’s say you have 5 developers, you have one ‘ongoing’ and one ‘review column’, and in order to move things forward you have a WIP limit of 2 for ‘review’ and 5 for ‘ongoing’. The sum of these WIPs is 7 but the actual capacity is 5. If you set the CONWIP to 6 or 7 you’ll have at least one developer who is working on multiple things. Moreover, the team slows down because ‘review’ will be emptied when ‘ongoing’ reaches its WIP limit. If you go below 5 you’ll have a developer who is idle. So the best CONWIP for this team under the given circumstances is 5. If you change the WIP limits to 4 and 1 ((for ‘ongoing’ and ‘review’ respectively) because you want your lead developer to do only review you can do it without changing the CONWIP. Unfortunately, it will be the same as the sum of WIPs but as I showed you before it is not a working use case.

As I mentioned in the first chapter the CONWIP serves as a controlling function in car manufacturing and it can be used in the same way in software development. The team which owns the board below can do more and more week by week (increase in throughput), but never enough to match the demand:

So, it decides to maximize the amount of work items it can have at the same time. With this approach the team can have some time and stabilize they are in. So the team takes control over the demand (input) and throughput (output) by using CONWIP.

Related posts you may find also interesting:

• The Lead Time Is The Time The Customer Must Wait to Get What She Asked For
• Flow Efficiency
• Using Takt Time to Find Problems Earlier
• Throughput
• One Reason Why WIP limits Matter
• Wrong WIP Limits Will Kill Your Options
• Aging Work Items

We started a new board - not a Kanban board - where we collected the already finished work items:

As you can see this board had three different columns. Each column represented a T-shirt size: ‘S’, ‘M’, and ‘L’. When we set up this board we put all the work items we had into these columns based on difficulty. Our smart questions were: “was this work item hard to do?” and “was it harder than these work items in this column?”. With this approach we ended up with three columns and since we weren’t able to find right titles for the them we named them T-shirt sizes. We calculated the lead time and spent time using distribution diagrams for each, and wrote them on the board (you can see them on the next picture). At the end of each week, we recalculated and put them on the board in order to use always the latest data for our predictions. When a work item was finished we put it into its proper column.

When we got a new work item, we gathered around the board, and we tried to estimate the right difficulty for the new work. Then we wrote ‘S’, ‘M’, or ‘L’ on the card and put it on our Kanban board. During the daily meeting our product owner checked the new work items on the board. When he thought that an item would take too long - its predicted spent time based on its size was too much - he asked us to cut the work item into pieces or he reduced the scope just to let something hit the market sooner. Our weekly inflow was around 7 work items, we spent around 5 minutes on finding the right place for the card, so our planning effort was a bit more than half an hour. Before that we have never finished our planning meeting in under two hours. The other big gain was that we could get rid of Scrum sprints and could work continuously: the planning meeting wasn’t an obstacle any more.

After several weeks, we observed that our predictions were not as good as before. There were ‘M’ sized items that were finished sooner, and vice versa. After a retrospective meeting we concluded that some of our data had expired. We were getting better at what we were doing, learned a lot about the product, and did several minor improvements in the meantime, therefore our old data was no longer useful. So we introduced lines on our board. Each line represented a week, and the latest was on the top (it took about 5 minutes to shift the whole board down each week, so it wasn’t a big effort). When we were doing the planning we considered only the last three weeks.

Of course we were wrong several times. The note on the right shows a transformation from ‘S’ -> ‘M’. After a work item was finished we took it from our Kanban board and move it to the other board. When a work item took more time than we had originally predicted, we tried to find the right place for it. The work item above was predicted as ‘S’ but actually was an ‘M’, so we put it into the ‘M’ column. With this technique we kept our board up to date. Of course, if it was an ‘S’ but we predicted an ‘M’ we did the same routine. This ‘S’ -> ‘M’ marker became very helpful later. There is an inner voice that tells us “next time you’ll do better”, but this marker kept us from listening to it. If the new work item was similar to a card with ‘S’ -> ‘M’, we wouldn’t mark it as ‘S’ because we knew that we had problems with predicting similar work items before, so it became an ‘M’. Most of time we were right, and I’m still very happy about it, because we were making decisions based on data and not gut feeling. Moreover, we were also looking for certain keywords. For example, if a work item had the word ‘wizard’ in its description it couldn’t get into the ‘S’ column, ever. Even if it was a text change on the UI. We tried several times to finish a ‘wizard’ related work within ‘S’ scope, and we never succeeded. So, the minimum an ‘wizard’ work item could get was an ‘M’. And our product owner was okay with this (I guess he valued predictability and quality over speed).

You may wonder about a couple of things. First, why were we tracking both the lead and spent time? We were kind of working in a TTM (time to market) fashion so it mattered how much time we spent on this project during a week or a month, so the spent time was important. On the other hand we needed the lead time to predict when a work item could be delivered. We weren’t doing continuous delivery - we did continuous deployment - so it was good to know when we can deploy.

Second, what has happened to the architectural decision part of a planning meeting? During a typical Scrum planning meeting, the teams kind of make architectural decisions as well. We didn’t stop doing this. We changed our process so that we did this planning for each new work item when it could get into the ‘analyse’ phase (before implementation). So in general the time we spent on planning didn’t change much. What changed is the time we spent on a regular planning meeting, and we reduced some mura waste: we planned when it was necessary, and therefore we had fewer re-planning sessions than before.

And third, the environment. When we started to do this kind of planning we knew the domain, knew each other and our technical knowledge was kind of the same. The size of the team changed over time, but this affected only the lead time because we rarely worked on work items in pairs.

I really enjoyed working like this. It was stressless: no hassle around deadlines and estimations, because everything we did was predicable most of the time. Of course, when we had some performance issues we had some stress, but not because of planning and execution of plans. The pictures above were taken after four weeks of usage but we used this technique for three months until the end of the project. I can only recommend this technique, and if you are interested in the #noEstimates movement, this is a good start. You don’t need a physical board either. You can have a bit wider Done column, or a different kind of Archive board. Here is an example from Leankit:

Related posts you may find also interesting:

• When Will It Be Done?
• The Lead Time Is The Time The Customer Must Wait to Get What She Asked For
• The Kanban Board is a Mirror
• Flow Efficiency
• Throughput

First, they make it really hard to know the real output of a team. If you remember the example from the throughput post after a while the team had so many aging items that they couldn’t take new work items. Of course, you can throw away aging work items, but these were important once and the team invested time and effort into bringing them to where they are now. Check out the chart on the right. It shows the demand, the throughput, and the actual number of aging items. Without considering aging items we can assume that last week the team’s throughput was 7 work items, which is true, but they could only finish 5 new work items. If the team decides to take more work items in this condition, their throughput of new work items won’t change. Every week they will have at least as many aging work items as the week before, their actual speed regarding new work is 5 work items per week, so a growth in demand will only increase the number of aging items. They simply cannot work faster because of them. The solution is counterintuitive. They have to decrease the demand in order to increase throughput. In other words they need to finish the aging work items, or at least lower their number. This will lower their throughput but this throughput won’t have an invisible component.

Second, if you use velocity or throughput for forecasting, the aging items can make it inaccurate. If you know that you can deliver ‘N’ items in ‘M’ days/weeks/months you can assume that the lead time of an item is shorter or equal to ‘M’. For example, if you deliver 10 features a month you can assume that you need maximum one month to deliver one feature. If you know about aging work items you know that this assumption may be wrong. If you have at least one aging item among the delivered features, you have one item whose lead time is actually longer than ‘M’. If you draw a distribution chart of lead times (on the right) you can see that there the majority of lead times are shorter than or equal to ‘M’, however there are actually several examples of longer lead times. In the basic forecasting post I mentioned why it is more safe to use the 85%-100% range of the lead time distribution (it is more likely that you’ll deliver before the longest lead time than at the average or median lead time), and if you work under the assumption above (lead time <= ‘M’) you may fail your commitment. So, if it is possible don’t use velocity or throughput for forecasting, use lead time distribution.

Let’s see a real example. This is a throughput diagram of the team:

And the board:

It seems that the team is improving: it outputs more and more work items. However they are in trouble now. Their current throughput is 7 work items a week, but they have 9 work items on their Kanban board. This means that they cannot take more work for at least two weeks until they get rid of all the aging items. The problem is that the team has a deadline in three weeks and their backlog has more than 10 cards.

Aging items aren’t unique, we all have them and will have in the future. The key is to find them and solve them one by one. An easy way to find them is to check how long the work items have been staying on the Kanban board. You are looking for those items that have been longer on the Kanban board than the length of the release cycle. Look for them at least once a week and talk to your team to figure out what to do with them.

Related posts you may find also interesting:

• Ageing Items on the Board
• The Hidden Inventory
• When Will It Be Done?
• Visualize the Flow on the Highest Possible Level
• Visualize and Manage Team Dependency
• Throughput

I mentioned that Chris was half right because if there is no limit on WIP the work might not get to the next phase. Imagine that the staff liquidity of the previously mentioned team for deployment is one (say it’s the member who has no idea about testing). If there is no limit on the testing phase the work can easily pile up there, which creates unnecessary pressure on the team member who does deployment, and the lead time will be unnecessarily long. So the right thing to do is to set the WIP limits based on the staff liquidity of the team and if you need more WIP in a phase, work on the staff liquidity instead. In real life it means that you train your people and help them grow. If you consider the team above, it is very risky to have only one team member who knows about deployment. Besides the risk of having a bottleneck (WIP limit 1 is a clear bottleneck) in your flow, this can negatively affect your lead time and throughput. Therefore, it is in your best interest to have a higher WIP limit (more options) in deployment, so either you help your current team members to learn more about deployment, or you hire someone who can do that.

These are equally good choices, and they are better than artificially increasing the WIP limit. Because if you think about it, if you have low staff liquidity then even if you have higher WIP in a particular column (more options - you can see how options and WIP are interchangeable) there won’t be more persons to do the job, so the work items may stay there idle and the lead time will not change: previously they were idle in the previous phase, now they are idle in this phase. Again, do not set the WIP limit. Use the characteristics of your system (e.g. the staff liquidity) to set them, and if you need higher or lower WIP, change your system accordingly, not your WIP.

Update: you can read Chris’ response here.

Related posts you may find also interesting:

• The Problems of the Capacity Utilization
• When Will It Be Done?
• The Lead Time Is The Time The Customer Must Wait to Get What She Asked For
• Does the WIP Limit Have to Match the Demand?
• Throughput
• One Reason Why WIP limits Matter

It takes 21 pulls to have one item done: you pull each work item into each phase one by one and when you run out of pulls you start with the next phase. You can see that in this situation that the actual WIP limit always equals to the number of work items in the system. However, if you have WIP limits the situation is different. With the WIP limit of one you need only 5 pulls but you may have idle work items and idle team members. This is not good either.

The solution is the harmony of the better capability utilisation and the short cycles. Better capability utilisation doesn’t mean that you want all the employees to provide 100% all the time (I suggest lower utilisation time), but you want the team members to work where they are the best or where they need to be. Unless, of course, there is a phase where your capability is low. This is where the shorter cycles kick in. In phases where the capability is low, the lead time will be high due to waiting or slow progress, so you may want to reconsider to make people learn new skills, and therefore be able to work in different phases. This will reduce the cycles because the capability will go up in the phase where it was low before, but it will decrease somewhere else because of the capability withdrawal.

In Kanban we use Chris Matts’ staff liquidity for capability utilitisation and lead time for checking the size of the cycles. Staff liquidity is actually a matrix which tells us the skill level of team members in the different phases. Here is an example:

As you can see the guy on the top is very good at testing (level 3), however he is not really good at development, but has an idea of how to do it (level 1). Moreover, you can see that there is another team member who is good at testing (level 2) which means that it is safe to say that the WIP limit on testing must be 2. If the limit is lower than 2, there is a chance that one person will be idle. If it is higher than 2, we have the no limit situation again: items won’t be pulled until the phase is full which actually means that there may be items that waiting more than they have to.

In Kanban we use lead time and flow efficiency to measure the cycles. Check out this lead time histogram:

And the flow efficiency:

It shows that the team can deliver a work item in 10 days (checkout this post why), but the flow efficiency (ratio between waiting and working) is 5% which is very low: the work items are in an idle state for 95% of their livecycle which is 9.5 days in this case. So, they should figure out in which phase they are waiting the most; probably where their capability is low. And we ended up at staff liquidity again. This is a nice cycle: lead time -> staff liquidity -> lead time -> staff liquidity etc, which is implemented with WIP limits and that’s why WIP limits are important: they are tools of controlling and fine tuning your system.

Related posts you may find also interesting:

• When Will It Be Done?
• The Lead Time Is The Time The Customer Must Wait to Get What She Asked For
• Does the WIP Limit Have to Match the Demand?
• The Problems of the Capacity Utilization
• Flow Efficiency

When I don’t know what to do, or I’m unsure about the next step, I ask myself the question “are we preventing something from happening, or are we fighting against something?” This question helps me orient myself and think about the next move. If the answer is “fighting” that is an immediate sign of doing something in the wrong way - not in an Agile way. A good example is the situation when we have to balance between bug fixes and features. This is a classic fighting situation because we are “fighting” with the bugs, but we don’t do anything in order to reduce their numbers. Or, we don’t know what the next step is, and we call for a planning meeting because that’s what the book suggests. This is not Agile according to me. We are going with the flow, but with the wrong one, and we don’t do anything to get out of this flow and make a difference in our lives. We are “fighting”.

You can guess where I’m going with this: Agile is the prevention of known problems from happening. This requires us to know about future problems, and be able to react in time. Going back to the police metaphor, the policemen really know about future problems but due to high volume in crime and their limited resources they cannot react in time. This is a reason why I think that Waterfall is not a good choice anymore: the model doesn’t allow us to react faster to known problems. In the beginning of my career I was working in Waterfall, and I enjoyed it. But when we were doing not so good it was always because of the reaction time. We never managed to react to situations in time.

Even if you can react in time, what if your knowledge of future problems is obsolete? Let’s say you are doing Scrum and you do iteration after iteration, but release to the customer after ten iterations. Are you Agile? I would say no. The iterations help you to react faster but your backlog can be obsolete, so you react to the wrong thing and that is not different from not reacting at all. Translating this to the police metaphor: the thieves found another area, while the police is still putting up warning signs in the old area.

My advice is to ask yourself or your team several times a week: “are we preventing crime or are we fighting crime”, and see the answers. If you do all the Agile practices and yet you do more “fighting” than “preventing”, you are not Agile.

A related post you may find also interesting:

• Parkinson’s Law of Triviality

I cannot really do anything with my issue of quantitative demand because that is not natural in software development unless you are paid by the number of delivered features. However, I can use the throughput to see how a team is doing by simply showing the demand (input) next to the throughput (output). The demand can come from outside and inside of the team. Outside is when the team gets the work from somebody else, inside is when the team plans the work themselves.

Let’s take as an example a team planning one week ahead. The chart on the right shows how they are performing week by week. As you can see they finish more and more work items (increase in throughput) week by week but they never manage to satisfy the demand that they are creating themselves by planning. This team needs a break and re-evaluate their planning process. It is clearly visible that they cannot deliver the amount they are planning, and most probably they have a huge internal backlog somewhere where the planned but never delivered work items are staying. What they should do is clean up this inventory and during the next planning session they should stop at the number of cards that equals to the throughput of the previous week. When their throughput exceeds above the demand several times in a row they can change this approach and take more work items, but as soon as the demand exceeds higher than the throughput they should check their planning process again.

Related posts you may find also interesting:

• The Hidden Inventory
• Liquidity for Kanban Systems, My First Look
• The Lead Time Is The Time The Customer Must Wait to Get What She Asked For
• Does the WIP Limit Have to Match the Demand?
• Flow Efficiency

https://github.com/ZsoltFabok/emcalc

You should know that I lost the source code so the repository contains the reverse engineered code (I used jad). I’ll keep the master branch untouched so that you start working on the code right away and changes will go to the work branch. There is another catch: the application is in Hungarian and Emily mentioned that it was not important to translate it, because this made the task even more exciting. Nevertheless, here is a quick overview of the interface:

And here is the way of opening new config files that fills out the parameters on the UI:

Example configuration files can be found in the data folder.

1
2
3
4
5
6
7
8

source "https://rubygems.org"
 # ...
    # bundler will take the specified version from the source repository:
   gem 'rake', '~> 0.9.2'

   # bundler takes this gem from the filesystem:
   gem 'mygem', :path => '/Users/home/.../gems/mygem'
 # ...

When the :path attribute is used, bundler goes to the filesystem and takes the gem from the specified location (without the :path attribute, it goes to the source - in this case https://rubygems.org). If the specified gem doesn’t have a proper .gemspec file, bundler won’t download its dependencies, and if you haven’t downloaded them before, your gem won’t work.

This a nice feature if you want to check how your gem works with your other gems that depend on it before commit.

Related posts you may find also interesting:

• Ruby on Rails: Migration Status
• Ruby on Rails: Sandboxed Console
• The Empty Else Block
• Moving From Cucumber to Turnip

Car manufacturers are producing the same kind of car over and over again, whereas software houses rarely do exactly the same software twice. Even on the smallest possible level there are only similar tasks, but not the same tasks. Moreover, in software development we don’t have to deliver 10 features in a week (unless the organisational bonus system is based on the number of delivered features), we have to deliver the one feature the customer needs/asked for. Therefore the takt time in its original form - throughput prediction - is useless in software development. However, this doesn’t mean that we cannot have it, but we need to adapt it. If the takt time - frequency of finishing tasks - drops or increases that is an indicator of mura (inconsistency, unevenness or unbalanced demand situations in the system) or poor planning. If the takt time is inconsistent or has pikes in your Kanban system that is an indication that something is going on that requires your attention.

When I’m talking about Kanban and Lean in workshops and talks, I always emphasise that we shouldn’t take practices from car manufacturing and apply them unchanged to software development. Using takt time in its original form would drive us towards increasing the number of completed features and that is very dangerous. I’m pretty sure that any organisation can increase the number of delivered features (throughput), but delivering the right features is a completely different story. However, finding process issues earlier is a good thing, and takt time is one of the things that can help do that.

Related posts you may find also interesting:

• Waste in Software Development
• The Lead Time Is The Time The Customer Must Wait to Get What She Asked For
• Does the WIP Limit Have to Match the Demand?
• Flow Efficiency

With the team I mentioned before, we used a physical Kanban board and redmine for issue (later work) tracking. At the end of each day we added the spent time to each work item we had been working on. When a work item was done, we’d get the data out of redmine, get the lead time from the post-it note which after a simple division gives us the flow efficiency of that item. Of course, you don’t have to use redmine, there are other options as well. You can write spent time on the post-it, or add it into the description of a work item in case you are using an electronic Kanban board. The goal is to know the time you’ve actually spent on a work item (I’m assuming that you know your lead time).

There was a time when we had a very low flow efficiency: it was around 5% and that was kind of scary and unacceptable. So we did a retrospective where it turned out that our work items were waiting unnecessarily for days in a particular column. After a long discussion, we changed our process and introduced a daily deployment to staging (pre-production) reducing the days to maximum one day and that helped us reduce the lead time from 9 days to 5 days. Flow efficiency actually helped us find a flaw in our process.

Flow efficiency is a tricky measure. First, you cannot determine the desired percentage in advance because it has a certain lag: you’ll only know the lead time and working time when you are done with the item. Second, software development is not car manufacturing. We don’t do the same work in the same environment all the time. We have very high uncertainty, options, changes, multitasking and humans in the process. I don’t want to talk about all these things except multitasking. We see it as a wrong thing, but if you think about it it’s that something we have that car manufacturers don’t. In their case if the flow efficiency is low it means that the factory doesn’t actually do anything. On the other hand, in our world it means that we are working on other things as well. We can actually wait and work on something else, maybe something more important. That is not possible in car manufacturing. Among other things that’s why David J. Anderson told us at various conferences that having a flow efficiency above 15% is normal, and above 40% is good.

And third, the context really matters. We had 5% which is below normal according to David, but it was fine for us. As far as I remember we were close to the end of that project and what we really needed (as it turned out later) is a lead time that is shorter than a working week (for planning purposes), and we achieved it. Our managers were happy with our results and we had other things to sort out, so we actually never checked flow efficiency again. We learned how to work with lead time instead. But this wouldn’t have happened without checking out the flow efficiency.

I hope that this post will help you to fine tune your Kanban system and get the flow efficiency from it. Don’t forget the points I mentioned earlier: collect your spent time, do not aim for a specific flow efficiency number, know the difference between car manufacturing and software development, and know your context. A couple of months ago David wrote a nice post about flow efficiency that can provide you more details. Happy tuning ;-)

Related posts you may find also interesting:

• When Local Optimization Won’t Make a Difference
• The Lead Time Is The Time The Customer Must Wait to Get What She Asked For
• The Kanban Board is a Mirror