Priorities changed - Pitched

Most developers know that task switching is a great way to destroy productivity. In essence, it's the same when the company changes priorities at the last minute. All the preparation is wasted, all the coordination goes out the door and you're back at starting blocks. There exists a “last responsible moment”, after which changing the focus for development team will be wasteful. Of course, occasionally this change and waste is better then the repercussions of not, but in my experience this is rare. The idea of suddenly changing priorities is usually based on incomplete information. Anything that improves communication, so that everyone is fully in the know, is good.

Tip: Try to ensure the stakeholders who can change priorities are a) aware of the last responsible moment b) are in the right meetings c) are aware of the potential loss of productivity.

Introducing “Pitched”- Types of Waste in the development process.

There is a well known acronym for the types of waste that is used in LEAN thinking – TimWoods (http://www.isixsigma.com/dictionary/8-wastes-of-lean/ ).

I'd like to propose an alternative for software development – Pitched.

• Priorities changed
• Incomplete Requirements
• Team Imbalance
• Circumstances outside control
• Hoppers are incomplete
• Estimation is inherently problematic
• Dependencies cause a log jam

Knowing about these 7 items should give you enough of a heads up to spot them occurring before they damage your productivity. Hopefully they are self explanatory, but I will examine each one in detail in later posts.

Waste in Software Development

“A developer sits at his desk for 8 hours writing code, don’t tell me he wasted his time!”

Unfortunately I'm going to tell you that he probably did – or at least some of it! If you can't tell me what he actually delivered over the past sprint then some of your development team's precious time will be have been wasted! And worse... it will be because you told them to waste it!

Let me explain... You're very good at planning your sprint, but do you follow-up at the end of the sprint and measure what was delivered. If you do, how much of it was in the original plan compared to the reactive work you told him to do? How much of it contributes to the “Big Picture” or “RoadMap”?

We've all read the blogs that say, only allocate 60% of time to project work, allocate time for technical debt etc etc, but do you measure what ACTUALLY happened. Can you track back over the last few months and show much effort has been spent on TD, or on bugs, or where it really matters ON THE ROADMAP?

It's funny, but if you don't measure actual output, it is so easy to allow a 'just this once' or 'but this is an important customer' to distract you from the plan. Just by measuring, people seem to develop a backbone, and say no to these interruptions, putting them on the backlog where they belong!