More often than not, the development teams that I meet are really pretty good. In fact I can’t ever remember walking in to a business where the development resource isn’t up to the job. What I do find is that development teams that are struggling with the bad requirements that have been handed to them. Often, the reason that the planning sessions that they have are hard is because they are trying to do the business analysis, feasibility and definition & discovery work in the planning session as well as the technical planning – but they are not business focussed staff, so this is hard going for them, though by no means impossible.
So, the question on my mind is, “what can we do to make the developers’ lives as easy as possible?”
I have come to the conclusion that many of the challenges that development teams are having are a symptom of a problem. The problem must lie before the work gets to the development team – the problem must lie upstream with the business. Thinking further about this, it occurs to me that whilst the teams have been practising continuous improvement for years, business teams have not – and that’s the root cause of these issues.
Recently, I did a day of coaching with a team that wanted to move to Kanban because “planning wasn’t working”. I asked them to explain how the requirements got to them. The answer was quite simple: people throw requests for work over to them by means of electronic tool, then they do triage (read: panic a bit), then they do the item that looks easiest, then they release it. They constantly get
complaints about delivering ‘poor work’. Morale is low. The team is seen as shoddy at best.
So then I asked, if you could have any process you want, how would it look? So, with a bit of animated discussion and facilitation, they did this:
Which, for your benefit is actually this:
The interesting thing to note is that this only goes up to development. The team readily identified that they really needed more – and higher quality – business input.
The reality is that in many cases development is only a small part of the entire process. What we need to do is try to reduce the size of the processes around it. In mapping a process with another team recently, we were somewhat amused to see how much the development part is really sandwiched between business and pipeline – as demonstrated by this overlay of this end-to-end process map:
We need to remind ourselves of that old Lean principle – “see the whole”. Scrum is really good at helping us tweak and optimise development teams. Other Agile tools like XP and DSDM are also good at that too. Kanban, if used to improve the whole process, is an excellent tool to help us minimise waste by continually improving all parts of the development and delivery cycle, especially upstream.
So what should we be doing? I say we need to get the business thinking about many of the basics – vision, value drivers, MMFs, MVPs, feasibility of requirements and decision making – the list goes on. Development teams just need clarity and stability in the requirements they are asked to do. They also want to be listened to – for it is they alone who can tell you what it is you need to do to make their jobs easier.
