Is the Engineering Process Overrated
Many engineers and managers focus too much on the process and overlook the far more important aspects of running a successful engineering team.
This article is a quick reminder of what really matters and where engineering managers should be spending their time and energy.
In the course of my work I have interviewed many people. And every time, the question inevitably came up: ‘How is your engineering process structured? Are you in agile team?" At the moment the terms agile, scrum, sprint are used very loosely and I dare say we hardly all understand them in the same way. How did we get from the original Agile Manifesto to where we are today?
Process is the key to building engineering teams. In my opinion, it is the least important aspect, but people are attracted to it because it is simple and tangible.
What really matters
Engineering teams are formed to build or enhance software products that customers need. It is important for most organisations that the teams deliver value at a predictable frequency. It is equally important that the teams are dedicated to maintaining and improving the technical component of the products so that future development and upgrades can occur at a reasonable rate.
What is necessary to achieve this?
Here is a short list (by no means complete) of the aspects that were important to me. I have divided them into two categories: team member skills and team member collaboration.
1. Team member skills
- Engineers must have an understanding of the technology that is used to create the product.
- Engineers should be interested in the type of problems they have to solve.
- Engineers should be able to assess the technical merits of several priority initiatives to optimise the cost-benefit ratio and define milestones.
- Engineers need to understand the system they are working with well enough to identify areas requiring maintenance and reduce technical debt so that it doesn’t affect future speed.
- Engineers need to co-operate and communicate well with each other.
2. Team member collaboration
- The team must understand customer desires and therefore be able to prioritise initiatives (with the help of the analyst and product manager).
- Engineers need to be involved in their work to maximise productivity. This usually requires an understanding of the impact of their work, as well as some degree of creative freedom.
- Engineers need to have enough time to focus.
- Engineers need to be aware of the details of what they are doing. They need a challenge and responsibility for the result.
- The team needs to feel the momentum. Frequent value delivery combined with analysing the impact of the team’s work through metrics is a very important aspect of motivation. Impetus is best achieved through iterative project implementation.
- The team must have limited dependency on other parts of the organisation to do their job.
What can the technical manager do to meet these requirements?
- Conduct quality recruitment and selection for the team. Many of the points above require strong individual skills. Team composition is important. A strong team combines engineers from different backgrounds who enjoy working together. This allows the team to take on tasks of varying levels of difficulty.
- Contextualising the work done by the team in relation to the larger product and organisation.
- Defining small volumes of work with measurable results. Keeping volumes small is the best way to achieve your goals.
- Create a work environment with limited distractions.
- Enabling engineers to spend some of their time on work they consider important. This will allow them to eliminate technical debt as well as utilise their creativity in product development.
- Allowing engineers to participate in planning their work and setting milestones, with limited accountability for results.
- Identify and address the team’s dependencies on the rest of the organisation.
Can the process help with that?
Maybe. But it can only fulfil a fraction of the requirements for a great team and from my experience, it rarely ever leads to success.
I often see teams implement formal Scrum, combining it with multi-month projects in a cascading methodology. This results in a lot of overhead for sprint planning, estimation, retrospectives, but provides no impetus for an iterative approach to development and typically does not result in a predictable schedule as even the best engineers are bad at estimating huge projects. The process also leaves little room for creativity as teams scroll through predefined stories and tasks from sprint to sprint.
But the main problem lies not in the implementation of a particular process, but in the fact that many teams focus too much on the process, neglecting the more important areas necessary to build a great team.
Conclusion
I have tried not to make this post too long. Specific recommendations on how to manage a team could fill more than one bookshelf. The purpose of this post is to remind everyone working in agile teams what is really important for debugging engineers, and to look at the aspects that are really important for building a successful team.
A process should be implemented if it can meet all the requirements listed in this article. But the focus should still be on recruiting great people, building momentum, getting them to work together, engaging and motivating everyone in the team - the process will not do the job.