Why should we care about cycle times?

What on earth do a development team care about Cycle times? After all what is it really for?

What do I care if it management want some bullshit metric to measure teams with - that doesn't make it valuable to us. We can't do our jobs better because of that.

OK so management can use cycle times for planning - but I don't need to know about that. I just want to get on with developing the product.

Granted, if we have short cycle times we can release the software more quickly then the company can make money on it sooner. But its not like the money wouldn't be made eventually.

Yeah - I suppose if we released regularly then my jerk of a boss would see what we have done and wouldn't scream at me for building the wrong shit.

Then my jerk boss makes us hack in the right solution at the end of the project for 3 weekends straight. If the code wasn't full of last minute hacks then my boss' precious cycle times wouldn't be so long!

Alright Alright I admit, by having shorter cycle times then I am probably going to have less things at any one time to work on, and my focus and attention can be given to one work item and prevent context switching.

FINE!! - short cycle times mean that the client will see our progress and have faith in what we do, but does that help me do my job? Trust between my team and the client is great but how does that let us build something better?

Alright - fair enough - I guess by having the clients trust I won't have to listen to them tell me how to do my job and have them constantly checking up on my every move.

Okay Okay okay - other than quicker releases, better return on investment, fast feedback, cleaner solutions, less context switching, gaining the trust of the client, what have the Romans ever done for us?

Business Driven Goals - Why > What > How

​Whenever I am presented with a problem I usually jump straight in and start to think about the solution. It is a natural inclination I have to create a link between my knowledge and understanding, to the solution. I think that most people behave instinctively in a similar manner.

In that regards, I think it is very natural that when presenting a team with a feature that is to be developed, the language used is often based around HOW to create the solution.

A recurring problem that the teams I have been on, and our customer faced was to make sure the requirements defined WHAT is needed, and not HOW it was to be built. Over time this approach has been cemented, which was a very positive step forward.

It has allowed the team the ability to collaborate and Identify how best we can create a solution.

More recently we have started to be much more focused on defining stories based around the business value. It allows all members of the team to be conscious of the exact value being added with the work being done and keeps the work on focus. 

However, the feature that is being delivered is specific in its definition, so any attempt to define the business value for a story is inferred by the team. With a small amount of luck, the business value of the story will match the business value of the goal that the feature is trying to satisfy. 

But ...the team has not been told WHY the feature is to be built.

Quite possibly, the feature selected is not the best way to satisfy the business goal. 

Just as there is cognitive bias attached to presenting HOW to build something ahead of WHAT to build, there is a cognitive bias in presenting specifically WHAT to build ahead of WHY there is a need to build something. In each of these scenarios we are narrowing the scope of ideas.

We have previously learned that:

• By presenting a team with the steps to build a solution, it blocks them from creating better steps to the same solution.

To follow that same train of thought:

• By presenting a team with a solution to a business goal, it blocks the wider collaboration in thinking of better solutions.

By understanding the business goals that we are trying to achieve we improve by:

• Allowing teams to focus their efforts solely towards achieving that goal, and not wasting time exceeding the goal.
• Eliminating scope creep on features
• Eliminating pet projects
• Letting teams see which actions bring the goal closer
• Letting the team learn from steps that do not bring the goal closer

Lets be real - If a client decides that a feature will be of business value, and is paying for the feature to be built, its simply not feasible to suggest that the business goal be shared and that other solutions be explored. 

However, what should always be feasible is that the team can find out the business goals behind each feature, and also find out how to measure when the goal is complete.

So when we are looking at our goals, lets start with WHY, then we can look at WHAT, and eventually move to HOW.