Tag: technology

No McKinsey, You got it all wrong about developer productivity!

No McKinsey, You got it all wrong about developer productivity!

Disclaimer: I have been an enormous proponent of Developer Productivity and have tried to implement automated metrics collection in 3 orgs with varied success. In my Mentoring sessions with early-stage startup leaders as well, I (re)enforce the importance of being aware of Dev Productivity. So much so, that I have written a 2-part article on the same here, here and here. I have also been a huge fan of McKinsey and how they seem to get answers which eluded the attention and resources of mega-corporations or governments alike. However, this article is written to communicate an entirely different perspective. In my opinion, McKinsey has got this entire “framework” thing about “dev productivity” wrong.

Introduction:

About a month back, McKinsey published an article claiming that they have developed a framework to measure productivity. They also acknowledged the fact that they were simply rehashing some of the existing metrics (like DORA and SPACE), which were used by Engineering Leaders and have simplified it (without the context) and are pitching it to their traditional buyers, the C-Suite executives in Mega corporations. Actually, some of these metrics can be useful tools if used correctly -One example is Hand-offs. But, the main reason I have chosen to write this article is their central focus seems to be “Coders should code”. It also appears to have A) missed the context of every metric, OR B) Omitted the context so as not to burden their target audience.

Finally, there is a mix-max of things to track, metrics to monitor and Opportunities to Focus, which looks like

Captain Ramius Pointing to a young Jack Ryan that Admiral Halsey was reckless!

Captain Ramius Pointing to a young Jack Ryan that Admiral Halsey was Stupid!

The Legendary Kent Beck has written a deep 2-part piece on countering the conjectures presented by McKinsey and elaborating on the gaps that engineering orgs are traditionally bound to manifest. It is very well written and covers almost everything. There are also a bunch of other eminent Software Engineers who have written on this and I have tried to give a quick lot at the bottom of this article.

What Was I concerned about?

Focus On Activities

I was primarily concerned about the lack of focus on Outcomes and Impact and a focus on the “Activities” in the proposed framework!

Any engineering leader or manager will tell you that Code Review Velocity and Deployment Frequency have nothing to do with measuring outcomes. While I will not discount Cycle Time or MTTR (I take pride in building multiple teams with one of the lowest MTTR and Cycle times in the ecosystem). They are indicators of some process elements/activities that could lead to outcomes. If we want to measure something, it should be Outcomes, not activities!

Focus on Optimisation of Irrelevant Metrics

Code Review Velocity:

If you want to time-motion the code review process in the entire stream map, you’ll find that async code review is killing your productivity. Pairing improves that dramatically. Instead of trying to sub-optimize for code review, measure the thing we actually want to improve. Which will be “Cycel Time”.

Story Points Completed:

Let’s agree on a basic fact. A “story point” is a made-up number. It was conceived as yet another way to obfuscate estimates for thought work that is difficult to estimate. As originally conceived, it represented the number of mythical “ideal days” of effort. There’s so much time wasted on getting better at “story pointing,” arguing about the Fibonacci sequence, “planning poker,” and other story point nonsense. Frankly, it is one of the “Bad” elements of Scrum! As a leader, you should find and remove handoffs and wait times. Story points are useless for anything and even more useless for this goal. Track throughput instead. 

Handoffs:

This is a good one. Good job, McKinsey. You got something right. Stop using testing teams, use pairing instead of code review, operate what you build, and don’t have any people doing anything manual to the right of development.

Contribution Analysis and Opportunities focus

In the other focus areas, they have listed metrics at the individual level that can be useful unless you measure “developer satisfaction,” “retention,” and “interruptions” at the individual level. These should only be measured in aggregates to prevent any cognitive bias. IMO, Things start getting really toxic in the “Opportunities focus” section, though.

I have been part of organisations and processes where there was a focus on tracking and measuring the outcomes of individuals. It did not play out well, ever. My Conclusion after reading the article for the second time is that McKinsey thinks their intended audience (CEOs and CFOs) cannot understand “systems thinking.” Now, If you roll out this or a similar framework and announce this and what do you think will happen?

You have a group of people all working on the same backlog but not acting as a team. Code review suffers, mentoring sufferers, pairing is hard, work breakdown suffers, etc. Anything that requires more than one person to conduct/conclude, including helping someone get unstuck, will get deprioritised!

Overall, The inferences seem to be based on hard facts, but the conjectures are all flawed.

Why This Now?

At this point, I want to highlight what “Triggered” me to write this, read the following.,

For example, one company found that its most talented developers were spending excessive time on noncoding activities such as design sessions or managing interdependencies across teams. In response, the company changed its operating model and clarified roles and responsibilities to enable those highest-value developers to do what they do best: code.

McKinsey’s Article on the purported Framework

Wow. I pray for that company.

So, I believe after McKinsey pointed to the fact, that developers are involved in irrelevant things like design, architecture etc. They created separate towers of responsibility for design. In that case, I am puzzled about who will be responsible for the minor things like dependency management, prerequisites, versioning, capacity planning, concurrency, scalability etc.

Did they get anything Right?

Yes. There are tonnes, but they are buried at the bottom. Their focus on Hand-offs and cycle times are really worth tracking in any engineering org. To the authors’ credit, they have also identified some of the core issues with measuring Developer Productivity. But, someone higher in the firm seem to have suggested to soften the blow. So, they have diluted and buried those sections. I will share 2 gems here.

To truly benefit from measuring productivity, leaders and developers alike need to move past the outdated notion that leaders “cannot” understand the intricacies of software engineering, or that engineering is too complex to measure.

The real problem is that in many large organisations, “The Management” doesn’t understand the work they manage. Management can understand the intricacies of software engineering if they become leaders and study the work they manage. In a large behemoth, not all managers are leaders. They want a framework and will enforce it with an iron fist. Now, McKinsey has delivered them a framework!

Learn the basics. All C-suite leaders who are not engineers or who have been in management for a long time will need a primer on the software development process and how it is evolving.

This one Nailed it! The primary reason “Management” finds it difficult to measure the right thing is because they sometimes do not understand the work they want to measure. Leaders who understand do measure the right things. My primary concern with this framework is, in trying to solve this, McKinsey has made the problem worse!

Just google “McKinsey developer productivity” and you’ll find more articles on how this framework is flawed than the original article link!

Anto’s Response to the Article and the purported Framework.

References & Further Reading/Watching:

1, Mc.Kinsey Article – https://www.mckinsey.com/industries/technology-media-and-telecommunications/our-insights/yes-you-can-measure-software-developer-productivity
2, Kent Beck’s rebuttal – https://newsletter.pragmaticengineer.com/p/measuring-developer-productivity
3, Redidit – https://www.reddit.com/r/programming/comments/1650595/measuring_developer_productivity_a_response_to/
4, Level Up Coding – https://levelup.gitconnected.com/the-developers-productivity-can-t-be-measured-in-mckinsey-s-way-an-analysis-4d81924279ae
5, Measuring Developers Productivity… McKinsey what’s the point? – https://www.youtube.com/watch?v=wjQn8nnkXTs
6, Can We Measure Developer Productivity? A Reaction to McKinsey’s Article – https://www.youtube.com/watch?v=ETa24ErdcwQ
7, HOW TO MEASURE ENGINEERING PRODUCTIVITY? – https://nocturnalknight.co/2022/11/how-to-measure-engineering-productivity/
8, Business Value delivery by Engineering Teams in StartUps – Part 1 – https://nocturnalknight.co/2021/10/business-value-delivery-by-engineering-teams-in-startups-part-1/#comment-773
9, Business Value Delivery by Engineering Teams in StartUps – Part 2 – https://nocturnalknight.co/2021/10/business-value-delivery-by-engineering-teams-in-startups-part-2/
10, Space Metrics – https://www.harness.io/blog/space-metrics-get-started
11, DORA Metrics – https://www.leanix.net/en/wiki/vsm/dora-metrics
12, Dave Farley’s Response To The NONSENSE McKinsey Article On Developer Productivity – https://www.youtube.com/watch?v=yuUBZ1pByzM

How to measure Engineering Productivity?

How to measure Engineering Productivity?

The fact that you clicked on this article tells me that you are leading/heading a Team, group or an entire Engineering function and most likely a fast-paced startup. Assume the following,

It was a regular weekday, and your CEO/CTO asked the most intriguing question.

Do we measure Engineering Productivity? How do we fare? What can we do to improve it?

Well, if your boss’s name is not Elon Musk or if you do not work for Twitter, you can still be saved. Go on and read through. I know it is a long read.

What is Engineering Productivity?

As with anything you’re trying to improve, it starts with measuring the right data. So, you can actually track the right metrics. This data will form the basis of your analysis and baseline. I strongly recommend you don’t change anything about your current engineering process before you can collect sex weeks’ worth of data about your processes. If you start working on processes, you could end up with a Survivorship Basis.

You should have sufficient historical data to make comparisons. On top of that, most teams work in sprints of two weeks, so six weeks of data allows you to collect data for at least three different sprints. This will give you the allowances for any spikes and eliminate any unusual stress or slack on the execution.

Next, you should make gradual changes to the engineering process to see what improves or impedes the value delivery. It’s ideal to only implement one change at a time, so you can see the effect of each change, with all other things being equal. (it never is :D)

For example, if your engineering squads suffer from significant technical debt, you may want to build an additional stub related to feature completion. Every time an engineer completes a new feature, they must document the new feature. This could mean describing the feature, how is it built, what are the outcomes, how it interacts with other functions and the reasoning behind the design decisions.

By continuously measuring engineering productivity metrics, you can determine if this change has positively impacted the developers’ productivity.

How Is Engineering Productivity Measured?

There are potentially 100s of metrics you can measure for an Engineering Org. Here are four key metrics that will help you to get started with measuring engineering productivity. And I have consciously excluded the Sprint Velocity.

4 Prime Directives of Engineering Metrics

1. The One Metrics to rule them all metrics – Cycle Time 

Software development cycle time measures the amount of time from work started to work delivered. It is a metric “borrowed” from lean manufacturing, and it is one of the most important metrics for software development teams. In plain speak, cycle time measures the amount of time from the first commit to production release.

2. The Oracle of an Engineering Leader – Release Frequency 

You should measure how often you deploy new changes to your customers (production). In addition, you can track deployments to various branches/instances, such as feature branches, hotfix branches, or QA branches. This data would show you how long it takes for a feature/fix to move through the different development stages. In addition, the Release Frequency reflects the throughput of your team. It’s a good stand-in replacement for Agile Velocity, so you don’t spook your Engineers and you are not blind as well.

3. The Guardrail – Number of Bugs

You should definitely track the number of bugs that your team has to resolve within 2 sprints of releasing a feature. This metric helps you to understand the quality of your code better. Higher-quality code should display fewer bugs after feature deployment.

While there are derivative and more evolved metrics like Defect Density, Mean Time to Detect (MTtD), Mean Time to Resolve (MTrR) and Code coverage, those onces makes sense after you’ve taken stock of and address the prime metric “ No: of Bugs” first.

If you want a more detailed list, methodology of QA metrics, refer the links given below. 

4. What is your “Blocker” – Review to Merge Time (RTMT)

This may look like a zoom-in on “Cycle time” metric we discussed earlier. But, in fact it is very different. In fact, it is an interesting metric suggested by GitLab’s development handbook. 

You should measure the time between asking for a pull request (PR) review and merging the PR. Ideally, you want to reduce the time a feature spends in the review state (or pending review state). A high RTMT prevents developers from progressing while they wait for feedback and encourages context-switching between different issues/features.

Arguably, Context-Switching is the highest productivity killer and should be avoided as much as possible

So, why would you measure all these engineering productivity metrics?

Why Is Measuring Engineering Productivity Important?

When you’re a “fast-growing startup”, it’s important to keep an eye on engineering productivity. It happens that these startups favour growth through feature delivery at the cost of effectively scaling the engineering team and ensuring the team’s efficiency.

I hear your question.

But, why does my CEO/VP/MD not understand?

Answer is simple

Assume you have to manage multiple VP’s expectations and outcomes (Sales, Marketing, Support etc), Company’s OKRs, and investors (or) board, will you have more time to dedicate to Engineering Productivity?

In these cases, technical debt can quickly grow, which will slowly kill your team’s productivity. Technical debt can have many negative consequences:

  • More bugs for your team to fix
  • Lower code quality—not only bugs but also worse code design
  • Harder to debug code
  • Scalability issues
  • A decline in overall happiness and job satisfaction

To avoid all of these scenarios, you should measure the engineering team’s efficiency and avoid technical debt buildup. Avoiding these problems before they occur is an excellent Occam’s razor.  But addressing them head-on will have a significant impact on your organisation, both materially and culturally. 

In addition to preventing your team’s productivity from going down, the engineering productivity approach allows you to experiment with various approaches to try and improve throughput & efficiency. 

So, the goal is to improve the engineering process itself. For example, introducing new tools or applying new techniques. Next, you can measure the impact of these changes on your team’s productivity.

In the next part, I will write down on how can measurement improve engineering productivity, Stay Tuned!

References:

  1. Survivorship Bias. 
    1. https://www.masterclass.com/articles/survivorship-bias
    2. https://en.wikipedia.org/wiki/Survivorship_bias 
  2. Cycle Time
    1. https://tulip.co/blog/cycle-vs-lead-vs-takt
  3. Release Frequency
    1. https://community.atlassian.com/t5/DevOps-articles/Why-should-we-start-measuring-the-Release-Frequency/ba-p/1786430 
  4. Detailed QA Metrics to ponder (in addition to No: of bugs)
    1. https://reqtest.com/agile-blog/agile-testing-metrics/ 
  5. Review to Merge Time
    1. https://about.gitlab.com/handbook/engineering/development/performance-indicators/#review-to-merge-time-rtmt 
  6. Context Switching 
    1. https://pacohq.com/blog/guide/the-high-price-of-context-switching-for-developers/ 
Bezos sells $1 bn in Amazon stock yearly to pay for Blue Origin

Bezos sells $1 bn in Amazon stock yearly to pay for Blue Origin


Yesterday, Billionaire entrepreneur Jeff Bezos introduced the Blue Origin capsule to the press corps.
Speaking Wednesday at the 33rd Space Symposium in Colorado Springs, Colorado, Bezos vowed to lower the cost of space travel and start taking customers to space by next year. Jeff Bezos said he is selling $1 billion in stock of his retail giant Amazon each year to finance his rocket company, Blue Origin, which aims to carry tourists to space by 2018.
The entrepreneur did not say how much a ticket would cost, as he showed off the New Shepard rocket and a mock-up of the large-windowed capsule that tourists will one day ride to suborbital space — just past the Karman Line some 62 miles (100 kilometers) above Earth — and back.
Bezos did say that the next-generation New Glenn rocket, which would be powerful enough to reach orbit and is expected to start flying satellites by 2020, is expected to cost $2.5 billion to develop.
Bezos did say that the next-generation New Glenn rocket, which would be powerful enough to reach orbit and is expected to start flying satellites by 2020, is expected to cost $2.5 billion to develop.
“My business model right now for Blue Origin is that I sell about $1 billion a year of Amazon stock and I use it to invest in Blue Origin,” he said.
“It’s very important that Blue Origin stand on its own feet and be a profitable, sustainable enterprise. That’s how real progress gets made.”
Bezos, a lifelong space enthusiast, founded Blue Origin in 2000.

DCNS's Scorpene Data Leak and Future of Indian Submarine Fleet

DCNS's Scorpene Data Leak and Future of Indian Submarine Fleet

File photo of Malaysia’s first submarine, “KD Tunku Abdul Rahman”, a Scorpene-class diesel-electric submarine. © Bazuki Muhammad Sourced from WikiMedia
A massive leak of documents on India’s new military submarines from French shipbuilder DCNS is the result of a hack, the country’s defence minister said on Wednesday.
Manohar Parrikar claimed, according to local reports, that the entire designs of its Scorpene submarines hadn’t been disclosed. “First step is to identify if its related to us, and anyway its not all 100 percent leak,” he was quoted as saying.
A DCNS spokesperson told Ars: “DCNS has been made aware of articles published in the Australian press related to the leakage of sensitive data about Indian Scorpene. This serious matter is thoroughly investigated by the proper French national authorities for defence security. This investigation will determine the exact nature of the leaked documents, the potential damages to DCNS customers as well as the responsibilities for this leakage.”
French naval contractor DCNS said on Wednesday it may have been the victim of “economic warfare” after secrets about its Scorpene submarines being built in India were leaked.
India opened an investigation after The Australian newspaper published documents relating to the submarine’s combat capabilities, raising concerns over another major contract with Australia.
The leak contains more than 22,000 pages outlining the details of six submarines that DCNS has designed for the Indian Navy. This has been touted as Snowden-Sized, especially so as India, Malyasis, Chile, Norway, Poland and several other nations are either in the process of acquiring or final bids for the submarines.
Even as DCNS says it may have been a victim of an economic warfare, it had already spilled into the strategic warfare realm. The leak describes in detail vital features of six Scorpene-class submarines that the French state-owned shipbuilding company DCNS designed for the Indian Navy, according to the Australian – which published a number of redacted documents on its website.
It could become an intelligence gold mine for India’s rivals such as Pakistan or China, given the potential use of the data to detect, identify and destroy the French-built submarines in wartime.
With the Scorpene  planned to be the backbone of the Indian Submarine fleet, it is high-time Mr.Manohar Parrikar started concentrating on Defense of the nation rather than meddling with wannabe super stars and eCommerce companies for promulgating Hindutuva ideologies.
Also, at this juncture, India should just limit its exposure to 1-2 submarines that are undergoing production and terminate the reminder of the contract. This will give the much needed budget for buying/leasing some of Project 941 (NATO RN : Akula)  from Russia or even Dolphin Class subs from HDW Germany.
 
 
 

Organisers of Brazil Protest use Analytics to Measure Attendance

Organisers of Brazil Protest use Analytics to Measure Attendance

Organizers of yesterday’s massive demonstration in São Paulo against the Brazilian government have employed an analytics tool to get accurate attendance data.
Opposition group Movimento Brasil Livre (MBL) was offered the technology by Israeli startup StoreSmarts for free through its Brazilian distributor SmartLok in exchange for the marketing exposure linked to the anti-government demo.
brazil-protest-fla_2593028b
The technology used in the protest is all readily available and is in use for atleast 3 years now. Its is a combination of portable router and an application that is usually employed by retailers to monitor, analyze and provide insights on shopper behavior by detecting WiFi signals from mobile devices in a designated area.
In order to estimate the amount of people in any given area, the system only takes smartphones into account while ignoring other WiFi signals from devices such as laptops or routers. The calculations are carried out in real-time, so the system can also provide insight on its web dashboard into the peak hours of the protests.
By calculating the device’s receiver signal strength indication (RSSI), the system can also tell how long the smartphone – and therefore its owner – spent in the area that is being mapped. However, the system does not track or store data on individual users.
Typically, protest organizers in Brazil or their comrades across the world have to rely on data provided by the local authorities and large media organisations to get accurate insights on attendance. These media organisations themselves rely on local bodies. Those numbers are often believed to be inaccurate for political reasons – the StoreSmarts system suggests that 1.4 million people attended yesterday’s demonstration, a number that matches what has been provided by the local police.
When asked why it is interesting to provide the technology free of charge, the startup founder says that his Brazilian partner has been piloting StoreSmarts’ analytics tool with some retailers in São Paulo – so getting the extra attention is helpful.
“We believe in taking data driven decisions, whether it’s politics or retail. The exposure we get by supporting such requests is very important for us and our partner, as we see Brazil as a very important market,” Eliyahu says.

Bitnami