Tips, Expertise, Articles and Advice from the Pro's for Your Website or Blog to Succeed
In 2014 the DevOps Research and Assessment (DORA) team published their first State of DevOps report, identifying four metrics that can be used to measure engineering team performance.
Six months ago the Data Science Team at LinearB decided to continue where DORA left off, digging deeper into the data than ever before. For the first time in history, engineering teams are able to benchmark their performance against data-backed industry standards.
As a manager of a software development team, you are always under pressure to deliver value to the customer. In order to do that more effectively, you monitor your Cycle Time and work to keep it as low as possible so that features get into production as quickly as possible.
One of the issues that can be a bump in the road towards meeting that goal is Review Time. Review Time is defined as the time between the first comment on your code and the time it is merged back into the main branch. It’s the third phase of Cycle Time and keeping it inside proper boundaries is critical to keeping quality code moving through the pipeline.
Objective data to measure software development is here, and it’s here to stay.
For a long time, the notion of using such data was thought to not really be possible. Thought leaders like Martin Fowler and Joel Spolsky basically said it couldn’t be done. Clearly, it’s a challenging task that frustrated software development managers everywhere. Shoot, I wrote an article way back when basically arguing that it is impossible to do.
Well, I’d continue to argue that it was impossible to do. But now, with the rise of tooling like git, Jira, and other project management tools, it started becoming clear that the data is there to enable us to get a closer, more data-driven look at what is going on inside software development projects. That data just had to be revealed.
Informing someone that you want to “measure” them is not a great way to start a conversation. Software developers, like all people, tend to look unfavorably upon having their performance closely measured. But measuring developers is one of the hottest trends for companies around the globe. So is it tyranny to measure people?
People are quick to note that numbers don’t tell the whole story and can become defensive at the notion their productivity should be quantified somehow. This resistance can become even more entrenched when teams become stacked against each other.
Change is difficult.
And it’s even more difficult if you’re the one trying to make change happen. But as more organizations start modernizing their software development workflows, like going from story points to cycle time, change is something we need to learn how to implement.
When I was a software developer manager, there were a lot of questions. Questions that my boss asked me. Questions that I had myself. Questions that arose when discussing work with my team. And most of these were questions to which I did not have a good answer. I couldn’t respond well to them because I didn’t have the data necessary to give a definitive answer.
The data was there, but without a way to get at it, I often felt like I was stumbling in the dark. But all is not lost. Here are eight questions that I had, and ways that data inside your tools can be used to answer them.
Software developers submit a pull request (often abbreviated to PR) in their git system like GitHub, GitLab or BitBucket to signal to their teammates or manager that a branch or fork they have been working on is ready for review.
The git pull request usually happens in the software development process after coding and before merge.
Productivity in software development is typically tricky to measure. Is it how fast your team is doing something? It has been proven time and again that lines of code are a poor measure; are the number of modules an indicator? The degree of module reuse within a project, or from previous projects?
This post is the second article in our Tactical Guide to a Shorter Cycle Time five-part series. Read the previous post here.
You discover your engineering team has a long Cycle Time compared to the rest of the organization or compared to the industry’s top performers. Now what?
The topic of Agile metrics inevitably comes up in many situations and conversations. I have been hiring Scrum Masters lately. One of my screening questions read, "What standard metrics would you track if any and for what purpose?" I cannot tell you how many candidates mention velocity, burndown and burnup charts. Very few can reasonably explain the meaning and use for those.
So far, I hired 2 Scrum Masters whose answer to the question didn't have any of those metrics. What these two have in common was they mentioned and could talk about Cycle Time. Mind you, that was not the only reason they got the job, but it gave them an advantage over others. Rarely do you hear Scrum practitioners bringing up Cycle Time, Lead Time, Throughput, or Work Item Age. These all firmly used to belong to the Kanban world. Somehow during the Holy Scrum-Kanban decades of feud these metrics were banished from the Scrum land and forgotten by many.