Capacity Planning helps the organisation identify the constraints in the development system, and also identify teams that are not working on strategic goals.

From the organisations perspective, the most valuable work that the Credit and Payments teams could do is to help out the Windows and Mac Client teams, or perhaps Android or WinPhone Client. Any team or individual that moved to work on an unfamiliar area of the code would likely compare unfavourably to the teams/individuals already working on that code. A team from Credit might only be 30% effective compared to the existing Windows Client team.

Any HR performance / incentives scheme that compares or ranks individuals or teams against each other will discourage the Credit Team from working alongside the Windows Client team. They will find valid reasons for not making the move. The organisation will find it hard to encourage staff liquidity. They should have a policy that encourages people to work on the right work instead. A policy that encourages collaboration.

Lets put that in simple terms. Any HR performance / incentive scheme that compares or ranks individuals or teams against each other is in direct conflict with achieving the goals of the organisation.

Recently Microsoft famously gave up stack ranking. Sadly, other organisations have not seen the light and are happy for the HR department to wage a cold war against the organisation they claim to serve.

Stepping back from the strategic view of scaling agile, I thought I would share a very very practical first step.

GIVEN you have hundreds… thousands of developers (programmers and testers),

AND you have more than a few dozen product owners

WHEN your enterprise intends to scale agile

THEN you are going to need a tool to coordinate activity and decisions and summarise status.

1. Everyone in the enterprise needs to use the same tool for task management. Whether it is Jira, Rally, Version One, TFS, Lean Kit, Blah, or whatever tool, the entire enterprise needs to use the same instance of the same tool. Your Agile Scaling initiative will have emergent requirements. Its hard enough getting everyone to adopt a process change on a single tool. Trying to do that on multiple tools would be impossible.
2. The tool will need to support the entire scaled product owner process and the development process (whether it is Scrum, Kanban, XP, or whatever). There will need to be a minimum set of agreed processes that everyone will need to abide by so that the tool can be effectively to support scaling to the enterprise.
3. Some agalistas will protest saying that the team should pick their own tools. They can but they should ensure that the corporate tool is always up to date. Given that teams are unlikely to want to maintain two tools, they should probably only use the corporate standard tools (My personal preference is that user stories and above are managed in the tool and tasks within a sprint etc are managed on a physical board).
4. You will need to extract the data from the tool and put it into a reporting database so that you can isolate your enterprise reporting from the tool… so that you are not dependent on the tool for reporting, Also, this means you can more easily switch if you find you have selected the wrong tool.
5. All reporting needs to be automated. You never want to be in the situation where people are manually aggregating data in a spreadsheet to get an enterprise view. This will break completely when you go into your capacity planning meeting and people are making last minute updates even in the meeting.
6. You need to have a dedicated team who maintain the tool. You need to create the budget for this as part of the Agile Scaling initiative, and as an on-going activity. You cannot rely on a team maintaining the tool as a side project. The tool is a strategic asset that needs to be carefully controlled. Without proper management, your initiative can derailed by people adding the wrong fields or processes in the tool. The tool maintenance team need to work very closely with your Agile Coaches.
7. Your tool and supporting processes need to be Agile. Your support team need to be able to add fields/change process in quickly as emergent requirements arise. Any tool that needs modifications to be made by the vendor to add fields etc. IS NOT FIT FOR PURPOSE. If you need to create a manual process as a work around, you have broken your process.

Zsolt Fabok, a good friend of mine, has written a blog post responding to a talk I gave where I said “Explicit WIP Limits destroy options”. Before I respond, there are a couple of inaccuracies in the post that I want to call out.

1. In the video I said that “Explicit WIP limits destroy options”. I did not say that “WIP limits destroy options”. This is a subtle but significant difference. It is possible that Zsolt misheard what I say in the video. Instead of “Explicit WIP limits”, I advocate the use of WIP limiting policies.
2. Zsolt says “In this context it means that “the more liquid our staff” the more work items we can work on in parallel, which means that we have more options.” This is a misunderstanding of Staff Liquidity. Staff Liquidity is about the number of types of task that a team member can work on. It has nothing to do with working on things in parallel. This misunderstanding may be based on another misguided definition of staff liquidity that is based on the number of transactions in a system. (The number of transactions is a measure of system activity, not liquidity.)

Point 1 completely undermines the argument made in Zsolt post. Typical WIP limiting policies would be no more than one EPIC (unit of delivery of value) in progress, and no team member/pair should work on more than one task at a time (Blocked tasks should be marked as such). It is vital that everyone on the team knows the value of limiting WIP.

“Explicit WIP limited systems”, or Kanban systems as they are known, destroy options for the person managing risk in the system. The problem is that this coercive management technique (not necessarily the manager*) dictate the next task that a team member should take in certain circumstances. Given the WIP limit for the “waiting for test” queue is three and the queue currently has two items in it, when someone finishes a development task, then they know that the next task they should take is a testing task. Given that they do not like testing, when this happens, then they might do other stuff until someone else finishes, takes the testing task and then they will take the next development task.

The limits force behaviour. Without the limits, team members pick the tasks that they want to. Making this visible makes it easier to identify people who do not want to perform certain roles. This can lead to a discussion to see if they need further training or they disagree with WIP limits. This is a very important option for the person(s) managing the system, as it shows whether all the team members understand and support the approach.

To be clear, having more WIP reduces options. A smaller WIP increases options. Creating a system with lower WIP and no waste (i.e. where effective swarming takes place) is not a simple task.

Zsolt has been nominated for Kanban Community’s Brickell Quay Award. Please vote for him. 🙂

*Sometimes enthusiastic team members can force an approach on other passive members who are not aware of the consequences.

Last week, Skip Angel, one of the Agile Coaches I work with, attended a training course on SAFE. He gave a cracking one hour summary of the course to the coaching team at the client. Our conclusion was that we have a process that looks very similar to SAFE which gave us confidence that we are on the “right track”. The SAFE material is lovely, it is wonderful marketing material to sell scaled agile.

Our other conclusion was that we much prefer our approach based on Theory of Constraints to implementing SAFE. These are my (not my Client’s) opinion on Safe versus Theory of Constraints.

1. We started out with Theory of Constraints and ended up with a process similar to SAFE. In some places we are behind but in others we are ahead.
2. We have a deep organisational understanding why we have adopted each practice. This has taken months to achieve but we believe it will ensure more support and stability for the approach. Adopting SAFE would require a leap of faith.
3. Theory of Constraints has given us a clear roadmap of the significant issues that we face in the next year or two. We are now creating some real options to prepare.
4. Theory of Constraints helps us identify issues whereas SAFE tells us what to do. This means that Theory of Constraints adapts better to the context.
5. Rather than bland statements like the need for servant leaders, Theory of Constraints is helping us identify specific practices that management need to adapt to make our system successful.
6. Theory of Constraints is allowing us to evolve our process in a way that management have the necessary information to perform proper risk management of the process.
7. SAFE is a development centric framework. Using Theory of Constraints means that we have already partially incorporated Marketing, Finance are fully engaged and co-evolving practices to ensure fiscal controls are in place. We are currently planning the engagement with Human Resources.

Skip highlighted the most impressive part of SAFE is that the creator acknowledges gaps in the process and looks to the community to fill those gaps. It will be interesting to see whether that happens. I had a poke around SAFE to see how it addressed some of the trickier problems we have had to resolve. So far, it has nothing to say about them. The big gaps are around the “Portfolio” aspects of SAFE… or in other words the scaling bits.

It will be interesting to see how SAFE fills the gaps. Will it adopt a solid practitioner led approach like the XP and the ATDD communities, or will it annoint high priests who lack practical experience like some other marketing lead communities.

My advice to anyone thinking of scaling agile. Use SAFE as a map for the foothills but use Theory of Constraints as your compass. The maps soon runs out…  As a result, build your leadership skills in Theory of Constraints and keep SAFE in your pocket for when you get lost and need inspiration. Rather than give your executives a map to give them confidence, help them learn new skills to see the problems they need to solve. Your executives will surprise you by solving problems in ways you never considered. After all, they have different options to you… so help them see them.

A while back I suggested that using time value of money had little or no impact on the calculation of what I’m now (as of five minutes ago) calling “Software Investment Duration”.

To validate my assertion (sweet use of TDD language), I’ve calculated the impact of interest rates ( and hence time value of money ) on the calculation of “Software Investment Duration” for three scenarios. In each case, I’ve calculated the value using no interest rate ( time value ) adjustment, and with an interest rate of 20% (i.e. the US Peso). To simplify the blog post I’ve put the description of how the interest rate adjusted value is calculated in an appendix at the bottom of the post.

1. Constant Investment

In this scenario, there is a constant investment of 100 US Pesos per month for six months until the release.

The zero interest rate value is approx 3.5. The interest rate adjusted value is 3.45. Approx 1% difference.

1. Big Upfront Investment

In this scenario, there is a large upfront investment of 550 US Pesos, followed by an investment of 10 US Pesos per month for five months until the release.

The zero interest rate value is approx 5.75. The interest rate adjusted value is 5.74. Almost no difference.

1. Big last minute Investment

In this scenario, there are monthly investments of 10 US Pesos per month for five months until a big investment of 550 US Pesos just before the release.

The zero interest rate value is approx 1.25. The interest rate adjusted value is 1.24. Approx 1% difference.

So why does this matter?

The examples shows that even with fairly extreme values for interest rates (20%), the impact on the “Software Investment Duration” or SID is only about 1%. For lower values of interest rates, the impact is even less. So time value of money or interest rate adjustments only give us an extra 1% of accuracy in our calculation.

More accuracy is more good surely?

This level of accuracy is misleading. Whenever you calculate the cash flows going into the calculation, there are always going to be other factors that have a bigger impact than 1%. The effect of holidays, training and other non development tasks which may or may not be counted. The effects of bugs and or support that may or may not be counted. The effects of salary differentials between roles that may or may not be counted. ( To assign work to an individual rather than a team requires you create a time tracking system which is more than a 1% overhead ).

Worst of all, including an interest rate adjustment makes the concept much harder for people to comprehend and understand. “Everything should be as simple as possible but not simpler”.  See below.

Appendix – How the interest rate adjusted value is calculated.

To calculate the interest rate adjusted value, I calculated a simple discount factor as follows:

Discount Factor = exp ( -1 * interest rate * time in months / number of months in the year )

Although most readers of this blog will probably find this trivial, you should try discussing exponential functions with your business colleagues in finance, HR, product, UX design and marketing. In fact, anyone who did not studying for a science or engineering based degree. What you will find is that you will exclude a number of your colleagues from the business investment process for an extra 1% of accuracy.

This is a simple way to calculate a discount factor. To calculate it properly, you should first decide on which interest rate to use… Risk free? WACC? (Popular with the MBA crowd is the Weighted Average Cost of Capital).

Then you need some analytics to generate a curve using splines etc. A nasty tricky business.

On a few occasions over the past year I’ve heard the same urban myth about theory of constraints. I wonder whether anyone knows the origin of the story? I’ve started referring to it as the #NeoPrinciple…. They are the one.

Theory of Constraints tells us a number of steps we need to take in order to improve a system. Identify the constraint, exploit the constraint, subordinate everything to the constraint, elevate the constraint, rinse and repeat. Theory of constraints tells us that adding capacity anywhere in the system other than the constraint is a waste.

So what if you do not know about the theory of constraints. You put a bunch of effort into the system but are unaware that you are having little impact. If you cannot identify the constraint, your impact is based on luck rather than judgment.

This is the basis of the #NeoPrinciple urban myth. There is/was a company where the management did not understand the theory of constraints. Within that company was an individual/small group of individuals (I’ve heard both variants) that did understand the theory of constraints. Those with the knowledge of theory of constraints were the effective leaders of the company. It was they that controlled the future of the company, not the management team.

I think the purpose of this urban myth is to add some spice to an otherwise boring subject. The myth is the El Dorado of subjects for those hungry for power and influence. Its a great subject for the pub where alcohol clouded judgment attempts to work out whether it is possible.

Of course, the other aspect of the #NeoPrinciple is that it is a cautionary tale. There are some powerful memes stalking the halls of companies these days. Some memes need executive support. Others just need an infection point. TOC is one of the later. The moral of the story is for the managers of companies, learn about new ways of managing your company. Its better that you have the pleasant joy of discovering the work is already started than to discover that someone has disconnected your tiller from the rudder for good.

Me, I’d like to know if anyone knows whether its based on a true story. Be great to hear from anyone who knows about it.