Author Archives: Jiten Vara

Is it ever okay to fully load a system?

Is there ever a time when it is okay to not limit your work in progress or ever a time when it is okay to fully load your system? Most people’s answer would be “probably not”. In most circumstances that would be the correct answer.

We see the consequences of loading our system when our teams take on too much work: our cycle time generally starts to increase and we struggle to get things finished.

We see a similar effect when there are too many cars on the motorway: things tend to grind to a halt and it takes forever to get to your destination.

Recently, I was fortunate enough to go to Japan during Hanami, or cherry blossom season. I went to Ueno park, one of the many parks in Tokyo to take in the beautiful views of the cherry blossom. However, it seemed like so had the rest of Tokyo. There were hordes of people in the park, many of whom were settling in for the famous cherry blossom parties. With the number of people in the park it was very slow getting around, with little space to sit and relax, and impossible to take a good picture of the blossom!

Ueno Park

The full to capacity Ueno Park


A couple of days later, I went to another park: the East Gardens of the Imperial Palace. These are the gardens mentioned in David Anderson’s Kanban book. Here they issue you with a token, or kanban, on entry (entry is free and you return the token on exit). Once the tokens run out they stop letting people in. Limiting entry this way meant that it was easier to enjoy the sight of the blossom. You were able to move about freely and there was plenty of space to relax. I was also able to take some decent shots!

Much less busy East Gardens of the Imperial Palace

The much less busy East Gardens of the Imperial Palace

Kanban used to limit the number of people in the East Gardens

Kanban used to limit the number of people in the East Gardens

It’s clear to see the benefits of Limiting WIP and not overloading your system, and we should aim to do it wherever is possible.

So why did the authorities not limit access to Ueno Park? Well, I reckon it was because it was still a whole lot of fun celebrating cherry blossom season with so many people, probably one of only a few situations where it is okay to fully load the ‘system’.

Don’t forget to add in the conversation

Story, Epic or even Saga, what is the difference? David Lowe’s post from last year gives a good description of each. However, in my opinion, there is not much difference. A story, epic or saga all narrate the type of user, the need of the user, and the value returned by fulfilling that need. The only real difference is the granularity at which it describes that need and resulting value. For example, stories may focus in on a particular feature whereas a saga may narrate the product as a whole. Whatever the size of the story, the thing that must be remembered is that it is just a placeholder for conversation. As Ron Jeffries says, it should be “an exchange of thoughts, opinions, and feelings” regarding the customer requirement.

User stories were first conceived in the early days of the Extreme Programming movement. Since then, much has been written about user stories and epics, how they are written, their benefits and how they form the product backlog. However, many people seem to have misunderstood their purpose.

Some Product Owners seem to have taken a very formulaic approach to the generation of items for the backlog. Almost like following a recipe in a cookbook, they will first write all of the epics required for the product, then once this is complete they will break all the epics down into smaller chunks or stories. Then they will obtain some arbitrary story points for each item and, voila, they have cooked up some delicious stories ready to be devoured by the team in their sprints.

This seems very similar to the approach used in traditional projects, where all the analysis and all the requirements generation is done up front, then, once estimates have been given against those requirements, the work is handed over to the development team for completion.

Apart from the fact that there is a big possibility that most of the things identified as stories will probably never be worked on and therefore a lot of time and effort would have been wasted in generating these, the recipe described above does not mention at any point any conversation about the epics or stories.

Without doubt, conversation is the most vital ingredient in a recipe for successfully identifying and understanding requirements and should be added in as early as possibly. And as Mike Cohn sums it up, “the most important part of a story is the conversations it creates”.

So, remember, don’t forget to add in the conversation.

Image credit: edududas

Are we slacking enough?

The team that I am currently working with is approaching the end of the sprint. After the last stand up, conversation turned to taking on more product backlog items before the sprint finishes, as the team felt like they had some spare time, or, slack. Most of the team felt strongly that we should be utilising as much of the team’s capacity as possible.

We discussed what the implications of taking more PBIs would be in terms of our team’s forecast for the sprint. We felt that the work planned at the beginning of the sprint was all in hand and would be comfortably finished, and that extra work from the backlog would definitely not cause a bottleneck somewhere within the team. So there was definitely capacity to do some more stuff!

The team continued to explore what things they could be doing during the time they considered as slack, things such as refactoring of code, technical debt or reviewing user interface designs for the upcoming sprint. All good ideas, but what other options were there? I suggested that maybe the time could be used to do something not directly related to the current product backlog, such as learning about a new technology that could help the team later on down the line or even use the time to work on something entirely different.


To be honest, I wasn’t surprised at the looks of shock from the team. It is a difficult corporate mindset to break, that every moment must be taken up with cranking out endless lines of code. How would the team ever explain that to their managers?

I’m not saying that we should spend all of our time playing Candy Crush, but it is no secret that our best ideas often come to us when our brain is not fixated on a particular problem, such as when we are in the shower. John Kounios, a professor in Applied and Cognitive Brain Sciences, says “Not having an explicit task is the main ingredient for random insights”. So, our slack time could be an opportunity for us to come up with a cool idea that we would not otherwise have come up with if we were always working at 100% capacity. Google’s well documented dedicated time for innovation lends proof to the theory that giving workers free time to think is often not a waste of time at all, and can often be valuable to the organisation, and therefore should be encouraged.

So how was the conversation after stand up concluded? The team agreed to take on some more backlog items.

Photo credit: Geralt

Project v Product

After reading James’ last post, Responding to Change – A Decorator’s Story, I began thinking a bit more in general about how people consider software development. In a lot of places where I have worked, software has always been delivered in projects.

These projects, even ones that have been called ‘Agile projects’, have usually solely been focussed on achieving the end goal. Even in the scenario where an earlier version of the software was already in production and could easily be enhanced incrementally, the project or traditional mindset has often meant that little consideration was given to delivering value early and often, which inevitably meant all the requirements were released at the end with a wonderful ‘big bang’. This is similar to a situation that I am currently facing.


No more big bangs

Projects, by their nature, are finite in their duration. Generally, at the start of a project a team is formed and is often then disbanded when the project is deemed to be complete, meaning that most of the knowledge behind the software is lost. The maintenance of the product is at that point handed over to an ‘application support’ team elsewhere in the organisation.

While in some scenarios it may be appropriate for software to be developed as part of a project, a better approach in many situations is to form teams that are dedicated to developing, maintaining and supporting the product for the duration of the product’s existence.

Due to the fact that there is no end date or deterministic plans to focus on, like there are for traditional projects, teams can focus on working on and releasing the highest priority, most valuable features to production as soon as they are ready. Regular releases not only mean earlier return on investment for the business, but customers also see that the software is evolving and keeps them interested in using the product. This fast feedback from customer usage also helps to shape the direction in which the product goes.

My challenge at the moment is to get teams thinking in terms of product and delivering early and often, not about projects where everything is delivered at the end.

I’ll keep you posted on how I get on.

Image by flaivoloka


On a side note, I managed to finish the book I was reading as mentioned in my post ‘My new year’s evolution‘. On to the next one.


I was recently involved in a release planning discussion where someone referred to an action that needed to be “handed over to the DevOps” team. I was slightly confused by what this meant. When I questioned this, I was told that what was meant by DevOps in this instance was a reference to the release management team.

Over the last few years the term DevOps seems to have become fashionable in software development circles. It’s not the first time I have heard something like this said and DevOps appears to actually mean a variety of things, including the people that deploy the software, the people that provide live application support, the people that look after the infrastructure or anything in-between.

It’s fair enough of course that a term can mean different things to different people, but where did DevOps originate from?

Partly, it originated from the realisation that software development was still siloed and that, while there was better collaboration between developers, testers and product owners within Dev teams, there were lots of other people involved in the delivery of software. However these teams were often on the periphery when any plans were put together to deliver software. Work was often thrown over the fence as described in the example above.

As we all know, this siloed approach can often lead to many dysfunctions such as a lack of accountability and trust.

Realising that this was an inefficient way to deliver software and given that the teams were essentially all working towards the same objective, a movement was born to break down these silos allowing dev teams and operations teams to work closer together  (hence the creation of the term DevOps). This greater collaboration, is helping to facilitate great software being delivered efficiently and quickly to the customer.

The movement is now not just about Dev teams and Ops teams working closer together, but in many instances they are now actually part of the same team, where team members share duties. Developers are now often performing sysadmin duties, and sysadmins are working directly with the code. The movement along with its associated practices, such as continuous deployment, has allowed for teams to be more autonomous and has given them the ability to not only design and develop software, but also to release and support it.

This clearly mirrors the Agile values and principles that we use to guide us and, no matter whether you call it DevOps or something else, anything that encourages greater collaboration and the quick delivery and support of awesome software is in my eyes is a good thing!

I’ve only just scratched the surface here about the DevOps movement, so it would be great to hear from you about your DevOps experiences and any thoughts on the movement.


Photo Source: Juliaf

My new year’s evolution

So we’ve come to the end of yet another ‘sprint’ known as a year. Each 365 day sprint seems to go by quicker each time.

Traditionally this is the time of year when we retrospect on how the last 12 months have gone and we come up with a ‘resolution’ to do better in some way in the next 12 months.

If I’m on honest, I can’t remember the last time I made a new year’s resolution. I think the main reason why it has been many years since I made a new year’s resolution is that I no doubt set unrealistic, non-specific goals, where I give myself the whole year to achieve, but then have no actual way of knowing whether I have achieved the goal or not, and therefore I’ve probably subconsciously given up before I’ve started.

This year I am going to set myself a new year’s evolution, but instead of reflecting on it in 12 months time, I’m going to evolve my resolution by actively reflecting on it every 4 weeks, and I’ll make small changes if I’m not quite achieving what I set out to do.

So my overall goal is to read more. But, as I’m sure you’ll agree, that’s a pretty open ended goal. So to be more specific, here is a user story for what I want to achieve.

As someone who loves software being released frequently

I want to read the remainder of the Continuous Delivery book, which was purchased about six months ago

So that I can get a more detailed understanding of the mechanics that support software being delivered continuously

I’ll aim to complete that story in the next four weeks, i.e. finish reading the book. I’ll review how I got on at the end of the four weeks.

Hopefully I don’t fall at the first hurdle… but if I do, I’ll change something so that I do better in the next four weeks. I’ll keep you posted on how it is going.

In the meantime, the team at team wish you a very happy new year. Best wishes to all of you that are also making evolutions, let us know how you get on.


Theory of Constraints

The definition of constraint in English:


A limitation or restriction


The systems that we work in often face limitations or restrictions. These can stop us efficiently reaching our goals.


What is the Theory of Constraints?

The Theory of Constraints, created by Eliyahu M. Goldratt and illustrated in his book The Goal, is a framework for identifying where constraints are in a system and then going through a process to improve the situation.

The Goal uses a manufacturing plant to illustrate the Theory of Constraints, however it can be applied to any process or system in order to eradicate limiting factors, and consequently improve the system’s throughput.

The five focussing steps

In short, the process for identifying and eliminating a constraint is known as ‘the five focussing steps’. These are as follows:

1. Identify the constraint.

The first step is to find the single point in our system that is most limiting the rate at which we complete our work in order to meet our goal.

Let’s take an example of a software development team: we may identify that manual testing is the point where work is backing up and at which work is slowest to flow through. This is our constraint.

2. Decide how to exploit the constraint.

The next step is to ensure that the stage in our process where the constraint is identified is working at maximum capacity.

Example: we ensure that the people involved in the testing activity are solely working on this.

3. Subordinate and synchronize everything else to the above decisions.

This step requires that all other stages in our process are aligned with the constraint. This means that all other stages are working in a way which reduces the load that is put on the constraint.

Example: ensure that we are using unit tests and that each work item is code reviewed by 2 other people before it goes to test.

4. Elevate the performance of the constraint.

This step is required if the constraint still exists even after we have gone through the previous three steps. We would keep working through this stage until the constraint stops being a constraint. This may involve financial investment to help alleviate the issue.

Example: we may look to try and bring the testing activity forward in the process and in the most extreme circumstance we may even look to recruit additional people to take part in the testing activity.

5. If in any of the above steps the constraint has shifted, go back to Step 1

Goldratt describes the Theory of Constraints and its five focussing steps as ‘A process of ongoing improvement’ (see The Goal: A Process of Ongoing Improvement). This means that once a constraint has been broken, we immediately move on to try and break the next constraint. Goldratt also says we should ‘not allow inertia to cause a system’s constraint.’

Cost of Delay

“Our highest priority is to satisfy the customer through early and continuous delivery of valuable software”

As we all know this is the first principle behind the Agile Manifesto.

But how do we understand the value of the things we are working on and delivering? And why would we want to deliver something at the earliest possible opportunity?

‘Cost of Delay’ can be one way of determining the value of the things that we are working on. However as well as helping us understand the value, it also helps us to understand how the value of something may diminish over time. It therefore shows us the value we are missing out on while we are waiting for that something to be delivered.

In its most basic terms, Cost of Delay is a way of demonstrating the impact of time on value.

In some organisations, a feature or product may go through a development life cycle that may include steps such as requirements analysis, proof of concept or prototype generation, user validation testing, architectural analysis, requirements refinement, development and testing, and various types of deployment procedures before finally making it live. Now each of these steps may be efficient in its own right, but the wait in between each step, along with any unforeseen delays means the end-to-end delivery of value may not be at its optimum and therefore less total value is delivered.

There are three basic inputs required to work out the cost of delay.

  • Value. What is the monetary value of the benefits per week
  • Urgency. An understanding of when the benefits will start to accrue or diminish
  • Information value. What is the cost of taking the wrong path? What would we be willing to pay in order to sufficiently reduce the risk of our decision.

Looking at the simple example below, if we assume that the feature in question will return £1m for each week that it is live and we assume that its value will not diminish over its life cycle, then if each activity in the delivery chain takes a week to do and complete, then in total there are 7 weeks of waiting or delay, meaning that the cost of delay for this feature is £7m.

Cost of Delay

As Don Reinersten puts it: “People are often surprised at how large the Cost of Delay number is”. []

Armed with Cost of Delay information we can make better trade offs and decisions on prioritisation, and better decisions on the steps we choose to take in order to deliver, ensuring that we are more focused on delivering at the earliest possible opportunity so that the maximum amount of value is returned to us.

The Cobra Effect

I have worked in lots of organisations where ‘management’ has tried to measure and monitor development teams with the aim of seeing how the teams are performing and then using that information to drive through improvements in performance.

This desire to measure and control things can often have some unintended consequences.

In the best-case scenario, teams will change their behaviours so that their performance improves for a short while as they know that they are being monitored or studied. This is known as the Hawthorne effect.

However, in the worst case and most likely scenario the Cobra effect, which is an example of a perverse incentive, may come into play. The Cobra effect is a term coined from the following anecdote:

So the “cobra effect” refers to a scheme in colonial India where the British governor, or whoever, the person in charge in Delhi, wanted to rid Delhi of cobras. Apparently in his opinion there were too many cobras in Delhi. So he had the bounty placed on cobras. And he expected this would solve the problem. But the population in Delhi, at least some of it, responded by farming cobras. And all of a sudden the administration was getting too many cobra skins. –

The incentive given by the governor, meant that the locals worked out a way to exploit this to their advantage. In other words they gamed the system.

For a simple example, take a Dev team whose velocity is being used by ‘management’ to monitor and control their performance: ‘Management’ perceiving a higher velocity equating to greater and better performance. Whilst in some instances this might be true, in others it could lead the Dev team to behave in the same way as the locals of colonial Delhi. Being provided with an incentive to look better in front of management by having a higher velocity, the Dev team during planning may inflate their estimates thus making it look like they are delivering more work than they actually are.

Teams often use information on velocity, lead time, and so forth as a part of their inspect and adapt processes; measuring performance is good if it used for the right reasons. However, if used for the wrong reasons, then it could have a detrimental effect by making people alter their behaviors in a negative way, as shown by the Cobra effect.

Hopefully, this scenario never happens as your ‘management’ is satisfied with your performance, as you are delivering software frequently and they are using ‘working software as the only measure of success’.

G.R.O.W as a Coach

In my last post, Coaching v Mentoring, I talked about how, in my opinion, a Coach is someone who helps people “identify and achieve their goals” and that a coach should do this through questioning rather than “the coach influencing or giving their own opinion on the subject”.

Surely, this is easier said than done? How is it possible to coach people in achieving their goals just by asking them questions?

A goal setting model developed in the corporate coaching sphere in the 80s called GROW might be able to help? GROW stands for Goal, Reality, Options, Will/Way Forward.

The Goal is what the coachee wants to achieve. It should be very clear what that goal is and therefore it should be clear when it has been achieved. “What is your desired outcome?” and “How will you know when you achieve it?” are some questions that could be asked during goal setting.

Reality is next. This is where the present reality is explored, and what barriers they may have overcome or are currently facing. Questions to ask could be “What have you done specifically so far to achieve your goal?” and “What is the biggest challenge that you’ll need to overcome?”.

Options explores beyond what the coachee has tried or thought about before, and tries to get them to brainstorm further ways that they can get towards their goal. Here you could ask “If you had all the time you needed, what would you do?” and “If you had a friend in the same situation, what advice would you give them?

Finally comes Will or Way Forward. This is where you get commitment from the coachee as to the action that they are going to take. For example “When specifically are you going to take action?” would get them to articulate a commitment, and “What might stop you?” would help them to consider building a contingency plan.

The focus on the goal and exploring the options with the coachee makes GROW an effective model for coaching both individuals and teams.


Have you had experience of using the GROW model or any other coaching model? It would be great to hear about your experiences if you have.