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

Post a Comment

Popular posts from this blog

Testing functions that use local storage with Jest

Testing functions that use the browsers local storage API seems easy when you know how. Here's a quick run down on how to mock it out with Jest if, like me, you're not familiar with how to test it. In the end it's very little code. Consider the following TypeScript code. import { get, save, key } from "./storage"; describe(save, () => { let setItem: jest.Mock; beforeEach(() => { setItem = jest.fn(); Storage.prototype.setItem = setItem; }); it("should call set item with predefined key and json object", () => { const valueToStore = { value: "toStore" }; save(valueToStore); expect(setItem).toHaveBeenCalledWith(key, JSON.stringify(valueToStore)); }); }); The key lines are in the beforeEach call where the setItem function of the Storage prototype is assigned to an instance of jest.fn() . This allows us to make assertions on what is passed to the local storage setItem API.
Read more

Solving `Empty reply from server` in DotNet Core

tldr; If you’re getting  curl: (52) Empty reply from server  check that you’ve configured Kestrel correctly. Long version I’ve started playing with Dotnet Core and Docker and have had a few issues getting started. I’ve had a little bit of experience with Docker, though only a little. I’ve worked with DotNet previously but never with Core. Environment The setup I’m using is a Windows laptop running Vagrant. Via Vagrant I’m running an Ubuntu Virtual Machine with the Docker run time installed. Feels a litle like inception. Key Problem The key problem that I’ve had getting started was having my Docker container not responding correctly to my curl commands. I get this: curl: (56) Recv failure: Connection reset by peer curl: (52) Empty reply from server Given that I’m not all that familliar with Docker or Dotnet Core I decided to remove one of the variables and set up a simple Express app in a different docker container. This validated that the commmand I was usin...
Read more

Can't resolve DNS Aws

Image
I recently registered a domain for a joke website  saladsimulator.com .  I figured I could whip up the page in a couple of minutes and throw it up on AWS using S3 static site hosting.  All done in an hour or so. What I thought would take an hour ended up in a multi-day ordeal while I tried to get the DNS to resolve.  I went through what seem to be the typical problems. The bucket wasn't configured to be accessible as a website. My bucket wasn't named the same as the website; the bucket needed to be saladsimulator.com to match the domain saladsimulator.com . I got these fixed up and found that it still wasn't working.  I added extra routes in to see if I could Alias or CNAME to a known working site, but they didn't work either. So it seemed it was a problem with something to do with the DNS configuration. After searching around I found a mention in a thread that the name server records in the hosted zone needed to match those in the domain name registrat...
Read more