 |
VOOZH | about |
|
VOOZH | about |
We’re so glad you’re here. You can expect all the best TNS content to arrive Monday through Friday to keep you on top of the news and at the top of your game.
Check your inbox for a confirmation email where you can adjust your preferences and even join additional groups.
Follow TNS on your favorite social media networks.
Become a TNS follower on LinkedIn.
Check out the latest featured and trending stories while you wait for your first TNS newsletter.
BILBAO — Anna Daugherty thinks we shouldn’t be so obsessed with developer productivity. That was a spicy take at last week’s Continuous Delivery Mini Summit.
“This is something I talked about with almost everyone at the conference,” Daugherty, director of product marketing at Opsera, told The New Stack.
“There’s a difference between an individual trying their best and singling them out for not being productive. But productive doesn’t mean anything,” she continued. “Is individual developer productivity determined by code commits? What they accomplished in a sprint? The individual on the team, doesn’t a product make.”
Productivity metrics are trying to answer the wrong question, Daugherty argues, when you really should focus on:
Just like DevOps looks to accelerate the speed of the team’s delivery of software, Daugherty contends, you should look to focus on software team enablement, not individual developer productivity.
The most common DevOps metrics aren’t really metrics. DORA is more of a framework, she says, to measure velocity — via lead time for changes and deployment frequency — and stability — via change failure rate and time to restore service.
DORA “allows you to have some sort of metrics that your teams can work toward, or that have been identified as being metrics that indicate high performance,” she said. “But it’s not necessarily like the end all, be all. It’s not a Northstar metric. It’s an example of what is can constitutes a high performing software team.”
For Northstar metrics you could go for the 2021 SPACE developer productivity framework or the recent McKinsey developer productivity effort, which she says “is both SPACE plus DORA plus some other nonsense that they’ve all wrapped up.”
But really, you have to keep it simple. For Daugherty, that comes down to asking why you’re creating software in the first place, which comes down to three audiences:
While DORA and SPACE can point you in the right direction, she says you should be measuring outcomes that help measure the satisfaction of those three reasons to build software.
Also Read: Google Says You Might Be Doing DORA Metrics Wrong
This looks to answer if the software that you’re delivering is usable and delights your customers, she explained. This can be assessed via net promoter scores (NPS), G2 and other product review sites, and customer testimonials.
You need both qualitative data, with tight feedback cycles with your product’s users, and quantitative tracking, like drop-off rates.
Look to answer: Do your developers enjoy creating and releasing software? Do you have a high level of developer burnout? This is where platform engineering comes in as a way to increase developer enablement and reduce friction to release. This can be measured via platform adoption rate, regular developer surveys with an actionable follow-up strategy, Glassdoor reviews and sentiment on their public social media.
Is your delivered software helping capture the desired market share? Is it creating investment and/or partnership opportunities? Is it actually moving the sales pipeline along, generating measurable profit? Daugherty explained that business metrics are assessed by measuring things like the sales pipeline, investment and partnerships.
Some companies only seem to focus on the business metrics. But, while there’s been a noticeable shift in the tech industry “from growth at any cost to every dollar matters,” Daugherty emphasizes, how to increase developer productivity isn’t the right question to be asking.
Part of this is the fundamental disconnect between business leadership and engineering teams.
“Business leadership is always measuring revenue and pipeline, but that isn’t making its way to the engineering teams, or it’s not being translated in a way that they can understand,” she said. “They’re always chasing their tails about revenue, about pipeline, about partnerships [and] about investment, but it really should be a full conversation amongst the entirety of business, with engineering as a huge consideration for who that audience should be.”
Indeed, engineering tends to have the highest salaries, making it an important cost center. One of the early goals of platform engineering should be to facilitate a common language where business understands the benefits of engineering, while engineers understand the connection of their work to delivering business value.
Still, a lot of organizations fall short here. Sometimes, Daugherty says, that persistent chasm can be bridged by the blended role of Chief Digital Officer or Chief Transformation Officer.
Also Read: Developer Empowerment Via Platform Engineering, Self-Service Tooling
Software delivery enablement and 2023’s trend of platform engineering won’t succeed by focusing solely on people and technology. At most companies, processes need an overhaul too.
A team has “either a domain that they’re working in or they have a piece of functionality that they have to deliver,” she said. “Are they working together to deliver that thing? And, if not, what do we have to do to improve that?”
Developer enablement should be concentrated at the team outcome level, says Daugherty, which can be positively influenced by four key capabilities:
“Accelerate,” the iconic, metrics-centric guide to DevOps and scaling high-performing teams, has found certain decisions that are proven to help teams speed up delivery.
One is that when teams are empowered to choose which tools they use, this is proven to improve performance. When asked if this goes against platform engineering and its establishment of golden paths, Daugherty remarked that this train of thought derails from the focus on enablement.
“Platform engineering is not about directing which tools you use. That’s maybe what it has been reduced to in some organizations, but that’s not the most effective version of that,” she said. “Platform thinking is, truly, you are Dr. Strange from the Avengers, and you see the bigger picture and where things come together and align.”
Platform teams shouldn’t be adopting a rigid, siloed mindset of this team does this and uses that tool.
Platform engineering is about bringing people, products and processes together to increase efficiency and effectiveness for all teams, Daugherty clarified. “Does that means maybe sometimes choosing better workflows or technology and architecture? Yes, maybe for your business. But that’s just a reductive way of thinking about it,” if that’s your whole platform strategy.
Despite job roles, she emphasizes, DevOps and platform engineering are ways of working, not things you do or not do. And a platform team looks to trace over the DevOps infinity symbol, to make the pathway to delivery and the communication between Dev and Ops even smoother.
“A lot of people tell me: ‘I hate people like you, because you come in and tell me that I need this tool, and I need to do it this way’,” she said. After all, Opsera is a unified DevOps platform for engineering teams of any size.
But she always counters, “I’m not here to tell you anything. I’m here to help you do the work that you want to do because your work matters. And to help you understand how to communicate that value that you’re bringing to your organization to those business leaders who want more from you. And they constantly will be asking more from you.”
Her role, Daugherty says, is to help teams — and by extension the individual developers that make them up — to figure out how to deliver more, without increasing developer burnout.
DevOps is about enabling the right kind of communication to increase speed and collaboration — not creating more human-in-the-loop bumps in the road.
“Teams that reported no approval process or used peer review achieved higher software delivery performance,” found the research cited in Accelerate. “Teams that required approval by an external body achieved lower performance.”
It doesn’t necessarily mean zero approval process, but it’s more about keeping the majority of decisions within that team unit. Accelerate continues with the recommendation to “use a lightweight change approval process based on peer review, such as pair programming or intra-team code review, combined with a deployment pipeline to detect and reject bad changes.”
This could be an ops-driven, automated approval like in your Infrastructure as Code or an integrated test, explained Daugherty, or a human-to-human opportunity for shared knowledge.
“It’s gone through a peer review so that people on your team are in agreement that this is what they want to deliver,” she said. “And then it’s automatically deployed to production and not hanging around waiting at some gate [or] some bottleneck. If you have integrated testing and security throughout your pipeline, that’s going to enable you to do that.”
Peer review processes both ensure readability and thus maintainability of code, while also facilitating informal training. Daugherty recalled what Andrew Fenner, master designer at Ericsson, said during a panel on developer experience and productivity, also at the Continuous Delivery Mini Summit.
“Ericsson is kind of an old school sort of company, and so them being able to do this lightweight approval process is kind of a miracle.” Daugherty continued that Fenner spoke about how, sometimes, their most senior developers spend most of their time helping more junior developers, instead of committing code themselves. If you are measuring these more senior members by traditional, individual developer productivity metrics, they would score poorly. But, in reality, their less measurable impact has them helping to improve Ericsson’s junior developers every day. It also means knowledge is not perilously held by one team member by shared across the team.
“That’s what I mean by lightweight — not expecting your developers to have all the answers all the time, [but] to have some mechanism that’s easy for them to get feedback quickly. And to utilize the most knowledgeable and helpful people on your teams to be able to deliver quickly that feedback,” Daugherty said. “That lightweight idea is very much about not standing in people’s way. The better and easier they can deploy to production, the better outcomes they will have, based on velocity and stability.”
