Does Software Development Productivity always mean getting more work done in less time? No.
The other day Paul Adams, who runs product at Intercom, posted the above diagram. Which made me think of a challenge that Jonathan Cutrell's podcast gave to its listeners on his episode about development productivity:
Minimize the output to get to the same place.
"Productivity and effectiveness is not about how much you do, but about what you do." - Jonathan Cutrell DeveloperTea
It is easy as an engineering manager to get focused on the "Outputs" stage e.g. how many tickets we moved to Done this sprint. However the best in class teams evaluate their work by focusing on what business value can we deliver. How do we get to our desired outcome for our customers with by being the most effective and efficient.
Software engineering effectiveness is to do things right.
Software engineering efficiency is to do the right thing.
Spend more time in the inputs stage. For instance, go over your Jira backlog for the next sprint. Now look through it from the lens of what's the least the team can do to get to the output desired. Some useful tactics:
In conclusion, doing the right thing means spending more time on the input stage but it pays off and over time you'll see it impact your team's development velocity.
And remember, in the words of Kelsey Hightower, "no code is the best code", it doesn't break and doesn't need testing.