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.
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.
