How to identify when agile isn’t working for you (and what to do about it)

Dilbert Does Agile
Dilbert Does Agile

I’ve now had the pleasure of working with five different kinds of agile in different companies with different teams and different cultures.

It’s hard to make an objective assessment of a methodology’s impact when you’re using it and doing your darnedest to make it work. However being critical of ‘normal’ practice is a default for me. And I have reason to suspect that teams use agile to paper over the cracks of poor leadership, bad practice, and poor discipline.

During this time working with agile teams I’ve identified a few areas where you can quickly tell if things aren’t working, and what you can do to turn things around.

VITAL SIGNS THINGS AREN’T WORKING

1. It’s hard to tell if the team is delivering measurable business value

Agile teams use a lot (I mean A LOT) of internal KPIs and metrics. Burndown, sprint velocity, story points. To the uninitiated these words mean nothing, and nor should they.

If the team appears to be busy and there’s code being tested and put into production, but commercially there’s no change in performance, you have a problem.

2. The team don’t know why they’re delivering what they’re delivering

It’s easy to tell a workaday agile team full of developers, business analysts, and scrum masters. There’s usually plenty of focus on stand-ups, tickets, progress, and blockers. But amongst all the ‘busy work’ that’s being done to get code written, it’s easy for people to forget why the team exists.  As soon as that happens, the team isn’t in a good position to challenge priorities or find faster ways to deliver more value.

If you ask one of your agile team why they’re doing what they’re doing, and the answer doesn’t resonate with your overall strategy, then you have a problem.

3. Product Managers talk about the volume of work delivered

A Product Manager’s primary responsibility is to deliver business value – and importantly, to role model the behaviours that come with this responsibility to the team. There’s any number of ways that a PM can impact on this, whether it’s in her roadmap, her decision making, the way she runs meetings, or her approach to prioritisation.

When Product Managers stray away from talking about the value their product has delivered and into the volume of output from the team, then you have a problem.

4. In the rush to deliver, quality gets neglected

The good thing about software is that objective quality is easily measured. Software either works or it doesn’t. However, the bad thing about software is that everyone has an opinion about how it works.

The true test of how well software works is when it’s put to its intended use. Users and customers are the best judges of quality. If users and customers aren’t adopting the product, they’re getting errors or bugs, or they’re struggling to use it and it’s showing in your commercial KPIs – then you have a problem.

5. The target design never sees the light of day

‘Agile-istas’ (those who promote agile above everything else) promise that the methodology’s emphasis on breaking things down into smaller and smaller chunks and making requirements negotiable means that value gets delivered sooner. On the whole I buy that philosophy. But in my experience, this can give the team the power to dodge tackling tougher challenges.

The emphasis on speed of delivery focusses the team on what can be done now, rather than on how the solution ought to work for users, and why. Sometimes there’s value in a really great experience rather than a ‘Minimum Viable’ experience. The hard work of the design team to research and construct the best user experience is left gathering dust on the shelf. I’ve seen developers losing interest in the design because they’re too busy delivering story points.

When the design you’re shown is way off what ends up being delivered, you have a problem.

WHAT TO DO TO TURN IT AROUND

1. Measure what matters, with clarity and ownership

Turn those internally-facing agile KPIs into meaningful metrics that actually impact on your business. Drill down to find measures that the agile team can have a direct impact on, rather than top level KPIs that are dependant on any number of other variables that are outside of the team’s control.

The more clarity there is over how the agile team can impact on the measures, the more ownership you will find over moving them in the right direction.

Make visible measurement part of the delivery too, so that the team gets immediate feedback on their impact.

2. Take a sprint or two to define ‘quality’ as a team commitment

Too quickly agile teams will point to passed test criteria as their sole measure of quality. This delivers a product that works (important) but leaves plenty of room for short cuts and low-balling.

Spend some time with the team establishing the quality criteria you all want to aspire to. Use many lenses – technical, commercial, brand and user experience – as ways to provide clarity. Write these up as quality principles that you all as a team commit to delivering.

No-one comes to work to do a bad job. Specifying the quality you want to deliver makes everyone feel they’re on a team that wants to work together to do something special.

Be careful to reflect this commitment even when under pressure to deliver more. If you’re leading the team and your decision making overlooks the agreed principles, you’ll quickly lose everyone’s confidence.

3. Make senior people accountable for behaviours and performance

The flip side to delivering quality is accountability. It’s no good for the more senior members of the team to be able to dodge challenges and difficult questions when what’s being delivered doesn’t hit the mark. Those running the team must ensure the difficult conversations are had with poor performers way before they impact on the team’s overall delivery.

Acting on disruptive behaviours and below-par individual performance is a positive for the team – it’s usually really obvious to everyone when someone’s not pulling their weight.

4. Delivery from the outset, not just when the sprint starts

A common disconnect in agile is between user experience and development disciplines, especially when larger changes are being made.

Prevent this by making sure the team work together from the start. Developers should be as much part of the design process and defining the problem to be solved as designers should be part of delivery. Continuous input and ownership of the delivery throughout the process must be the norm to prevent the waste of unfeasible or overly complex approaches and solutions. And it builds common understanding throughout the team.

Similarly, designers must work closely with developers to refine and confirm all the details of the design as it becomes real.

Use the team’s commitment to quality to ensure that quality and challenge happens at all points. The Product Owner, Design lead and Tech lead must make sure this happens.

5. Alignment of incentives

In 2017, delivering quality digital products is still hard work. And in 2017 there are a myriad of opportunities for talented people to work hard. It’s important that the incentive for your team to work hard is reflected in how they are rewarded.

The agile approach is very focussed on team working, but companies still tend to reward individual performance. Typically, it’s the managers who get the plaudits, higher salaries, bonuses and perks when things work well.

Consider how you could meaningfully incentivise good overall team performance as well as individual contribution. And by ‘meaningfully’ I don’t just mean financially!

 

 

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s