Category: Software Industry

Agile Estimation Theatre

We’ve all experienced what I like to call Agile Estimation Theatre. Imagine it’s the beginning of the sprint and your team is holding a sprint planning meeting. The project manager has built up a set of stories a few of which have subtasks. Now you will spend the next two hours trying to create estimates for each of those stories. 

The project manager starts by reading the first story. Someone asks a question about whether ECS or EC2 are a better solution for the problem which devolves into a 20 minute conversation about the merits of various AWS services. The project manager is forced to stop discussion to leave any possibility of estimating all the stories slated for the sprint. You open your planning poker tab and evaluate your options 1,3,5,7,13,21,34, 55. After a moment you decide on 13 since you are sure the task will take at least a day or two. One of your coworkers then asks whether the numbers are days or hours. That question leads to a 10 minute discussion of what exactly story points are and how they are definitely not a unit of time. The teams votes range from 5 to 34. And then project manager overrides the score to be 21 since that’s what the senior engineer picked.

The two hours continue to drag on. By the blessed end of the meeting your team has ‘estimated’ 4 out of 20 single sentence stories. Since the sprint starts tomorrow the project manager holds a quick meeting with the senior engineer to estimate the rest of the stories before 5pm.

The above tale represents what I like to call agile estimation theatre. We have a sprint planning meeting where we’re supposed to involve the entire team in estimation, so we schedule a two hour meeting and hope for the best. Sometimes it actually works, but often we end up with questionable estimates for single sentence tasks.

The fundamental problem with Agile Estimation Theatre is not investing enough time. To get good estimates you need to have complete stories. You need to break down subtasks and specify them more thoroughly than a single sentence can possibly handle. Then you need to have your team spend time reviewing the stories individually and coming up with estimates. The problem is that it doesn’t make sense to spend several days out of a two week sprint on estimation. To do it right you need to have well specified stories. Building out the stories will take at least a few engineer days. Next you need to have the entire team spend 2 hours each estimating stories individually. Finally you add together the individual estimates and do the sprint planning meeting. Now repeat that process again every two weeks.

The breakdown is that the expected value of the estimates is typically less than the cost of spending a few days to produce good estimates. The organization intuitively knows this which is why we spend two hours in sprint planning instead of two days. But because we want to do scrum or agile ‘properly’ we need estimates. The end results is that we denature the estimates to comply with the process.

KPIs for Software Engineers

Key Performance Indicators are a common business practice. They are a quantifiable measure of performance for a specific objective. Occasionally, I am asked to create my own KPIs as an individual contributor. I think it is a bit strange, after all I work for the company, you’d think they would tell me what the KPIs are!

Ideally we want to avoid metrics which are created arbitrarily by team members. Hours worked is a great example of this especially in remote work environments. In hourly workplaces employees check in and check out to validate hours worked. I have never seen a software company do anything comparable. Typically, the software company employee is asked to fill in timesheets based on their personal memory with zero accountability. That scenario does not make for a good KPI. 

For our KPI metrics we have the following criteria:

  • countable 
  • verifiable by external system
  • valuable 
  • Individually attributable 

Countable 

KPIs need to be quantifiable. It should be easy to number how many of X someone completed

Verifiable

There should be impartial systems tracking KPI completion. We want to use systems like PagerDuty, JIRA, Github, etc to source our KPI data. 

Valuable

KPIs should relate to valuable activities for the company. We want our staff focused on things that are important. 

Individually attributable

KPIs should be based on individually attributable work. We want to avoid subjective judgements of how much of task X engineer 1 did vs engineer 2. We also do not want to encourage infighting over who gets credit for which tasks. 

Here are a few measurable things we could use for KPIs. 

  • lines of code 
  • commits 
  • bugs fixed
  • tests written 
  • Pull requests opened | accepted / rejected
  • Pull request comments
  • Pull requests reviewed | approved / rejected
  • story tickets completed
  • stories estimated 
  • Projects lead 
  • Projects delivered / Epics delivered 
  • architecture documents published
  • architecture documents reviewed / comments / approved / rejected
  • Documentation pages published
  • oncall response time when paged
  • pages recieved daytime/off hours
  • Prod deployments 
  • meetings attended
  • Pair programming sessions attended
  • Junior dev questions answered (answers documented in wiki / private stack overflow)

KPIs are a useful concept for businesses to track their performance. But they are often really ideal for business groups to examine their performance. Individual contributors rarely can claim responsibility for things like increasing the subscription renewal rate from 1% to 10%.

While this list is not exclusive it should include most of the trackable numerical things that software engineers do in their job. Then if you need to come up with some KPIs for yourself you can just pick from this list.

If you can think of some more good metrics for software engineers let us know!

Agile has gone from ‘people over process’ to ’no process’

In practice ‘agile’ means ‘we have no process in place and each team does whatever random thing the manager wants to try next’. Sometimes that is SAFE sometimes its SCRUM, usually it’s a combination of different things. This isn’t necessarily a bad thing, but there are trade offs. 

The first is standardization. If every team follows a different process it’s difficult to understand what is going on at a management level. Which teams are productive? Which teams are in downward spirals? If you don’t have a standard to judge against you can’t find out. 

Secondly, away team work is much harder. Working with a team that uses the same development process, pipeline setup, programming language and frameworks is easy. On the other hand working in the code base for a team which uses a different language, framework, architecture, etc is very difficult. Not supporting away team work severely limits your ability to integrate internal software components.

Thirdly, Estimates are not possible in this kind of environment. Since the process changes constantly historical data becomes useless. In response to this most companies don’t even keep historical data. The main use for estimates is ensuring that ‘burn down’ charts follow the 45 degree angle managers love. 

There is no team – Calibrating teams vs individual estimators 

Subjective expert predictions are a valid form of estimating software tasks. But if you don’t have historical data to calibrate against estimates devolve into gaming the system. 

When you change how estimates are made, when tickets are considered done and the sprint cadence every 3-6 months there is no way you can have cross company data on productivity. The lack of process empowers management to obfuscate the productivity of their teams. The pursuit of the best process gives technical organizations a great excuse as to why they have no idea if their processes have improved over the last two years or not. 

In this type of environment all judgements have to be made based on subjective gut feelings and corporate politics. You don’t know which VP’s processes are better than the other because neither has any accountability. You don’t know which technical department is more efficient because neither the estimates or logged hours can be trusted. 

‘We’re being agile’ has become the excuse to follow whatever process you want. Instead of ‘people over process’ it has become  ‘no process’. 

When creating processes (mechanisms) its important to consider who benefits

A business process is any procedure that is done manually by employees. In the software engineering environment this includes everything from code reviews to standup and 1 on 1s. 

Compliance with processes involves education, incentives and punishments. People need to know about the process to follow it. And if you don’t attach incentives to the process, negative or positive, people won’t feel a need to follow it. 

A common cycle I see is that management will think of a new process which could solve a problem the development organization is facing. They then declare the new process and are surprised when later on no one is following the new process. 

When designing new processes it’s important to consider who benefits from the process. Additionally, it’s helpful to contrast who benefits with who is required to implement the process. Are the same people benefiting from the process as the people expected to implement the new process? 

Your job as management is to create and enforce the business processes the team follows. Typically, this is best done with buy in from the team but the buck stops with middle and senior management. So it’s important to review what processes you tried to implement and how it went. 

What pain points did we try to address with new manual processes this year? How clearly did we define the new process we wanted to implement? Did the team follow the process as expected? Who’s pain point did the new process address? Was it the development team? Was it the product team? Was it the management team? 

Typically, people do not need incentives to follow processes which benefit them. But getting people to follow processes which do not benefit them is much more difficult. 

Take the example of sprint burn down charts. These charts provide utility to project and management team members. But they rely on the engineering team members to update tickets consistently. 

The conflict comes In because burn down charts provide zero benefit to engineers but all the work to support them has to be done by engineers.

This creates a dynamic where engineers are always incentivized to reduce their time commitment to updating tickets while management is frustrated that nobody is updating tickets.

You can of course make updating tickets the primary job task for engineers to fix this issue. But then instead of developing features, updating tickets becomes the primary job responsibility for the engineering team. Not what you want in a development organization.

The problem is that you have a fundamentally extractive business process. You need some group to take on extra work duties to improve the situation for another group. Having good reporting on the state of development tasks is an important thing for engineering organizations. But when designing processes to achieve that goal it is important to think about the process in the correct context. 

Being one sided is not a bad thing in general. Businesses are fundamentally about generating profit. If we need an extractive process to make money then it is justified in the context of the business. 

However, ideally we want to avoid these kinds of processes. We want to create processes which align the value produced with those doing the work. Because people enjoy following processes more when there is something in it for them. It makes their jobs easier and as a manger it makes your job easier because you don’t need to police whether people followed the process. 

I’m excited to announce Sledgeconf 2023: architecture success stories.

For the next sledgeconf we will focus on software architecture success stories. 

What does architecture success mean? Software architecture is the way we structure our software programs. A successful architecture enables us to support user requests, integrate improvements all while making it easy for the engineers working on the project. 

A bad architecture has to fail in some major way. It might have simply not worked once it was built. It might have made it hard for maintainers to fix bugs. it might have been too expensive to operate. 

They say that all happy families are alike, but at Sledgeconf 2023 we ask “Are all happy architectures alike?” 

If you have a software architecture that worked that you be willing to speak on let us know! We are looking for speakers for Sledgeconf 2023!

Tentative date May 12th 2023

https://sledgeconf.dev