Creating Healthy Tension in Software Dev Teams

One of the most brilliant things about an Agile process is when it works, it really works. You get development teams that produce software that is exceptionally valuable to the business while creating an environment in which development team members are highly engaged. However, more often than not there is an unhealthy level of tension between software development teams and their stakeholders.

This article is for you if you’re asking yourself these things:

Why are they not working on the most important features?

Why does the team over promise and under deliver?

Why are we constantly working on technical things and not on new features?

A common story

I was discussing with a friend who has moved to a new company which is scaling up past the startup phase. As the company grew, the founder became distracted away from product management into business management. The development team is not being given clear direction or face time with the founder and are using this gap in direction to focus on technical “busy” work. The owner is getting frustrated that the development team isn’t building the new features their customers are asking for. The development team is slowly becoming disengaged and not enjoying their work.

This is a common problem repeated in many organisations with slightly different factors depending on whether the company is a startup, scaleup or enterprise.

Enterprises may find that development teams spend a lot of time talking about creating or fixing the framework or resolving for technical debt. You may notice development teams convincing organisations to invest in rewriting parts of their application by swapping out technology which serves very similar purposes (e.g. moving from Angular to React). These rewrites are often sold on the improvement of developer productivity and customer experience.

Changing technology is either a by-product of poor implementation or selection or a strong lack of business requirements. It generally never results in sufficient gains in productivity or customer experience to warrant the investment. If the team caused the poor selection or poor implementation, what’s to stop them making the same mistakes again?

Creating healthy tension

To keep a development team on track, you must actively encourage a healthy level of tension between the stakeholders and the development team. 

On one side, you should have the stakeholders wanting the development team to produce as much as possible. There should be a hunger for new features and the stakeholders should be eager to review the results. There should be celebration when results are achieved. There should be active engagement with the team to support them.

On the other side you should have the development team understanding their progress is closely monitored. Their performance is critical to the organisation's continued success. The results will be reviewed and celebrated. Failure to perform will be questioned, and if there are excellent reasons for under-performance they will be accepted. Continued under performance without due cause will have undesirable consequences.

However, too often development teams are left to their own devices, trusted to just “get on with it” while stakeholders are busy with other tasks resulting in frustration.

Some tips to create healthy tension

Here’s some common approaches that should increase satisfaction and alignment between the stakeholders and the development team based on some of the most common needs.

1. Stakeholders want to keep the development team working on the highest value work.

A backlog of work needs to be created, ideas go into the backlog and are refined into fully formed business focussed requirements. A prioritisation session needs to occur regularly between the development team and the stakeholders to blend technical needs with business value.

2. Stakeholders want the development team to deliver value and the development team needs time to focus and deliver.

Hold a sprint planning meeting where the development team identifies how much work it can do during the sprint. It’s critical this is the development team taking items off the backlog and committing to the plan. The stakeholders should sign off the plan, ensuring it’s work that is the agreed highest priority.

The sprint plan is like a mini contract or promise, the development team says they can deliver if they are left alone to deliver. If the stakeholders avoid changing the plan, they are rewarded with a delivery on time.

3. Stakeholders need to create sufficient engagement within the development team to keep them happy and productive.

Typically the stakeholders are involved in defining work clearly with business focused user stories and acceptance criteria. Sometimes themselves or sometimes through a product owner or business analyst. It’s critical that these user stories clarify the problem and the business requirements (e.g. we want to register new users with their name, company, email address and phone number so we can follow these users up) and without dictating specifics of implementation of the solution (e.g. we need to create a new record in the users table).

Dictating the solution in technical detail is a surefire way to disengage a developer. Failing to provide a developer with clarity around the problem and the business requirements often results in developers filling in the gaps or waiting for further information. The result being solutions which need rework, inefficient development processes and unhappy developers.

The stakeholders and the developers need to come up with a compromise around the timeframe for delivery of new features and resolving for technical debt. Failing to resolve for technical debt could make it frustrating for the development team to continue to deliver. The development team needs to ensure that they aren’t worked to death by having stakeholders over commit them to a schedule they have no influence over.

4. Stakeholders often want to know how long it will take to deliver, to set expectations with clients or other stakeholders who need to plan around the arrival.

Engaging the team in estimating the work is imperative to achieve their buy in. If the team does estimate their work, they are more likely to hold themselves accountable for delivering within their estimates. The stakeholders need to know they can’t change the plan (being the stories or the acceptance criteria) while it’s in progress or without changing the estimates. With sufficient clarity as to the problem and business requirements developers can provide accurate estimates.

As a result development teams can usually achieve a consistent velocity (amount of work delivered per sprint). With a consistent velocity you can predict when work will be delivered. You should be able to predict when work will be delivered, +/-50% on anything further than 6 months out, and +/-20% on anything in a 4-8 week time horizons.

5. Stakeholders want to be sure that things are on track, so we need a way to measure and predict our deliveries.

There should be tooling which shows work remaining VS work completed with a view to both short range (within the sprint) and long range (3-6 months). The development team needs to know their progress to completing the shippable increment will be tracked and monitored and if things aren’t on track then everyone need’s to see it and they need to articulate why it’s not on track.

Sometimes it’s obvious, for example 'new requirements were identified, we’ve had to change work we thought was done because we learnt something new'. Adding more scope items pushes dates out, simplifying or removing scope or impediments brings dates in.

6. The development team needs to regularly present progress to stakeholders in order to stay on track.

There should be a regular set of presentations (a showcase every 2 weeks) where the development team is forced to present their progress with a live demo. This ensures there are opportunities for stakeholders to regularly inspect progress and course correct. The live demo causes the development team to find a way to focus their energy on proving progress to themselves but also to their stakeholders.

If the development team haven’t delivered on their sprint plan, there should be explanations as to why. Where reasonable explanations and consistent performance is observed there should be celebration. Where consistent under-performance is observed there should be corrective actions taken.

7. The stakeholders and the development team should review how they are progressing and identify any areas for improvement.

The stakeholders may receive some ideas from the development team, usually at a retrospective meeting, as to how to help the team go faster. Common examples might be avoiding interruptions when team members have headphones in, providing clearer requirements (e.g. specifying wording for error messages and email content prior to the sprint starting), answering questions faster during sprint or helping the team get any tooling or hardware they might need.

In summary

Establishing a healthy tension between development teams and their stakeholders results in more engaged development teams, better products and more value created. When you setup some rigorous processes in a light weight fashion the stakeholders can have minimal touch points with development teams while ensuring they are getting value and their expectations are managed.

If you think your practices could use a little improvement, we offer independent reviews on your processes along with actionable recommendations. Please do get in touch.