Responsibilities & Risk in an Agile Team

4 minutes

Giving Your Key Decision Makers Advice not Anxiety

It’s a common belief that working in an agile way means you can deliver things faster.  Sometimes you can, but it’s an unreliable benefit. One element of agile that is reliable is that agile can give companies a more accurate picture of the development landscape as they are building the product.

This is because working in an agile way should surface problems faster than more traditional methods. The benefit this gives you is that by finding them as early as possible we can address them and fix them early too.

What I want to write about here is how, in some agile teams, well-meaning team members can accidentally hamper this work. They try hard to do the right thing, yet make things just a little bit worse.

Here is a scenario:

We have a series of stories to do. The work includes some good refactoring of horrible gnarly code from the dawn of time.

While refactoring should show no change of behaviour, it impacts a vast swathe of the system.  Unfortunately, we have few tests here (automated or unit) covering the code. Also, our customers have some urgent requirements that need these changes and they need to have them by a deadline.

The team charged with the work understand this context and sympathise with the product owner. They make every effort to be as efficient with their testing and their development work as they can. They make pragmatic decisions to help deliver to the deadlines, and they usually get away with it.

Occasionally they don’t get away with it and something that they thought unlikely to happen, or low risk, occurs. Senior Managers and Directors see customers getting a poor experience and ask “how did this happen?  Lets understand it and make sure we don’t have this happen again.”

We might do a 5-whys or similar process to understand what happened, and we learn from the conclusions of the 5 whys.  What often happens is that the root cause of the problem is not understood properly or explored fully. It is a pattern I have seen repeated in many variations particularly by teams with a good level of experience.

The team are forgetting to be open and honest, although they are doing so with all the best intentions.

Here’s how it goes:

1) The strategists for your company (perhaps a Director or Product Owner) commit to delivering something for a customer, by a deadline. (Remember, your customers may not all work in an agile way, or may have other constraints that make a deadline important to them)

2) This work and its associated deadline gets to the team as part of the prioritised backlog – it is one of many similar pieces of work.

3) The team break the work up into stories, and estimate their complexity.  Only in this case there’s a deadline.

The team understand there is a lot more of the same type of work in the backlog. Similar work, with similar deadlines. Having challenged their product owner, who confirms there is no wriggle room at all, the team make some decisions:

  • We know that we can’t get all this work done in time for the deadline
  • So that we can finish by the deadline we can do the coding, but then only test the paths that are most critical or we believe will cause us a problem.
  • We hope other people using the system later in the delivery pipeline will use it differently. This will then broaden our test coverage, spotting anything we broke.
  • If we do break something, we can fix it quickly.

4) The team then give an estimate for the story work through the lens of these decisions.

5) The Product Owner ensures that everyone, not just the team, knows there is a lot of work to do, and the delivery deadline is tight.

6) The dice roll and the software is coded, tested and deployed.

What has happened is the people hired to take the big risks and big decisions in a company have no idea of the risk the team took for them. They only know that the team has said it is a tight deadline and that they might not make it.

The Company Strategists base all their future decisions on this incomplete information.

Now, whenever the team miss one of these deadlines or the customer has problems with the product, they trust the team a little less.

The team feel aggrieved as they are working hard doing their absolute best to deliver an impossible job.

The issue is that the Company Strategists & Product Owners don’t know it is an impossible job, because the team never let them see that.

The team stopped the Company Strategists choosing for themselves whether the risks were acceptable. They might have decided to take the risk of cutting the testing. They might have been able to talk to the customers and extend the deadlines to ensure better quality. Instead, the team have assumed the risk assessment & decision-making role.

In their enthusiasm to do a great job they have forgotten a key pillar of agile working: open and honest communication.

The Do-Over

If we re-run the scenario, this is how it could go better:

The team go through steps 1) & 2) as above, they get work with deadlines that the product owner prioritises. When they get to step 3) they break down the stories in the same way, but the decisions the team make here are different:

  • We can’t get all this work done in time for the deadline
  • If we do the coding and the testing it is likely to take this (X) long.
  • If we deliver the coding and test until the deadline then these are the things that won’t have been tested by that time.
  • We should tell our product owner both these possible pathways and allow him to make an informed choice.

This means the product owner can then share this open and honest information with the Company Strategists. Now they are able to make a properly informed choice based on good, solid information.

Being part of an empowered team does not mean you are empowered to take risks on behalf of your Company Strategists. Instead, it means you are responsible for ensuring they have all the information they need to make the right call.