RDEL #29: Besides coding, how do software engineers contribute to the agile development process?

This week we categorize the non-coding contributions software engineers make in the agile development process.

Welcome back to Research-Driven Engineering Leadership. Each week, we pose an interesting topic in engineering leadership, and apply the latest research in the field to drive to an answer.

A significant amount of software engineers follow some form of Agile software development. This process, focused on self-organizing teams, is a highly collaborative and iterative development process. For engineers, that means more than just coding. So this week we ask, how (besides coding) do software engineers contribute to the agile development process?

The context

In 2001, the original Agile manifesto was born out of a need to find a more human-centric alternative to the heavyweight processes that dictated software engineering in the past. 23 years later, and principles from the Agile manifesto are present in nearly every engineering organization. Many of those teams also use “Scrum”, an Agile framework that helps teams structure their work into short development cycles (or sprints).

To employ the Scrum process, teams need to focus on more than just writing code. There are a number of distinct processes - from retrospectives to sprint planning - that impact the success of those development cycles. This week we look into the role software engineers play in those tasks, beyond just the coding.

The research

Researchers at the University of Potsdam looked at the contributions of various key stakeholders in the Scrum process using the original Scrum framework as well as studies from numerous previous papers. They then used their findings to build a model that incorporates all the tasks and roles of the Scrum process.

Some key observations from the research included:

• While engineers (obviously) do more than just code, they actually participate in a number of non-technical tasks to ensure product success. This includes process improvement, progress inspection, setting goals, attending meetings, and product backlog refinement.

  • Note: this graph doesn’t show the distribution of time spent on these tasks.

• Researchers note that this is the “by the book” definition of Scrum, whereas modern teams have adapted their own interpretations of it.

  • For an in-depth look at the various project management styles within big tech companies, check out Gergely Orosz’s analysis of 100 engineering leadership responses.

The application

This paper does a good job of explicitly highlighting that engineers do more than just code in their day-to-day work. In fact, their presence in non-technical processes are critical to correctly scoping, communicating, and completing projects. This might be obvious to folks within the Agile development process, but for outside stakeholders, this is a very useful tool to communicate how engineering and product work together to deliver value to customers. As many engineering leaders already know, it’s not only about writing code :).

—

Hope you all have a wonderful week. Happy Research Monday!

Lizzie

From the Quotient team