Deliver your software, don't just write it.


Development teams have a nasty habit of writing too much code and putting aside testing and code review.

The Anti Pattern

A common agile anti pattern I see is tasks piling up on the right hand side of boards. These tasks are waiting on another developer or team member to take some action. They may, for example, need to be subject to a code review or testing before being deployed or merged into the master/delivery branch.

When I look at the disposition of the developers both myself and those that I have worked with I am not surprised at this behaviour. We as a collective group love to build things, the joy of breaking down a problem, fixing a bug or seeing what's in our heads come to life on the screen is amazing. Contrast that with the feeling of digging through code developed by someone else. Potentially telling that developer that what they've done needs to be tweaked, that you've found a bug or that you disagree with the approach that they've taken. This at least for me is something that I know I find tedious and at times uncomfortable. I'm not proud to admit that sometimes it's something I avoid. It's all too easy to find reasons to focus on doing what we love rather than something that we find unpleasant. 

What does it look like?

The symptoms of this would likely be that your team is carrying a lot of unfinished work over between sprints. Your may still be delivering everything by the end of the sprint. There's a good chance that you're not but you could be. In that case your burn down might look like the "jumping off a cliff" burn down.


But what does it matter? Why should you care? the team is getting the work done. 

This pattern pushes up the cycle time and lowers the available time to correct any issues that are found with in the code. It is obvious that the team believes that there might be issues with the code. Otherwise the steps wouldn't exist or would be rubber stamp pass through that wouldn't hold up the process. I see several issues emerging from this pattern.

The first issue with this pattern is that the team are limiting the amount of time they have to assess, test and fix what has been done. As the team rushes to get these items complete before the end of their sprint they are going to have to spend less time testing and assessing the code for quality issue.

Second for any issues that the team does find during their review and testing process. The team has 3 choices,
  • Ignore the issues; pushing code that is either broken or accruing tech debt into production,
  • Quickly fix the issues; likely accruing more tech debt,
  • Carry the tasks into the next sprint. 

The third issue is that  the fact that these tasks now pushed well out of the developers mind slows down delivery even further. When confronted with an issue in code that was written a week ago or more, with multiple tasks and context changes in between, developers take time to get back into the head space. Cycle time matters, the smaller it is the faster the team can move and actually completing tasks is a core component of short cycle times.

What can you do about it?

The good news is that fixing this problem is easy to put into a sound bite. 

"Stop starting and start finishing."
"Make delivery more important than developing."
"If it's not done, it's not done."

The bad news is that sound bites are a quick way to sum up culture change which is a slow process. The first steps to culture change are small, in this case it starts at stand up.

Instead of asking the Three Questions, Walking the Wall or just giving a status up date focus on those cards that are out of development but not yet done. Find someone to prioritise those cards over what ever they're doing now.  At this point there is no breaking the flow state or anything else, you're at stand up, it's the start of a new day, it's already broken.

The end goal is to build the practice of looking for work from right to left. Encourage your team to think:
  1. Is there something I can deploy?
  2. No? Is there something I can review or test? 
  3. No? Is there something that I can help another developer with?
  4. No? OK now I will look at the backlog/to do column for something to pick up. 
When this is the standard practice of your team they'll be more agile and deliver faster with higher quality.

Comments

Popular posts from this blog

Solving `Empty reply from server` in DotNet Core

Testing functions that use local storage with Jest

Can't resolve DNS Aws