• Skip to main content
  • Skip to primary sidebar
  • Skip to footer

Alex Aitken

Technical and Engineering Leadership, Coaching, and Mentorship

Improving Execution and Monitoring Execution

March 5, 2018 By Alex Leave a Comment

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.

Share this:

  • Click to share on X (Opens in new window) X
  • Click to share on Facebook (Opens in new window) Facebook

Like this:

Like Loading...

Related

Filed Under: Leadership

Alex

Reader Interactions

Leave a ReplyCancel reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Primary Sidebar

About the author

Alex is an AVP of Engineering currently working at Bukalapak. He is a leader in full-stack technologies. Read More…

Pages

  • Speaking Experience
  • About

Social Profiles

  • LinkedIn
  • Medium
  • ADPList

Recent Posts

  • Interviewing as an Engineering Leader
  • Managing Low Performers
  • Getting Docker, React, .NET Core, Postgres, and Nginx Playing Nice
  • What Makes a Good Software Engineering Manager?
  • “Am I There Yet?” Said an Engineer

Archives

  • January 2025
  • August 2024
  • July 2024
  • October 2023
  • August 2023
  • October 2020
  • May 2020
  • February 2020
  • June 2019
  • March 2019
  • October 2018
  • September 2018
  • August 2018
  • July 2018
  • June 2018
  • May 2018
  • April 2018
  • March 2018
  • February 2018
  • January 2018

Categories

  • Coding
  • Essay
  • Leadership
  • Management
  • Roundtable
  • Strategy

Footer

Privacy & Cookies: This site uses cookies. By continuing to use this website, you agree to their use.
To find out more, including how to control cookies, see here: Cookie Policy

Copyright © 2025

 

Loading Comments...
 

    %d