You have 1 article left to read this month before you need to register a free LeadDev.com account.
As an engineering leader, the most common question I hear from the exec team is, ‘when is feature X going to be ready and what can we do to deliver it faster?’
I get it. Our mission is to deliver value to customers (and the business) as fast as possible, especially at my current company, LinearB, which is a fast-growing start-up. We care about quality and cost, but the number one thing the CEO wants from my team right now is customer-facing innovation. Every conversation I have with the executive team revolves around when new features are coming and how we can deliver them faster.
The struggle is real
The problem is, it’s not a simple question! In order to figure out if we can move faster on feature X, first we need to answer the following questions:
- What is the current status of feature X?
- Are there any blockers or process bottlenecks slowing it down?
- Which engineers are working on it and what else are they working on?
I’m one of the rare software engineers that likes Jira, but unfortunately, it doesn’t provide an easy way to see the answers to these questions. So, to get this information, you need to interrupt your teams to ask them directly. Then the really hard part is trying to synthesize what you learn and communicate it to your CEO, which always results in an inevitable negotiation between engineering, product, and the business: What can we sacrifice for the existing engineers to move faster on feature X, or how can we put more people on the project? In my experience, these conversations rarely go well. I’ve had CEOs who, like many people, are visual thinkers and need to see the data; trying to explain it verbally or with crude spreadsheets doesn’t work.
Better negotiations with the business
When I got the job running engineering at LinearB, I had a list of things I was determined to improve. Fixing the negotiations around how to deliver a particular feature faster was at the top of the list. Through trial and error, I found there are three things you can do differently to fix these conversations:
1) Correlate projects to real developer work: Jira is not particularly useful for seeing the accurate status of features or projects. Even if your team is okay with Jira hygiene and you’re up to date, there isn’t enough information to make decisions. To get around this, we built reports that correlate our work from Git and CI/CD so we can see which features developers are working on, if they’re focused on feature X or distracted by other work, if they’re blocked (for example if a pull request is sitting open for days), and if the code they contributed to feature X has been merged and released.
2) Share simple visualizations: As you can imagine, trying to correlate three to five different data sources can make for a complicated report. It took us many tries to find a format that communicated critical information at a glance and could be consumed by both technical and non-technical stakeholders. We worked closely with the customer (our own CEO and exec team members, in this case) and invested hundreds of UX hours into getting the Project Delivery Tracker right.
3) Be proactive: It’s important that the Project Delivery Tracker is viewable on-demand but discussing progress regularly in executive meetings can also help to eliminate surprises and contentious conversations. For our team, we found that the sweet spot for verbal updates was every two weeks. So, every other week in the CEO’s Tuesday staff meeting, I talk through the dashboards, provide updates, and answer questions.
How to give comprehensive updates
When giving these biweekly updates, it’s important to provide the right data. I share the following data points from Project Delivery Tracker for each of our top projects:
People investment: We use automation to correlate our Git branches and PRs to project issues, and correlate our issues to projects so we can see a snapshot of A) which developers are really working on each project and B) the percentage of our total team working on each project in the current sprint and over time. It’s incredibly helpful for our CEO to look at the dashboard and know 40% of the team is working on X, while 30% of the team is working on Y and so on. If we want to invest more in X, it’s easy to visualize the impact of moving people from other projects, allowing us to have a data-driven negotiation.
Task velocity: We do not use story point velocity to measure the performance of teams or individuals and I strongly advise against this practice. However, tracking story points throughout is a very useful way to show the progress being made on specific projects. It helps our CEO to see if we’re speeding up or slowing down as well as the effect that holidays and vacations have on delivery. For scrum projects, we represent this as a burndown. For our kanban projects, we show it as a cumulative flow diagram. Our CEO loves the clear visualization of cause and effect that comes from using the people investment and task velocity dashboards together. When we allocate more people to a project, he can immediately see the effect this has on velocity.
Planning accuracy: I like showing planning accuracy for our scrum projects because it highlights common bottlenecks. If we completed significantly fewer story points in a sprint than we planned, it is often because the team was disrupted by unplanned work. Again, our CEO likes to understand cause and effect, so if he sees task velocity is down, he can look to see if the number of issues added during the sprint was high and decipher whether a bug set us back or if the product management team added requirements. Another common reason for inaccurate planning is an increase in cycle time. By correlating Git work to Jira projects, we can see if a bottleneck in our process (like high pull request review times) slowed down work on feature X.
Task profile: For long-living initiatives, it’s useful to see the breakdown percentage of time being spent on features, bugs, and non-functional work. Before we invested in CI/CD to automate our pipelines, our release process was often a bottleneck to getting value in the hands of customers. We convinced our CEO that a short-term investment in non-functional work would have a long-term pay-off in project velocity. Using the task profile view in combination with the task velocity view, we could reassure him that it would have the cause and effect he wanted, showing that the investment would come with a positive return.
A new dreaded question…
Since I started highlighting these data points from our Project Delivery Tracker every two weeks in the executive staff meeting, engineering has become more aligned to the business and our CEO no longer feels like we’re a black box. And, maybe more importantly, my team throws away less work and is less burdened by abrupt changes in direction and last-minute pushes to hit unreasonable deadlines. I hope you can learn from our experiences and implement some of these techniques to have better negotiations around your feature delivery times.
The problem? Now the next thing our CEOs will want to know is, ‘when is your team coming back to the office…?’
