Improving Execution and Monitoring Execution

One of the things I ended up being tasked with as the “leader” of the team, was monitoring our progress. One of our KPIs was to improve our execution. How do you monitor or even improve your execution as a team? That was one of the things we asked ourselves, and we started our journey down a black hole. Okay, it wasn’t that bad, but when you have to record every hour, break down and estimate tasks in hours and measure against both, it’s a bit much.

Measuring Execution

When we first started, we weren’t entirely sure how we could measure execution. Do you measure points done? Do you measure time? Do you measure tasks? We first started by measuring points done. And by “done”, for us, that’s merging into master and deploying to live. You can see by the example graph below that we weren’t meeting our sprint commitments. I don’t know about you, but if I saw a team with a graph like this, I would wonder why.

The reason it looks so low is because we measure points per sprint. There is no carryover. We re-estimated story points every sprint so that we measured for done. The more we used this system, the more we realised that we were over committing per sprint. But, this graph still doesn’t tell the story of our execution. We still have this graph, but we use it in conjunction with the next graph.

The next example I want to show is tasks done. When we started recording these, we weren’t too interested in the number. But when you combine it with your story points you start to get a picture of what happened during the sprint. One of the things you’ll notice towards the end is that we got better at recording tasks. We got better at showing why things are not done or done. I mean, if you can say – hey – we added 17 tasks that weren’t part of our original estimation, maybe our planning is bad and not our execution.

For execution as a KPI, we decided to use the tasks done/not done as an indicator. If we’re getting a lot of tasks done, then we’re obviously doing work, right? Story points don’t tell the whole story. Now, I’m not saying I agree with this method. In fact, I think we should be able to carry over story points. However, that doesn’t help the business. We want smaller stories that can be done faster. If you’re always carrying over points and have one sprint with nothing and the next sprint with max, you’re not delivering value for two sprints. That’s one lesson I’ve learned from my current manager. Deliver results as soon as possible.

Improving Execution

While I’ve talked about how we measure our execution, I haven’t talked about how we improved it. We didn’t meet our KPI, but we got close. I’m a minority in my team. Most of my team would rather speak another language than English. So, one of the things we have worked on is communication. How do you improve communication?

Well, there are a couple of exercises that our manager had us try.

1. Work on only one story at a time.

   
   As a team, we first thought that parallelisation would be the best thing to do. Everyone work on their own stories. Makes sense, right? We have better utilisation of employees, and there will be no merge conflicts until we need to merge to master. Everyone can work on their branch.

   Unfortunately, that didn’t work for us. What ended up happening is that everyone would work on their own branches for the entire sprint and none of them would get merged in time. This is bad because the business won’t see any value in that sprint. Sure we have 100% efficiency, but our execution was killed.

   We have found that each team should work on one and only one story at a time. Everyone on the team needs to work on that story. You don’t get 100% efficiency, but the business sees value sooner. And because you have many eyes on the code, your code should end up in a better place than otherwise. Now, not all the time can you work on one story. Sometimes you have tiny stories or you’re near the end of a story. If you can’t parallel the story any more than it is, then you can move on to the next story.

2. One day story

   
   This will be a challenge for your team and an experiment. Find a small story that would take a couple days for one developer to do. Now, motivate your team to complete it in one day. That includes deployment. You don’t need to reward them with anything, it’s more an exercise in task break down and communication. Why do I say this? Because for us we’ve had a couple one-day story experiments. We’ve failed all of them (to my recollection). That’s not bad. You learn from failure. One of the things we’ve learnt is that we need to break down better.

   If your team has trouble breaking down. Requirements missing. Stories dragging out. Try this method. Try to get them to complete one story in a day as part of the sprint. The next day you can have a mini retro and find out what went wrong. You don’t need to do this often. Once every now and then when an ideal story pops up is okay.

3. Own your code

   
   If you work in a fairly big company with a lot of developers, you’re probably relying on some APIs to get some data. What happened before is that we used to request changes from other teams. These would be put in the team’s backlog. Your team then had to wait to start your story until the other team prioritised yours. Well, that may work for the other team who owns the API, it certainly doesn’t work for the team that needs the API change.

   So, we changed our minds to “own your code”. We will now program in other teams API and send them pull-requests for our changes. This ended up reducing lead time for the APIs in question and reduced our execution time. I mean, we still wait for code review and pull request approval, but we’re getting faster.

I hope that some of these tips will help you improve your own execution. Execution != efficiency. You can have a high efficiency with almost no execution. Execution means getting stories and tasks done. If you decide to use any of these tips, feel free to let me know in the comments below.

Reposted on Medium.