process vs outcomes

Process vs outcomes: Which matters more to dev teams?

on Jun 13, 17 • by Alan McKellar • with No Comments

Last week I discussed the 2 big take-aways I had from MHA17. In this post, I'll explore how focusing on outcomes necessitates the need to consider value...

Home » Agile Development » Process vs outcomes: Which matters more to dev teams?

Last week I discussed the two big take-aways I had from Mile High Agile 2017 (MHA17). First, we need to look beyond practices and process if we want to gain significant improvements. Our ability to improve is beginning to plateau in these two dimensions since Agile techniques were embraced broadly nearly two decades ago. Most of the future improvements will come from looking at the challenges of software development in a new light. Second, that a holistic view of the entire system will help us optimize overall throughput instead of simply optimizing each component within our systems.

This week, I’ll explore how focusing on outcomes necessitates the need to consider value.

Focusing on outcomes is critical as it helps guide our use of time – our most important asset. And it ensures that we are giving our customers what they need. Failure to focus on outcomes means we stay busy but really don’t make progress.

Engineers tend to like to solve tough puzzles. After all, it is how we are wired. Yet research from an IDG InfoWorld study indicates that 85 percent of developers either frequently or sometimes spend their time troubleshooting software issues. If we consider value and think about time as our most important resource, is there a better use of software developer’s time?

Giving back time to software developers would allow them space to work more closely with their customers and more time to solve problems that are specific related to the customer’s environment. The value of a good developer is driven by the ability to solve a problem they have never seen, how to step through a problem in a logical fashion, and understanding their customer.

So, if we look at development holistically, we begin to see how a multi-layered approach would help. Instituting peer code reviews, beefing up continuous integration, and introducing better tools like CodeDynamics to find memory leaks, arithmetic pointer errors, and race conditions in highly scaled computing environments. With this, you can carve out space to support targeted innovation. And, move beyond asking, “how do I take advantage of new technology” to actually having some engineers available to build a prototype.

How could you carve out more space for your software developers?

Related Posts

Leave a Reply

Your email address will not be published. Required fields are marked *

Scroll to top