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

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 using to run
Read more

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

Building a verify JWT function in TypeScript

# Verifying an RS232 signed JWT JSON Web Tokens (JWT) are used as a way to verify the identity of the caller of an API. **The best way to verify a JWT is to use a verification library.** I wanted to have a look at some of what those libraries are doing under the hood by putting together a function that will return if a given token is valid. In this blog I'll go through what I have done to get a validation function working. To simplify things assume: - That the signing algorithm is RS232 all others are considered invalid. - That the public keys are available on a JWKS url provided to the function eg [https://klee-test.au.auth0.com/.well-known/jwks.json](https://klee-test.au.auth0.com/.well-known/jwks.json) - I only want to know if the token was signed by a key available at the above url. I wont be checking if the token has expired, if the scopes or other claims are valid. # Break up the token A JWT is made up to 3 parts. The first thing to do in validating the token is to brea
Read more