So the estimates weren't quite right, the team shape isn't quite right, or something just came up... and you are now left with a load of blocked tickets. Have you got a nice hopper of well defined work that you can quickly dip into that a) keeps the devs busy and b) contributes to the overall project direction? The alternative is scratching around to find work that will almost certainly not be defined well and may not even be necessary.
I use the term “sandfillers”, and have used a separate backlog of these smaller, generally isolated items. During the initial NPD process this backlog is useful for keeping the smaller items, the ones that are great to do at the end of a sprint. However, as a project goes through its life cycle these sandfillers can act as a great way of keeping other stakeholders involved. Once the product has been released the customer facing teams will make additional demands of the development team's time and need resource. Obviously, planning ahead for this would be wise, but lets face it you'll still be driven by feature releases and the need to broaden your MVP. The sandfillers can act as way of helping finding resource for the customer facing teams requests. Regularly prioritise this dedicated backlog with the customer facing teams. It works as a great way of ensuring they have some resource, whilst keeping them happy and involved in the project!
Circumstances outside of your control (or “Shit happens!”). Don't let this become the excuse why one of the other waste reasons occurred. It should become a red flag that alerts you to see if you can avoid the problem next time. Not knowing that John had his 3 week holiday of a lifetime booked in the middle of a key piece of development is not an excuse for missing a deadline, it should be the reason why the deadline was originally moved!
Take another example from my personal history... The government passes a law that affects your customers. Suddenly you need to drop what you are doing and focus on this new feature or functionality change. Whilst you may not have been certain the work would be needed until the law was passed, you could easily have prepared two plans, one for each circumstance! Not only would the business run more smoothly, but perhaps your customers would appreciate knowing they are in the safe hands of people who plan for this type of eventuality
There are two ways your team can have an imbalance, but both come from not understanding the “shape” of the work you need to do. Do you have estimates for your big picture or road map? (More about estimates in another post, but google Cone of Uncertainty for now). Do these estimates break down by work type and by level of difficulty? If so then you should be able to do a little bit of maths and see what an “average” piece of work looks like. Is it more weighted to Front End dev or is it more Back End? Is most of your work needing a genius or do you have mostly straight forward build work that juniors can perform. If your team shape differs from your average work shape then you'll either be inefficient (using racehorses instead of cart horses) or more than likely you'll always find yourself waiting for the right dev to be available. Do you constantly find yourself saying “that particular job will need <insert hassled developer name here>”? Time to look at the shape of your work and team!
It’s my suspicion that the typical person who enjoys writing code doesn't like agile and would prefer a waterfall / BUS approach. (They also tend to not like users or customers, which is where most problems start!) The reality of modern software development, especially for smaller SMEs building their own products, is that the comprehensive specification document is like rocking horse shit! Instead they receive “what could be cobbled together in the time allowed”. However, there are things you can do help yourself. Is your design and spec generation process defined? (And by defined I mean written down not “in John's head”). You'll probably end up with several versions, one for each type of problem, but once it’s written down, you can track whether a feature went through the process or not. No doubt the ones that just had to be rushed through and didn't follow the process will cause your dev team the most headaches, but I bet you'll also find they have the most bugs, or took much longer to develop than estimated or receive the worst user feedback. You’ll soon find enough evidence that everyone in the business will want everything to run through the full dev design process.
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.
