Don't do Agile, be agile

Over the last ~8 years in my career, I've worked on teams who do Agile, and who are actually agile.

Although there has been some overlap, I've found that for the most part, teams who are actually trying hard to follow the frameworks or methodologies have ended up being less effective at shipping at pace, compared to their counterparts who are a little more "loosey goosey".

I thought it would be good to write down my thoughts about this, given I think through writing, and I've recently been having this conversation at work, as we work to rethink how the team works.

Who cares what I have to say?

I've worked across a mix of teams, who've used the Scaled Agile Framework (SAFe), a pared-down version of Scrum, pure Kanban, and some ungodly unstructured horrors that left a ringing in my ears 🫣

In that time, I've also been able to enact changes to make it so our team ends up delivering much better, as an IC in the team, (including as the Tech Lead) such as:

• Measuring metrics around stories committed to, delivered, and uncommitted stories brought in, which led to much more reproducible and consistent sprint delivery, with a "facts, not feelings" approach of understanding what was actually viable
• Introducing a "Sprint Lead" role, which allowed moving ownership of team delivery into something that each member of the team owned, rotating each sprint, and providing a means to grow empathy and understanding about how the team delivers
• Improved the refinement process in our team, reducing our Sprint Planning sessions from ~3 hours of painful refinement + planning to ~30 minutes of "what's top of the backlog, cool let's do them then"
• Introduced insights into areas the team felt were causing delays, such as digging into how long it takes for asynchronous code review or using a Squad Healthcheck to understand sentiment of the team
• Building a team with a very high net promoter score

I will of course say that there were others involved in these changes, but for the most part these were all either pitched or primarily pushed by me, and so I'm pretty happy feeling comfortable taking credit for them, and am very proud of some of the changes I've enacted.

A framework can be a good starting point

I will start off by saying that if you're starting a fresh team, or are in an organisation where there's not really anything in place, trying a popular and known framework can be a good starting point.

Similar to choosing Spring Boot or Rails for your tech stack so engineers who are experienced with it can get onboarded and productive more easily, by aligning with a known and popular Agile framework you'll be able to get more support from external resources and teams, as well as onboard new folks more easily.

As someone Neurodiverse, I generally lean more towards "explicit over implicit", as well as enjoying rules to follow, so it can work well to make sure that I've got more clear guardrails around what needs to be done, but also not to the point that it's overly strict.

The trouble with starting with a framework is that it can lead to you getting yourself into more process than maybe you want as a new team.

I'd generally recommend starting with something more minimal like Kanban, where there's some guardrails but not a hugely prescriptive set of steps and processes to follow.

Scrum requires more investment than you're probably doing

I've found that to do Scrum really well, you need to really invest in it. Not just a case of getting everyone on the team on board with the methodology and relevant ceremonies, and staying true to the framework, but also making sure that you have your feedback loops with stakeholders in place.

If you're a team who's not done it before, it can take a bit of work before you're "actually" doing Scrum.

Sprint Reviews

For instance, I've found that while working on teams doing Scrum, our Retro would generally end up being a fairly moan-y session about how there were some blockers that stopped delivery, or that we thought there were some issues, and often not really focus on the actions we could take as a team to overcome these.

Instead of just having a Retro, you should also have a Sprint Review, where you dig into these questions, and get "facts, not feelings" i.e.:

• Did we hit our goals?
  • This is more important than getting all the delivery over-the-line - if we've delivered the value we set out to do, that's a win
  • Do our stakeholders (who should be in the meeting, too!) agree?
• How many stories did we complete? Did we achieve everything we'd committed to doing?
• What did our burndown look like?
  • There are usually interesting things we can learn from this, like "why did nothing get closed off until day 5" or "why did we finish 80% of the stories in the first few days of the sprint, then didn't complete the remaining work", or even "why did we decide to bring in more work, but then not complete any of it or the work we'd committed to?"
• Were there any unexpected scope change?
  • I.e. incidents, work we had to bring in as part of senior stakeholder requests
• What was carried over from the previous sprint?
  • And did we actually finish it?
• Did we allocate the right % of time per person per sprint?
• Did our story point estimate align with how complex the work actually was?
  • Which can then feed back into the refinement sessions

This then means that you've talked about the overall delivery, understood more about why you did (not) hit your goals, any key blockers that came out of it, which leaves the retro to discuss opportunities as a team to learn from this. For instance, how could you ensure the blocker doesn't happen again? What awesome work happened this sprint that you really want to shout out? What team ceremonies or processes do you think could be tweaked? Or was there an action from a previous retro that we haven't yet actioned, but that could have helped alleviate issues in this sprint?

I've found that making sure the Review and Retro are two separate meetings, run one-after-another, allows focussing the intent of each meeting, and is good expectation setting for the team.

Something I'd also heavily recommend is to empower each team member to take charge of the Review, so they can be empowered to better understand how the Review works, what sort of metrics are useful, and have an opportunity to look for any insights they can bring to the conversation separate to the usual discussions. By spreading this work around the team, we ensure that this isn't seen as "oh that's (our manager)'s job", but is a part of being an engaged member of the team, and I recommend doing this alongside all other ceremonies that are run by one person per sprint.

The trouble is that setting yourself up to be able to answer the questions in the Review is that it requires a bit of investment. You can't - or at least, shouldn't - have the person running the Review just rocking up to the meeting and running it off-the-cuff.

Although some of these things can be improvised, and some of the data automated, to run a really good Review, having some up-front prep (15-30 mins) can really make a difference to the quality of the meeting, and make sure you're respecting everyone's time and providing the most focussed, valuable opportunity to review your sprint's delivery.

Demos/story acceptance

There have been very few teams where we've either run a regular demo across teams with involvement from our stakeholders, or that we've done "story acceptance" where we've actually demo'd the story to our Product Owner. (You do have a Product Owner, right?)

This is somewhat due to the fact that I've largely been on backend/API teams, but that still doesn't mean we should be showing what we're doing in a way that isn't just "when I send this curl request, then I get back this bit of JSON".

It's a really important part of the process to ensure you're delivering the right solutions and making sure you're getting the regular feedback loop from your stakeholders!

Refinement

One key part of the agile process is story refinement, or at least "making sure we know what we're trying to achieve", regardless of whether it's a "User Story" or just a "we need to do this because ...".

This can take different forms, especially depending on how your team(s) are structured, whether you want to involve stakeholders in the ability to refine the work, and whether this is something being led by your Product Owners or not.

Trying to distill the ask into something that is both not-as-technical-human readable as well as technical-human readable can be difficult, and as I mentioned in 89 things I know about Git commits, "writing is a skill", and although we wish everyone has that skill right now, we're not there yet.

I find it very useful to understand how something fits into the wider goals, and that context is really important to give everyone, regardless of how close they are to the work. Although I pride myself on the way I write tickets and the level of context setting, there's always more I can be doing to improve, or in some cases to add a TL;DR to my more verbose writeups 🫣

That being said, I would absolutely prefer to be overly verbose than have one-liner ticket titles which explain what, but not why.

When I joined Deliveroo, my team had cases of mostly one-liner ticket titles and I was not a fan. But you know what? They were shipping a lot of stuff, getting valuable feedback, and everyone in the team was very highly engaged and aligned with the goal we had been working towards, and it was super clear what each ticket was.

In this case, I agree that spending tonnes of time on refinement wasn't providing the value.

There is of course a balance to be had, and like Git commits, a story gets read more times than it is written, and won't always be someone with the same level of context as you.

Learn what works for you

So with that in mind, you should see what actually works for you.

Some teams will thrive under the rigid structure that Scrum gives them, and others will feel shackled. It could even be that a change to the team (i.e. people joining/leaving, moving onto a new project, or only focussing on BAU work) leads to your existing methodology not working, and so you need to adapt.

Teams are not islands

However, you're also not an island. You're delivering solutions in the context of other teams in your organisation, and should make sure that you're not working completely in isolation, at odds with your colleagues.

For instance, if you're working in an organisation that only delivers customer-facing changes in quarterly increments, you working very hard to do very fast paced delivery of change (i.e. using Kanban) arguably leads to wasted effort, as the changes aren't reaching customers for months.

Additionally, if you're not following the same ways of working that the organisation at large works, make sure that you're either providing a translation layer (maybe via your manager) to the rest of the organisation, so they can still see how you're progressing.

A friend of mine works at a company where they're meant to work in Scrum, but it doesn't really make sense.

Their team doesn't really follow Scrum as it's intended - they regularly have carry-over, don't really work out what's achievable in a sprint, and instead just bring in tickets as-and-when they need to - but say they are "technically Scrum" so they can fit into the organisation's model of how to work.

That being said, this team delivers! They don't spend too much time on the Scrum ceremonies, and instead focus on getting shit done, and it shows.

"What's a stakeholder?"

If you're not engaging with your stakeholders early, you're missing out on a lot of opportunities to make sure you're on track and delivering the right solutions.

Instead of discussing with them at the end of the sprint, when it may be too late, you should instead be catching up with them, i.e. each day at standup.

But standups need to be run well to make this work. I've noticed that I generally find it hard in meetings that don't feel to be run well, but it's especially noticeable in a standup where it can be quite an "expensive meeting", with all the team and relevant stakeholders available.

As mentioned in a post of mine from 2018, it's important to think about how others may respond to jargon you use, or deep technical details that may not be relevant in the conversation. Lead with empathy, and you'll hopefully land on something inclusive and unalienating.

But as I've learned in the last couple of years, an effective standup takes the opportunity to focus on "the board", high-level updates, check the status of goals, and then any follow-up, in-depth conversations can be when everyone else can leave and you can dig into details.

This keeps the top of the meeting tight and focussed, and then getting into the weeds, or trying to talk about why a given piece of Go code isn't working so well can be followed up on.

But to do this, it requires that your sprint lead / scrum master needs to be good at keeping the conversations on-topic and facilitating the meeting well, which is a skill to hone.

(Aside: one thing I love about my team at Elastic is that we're globally distributed, so no synchronous standup! Instead we post updates in a GitHub Discussion throughout our days, allowing us to add as much detail as we need, and allowing following up with edits/new updates through the day)

People over process

One of the Agile manifesto's key principles is:

Individuals and interactions over processes and tools

So please listen to your teams.

If they're claiming that the process is getting in the way, or cursing that "software was not meant to be sisyphean", see what you can do to remove or relax it, as you should be focussing on making sure it's a sustainable process for the team.

Be agile with how you run your teams

But at the end of the day, learn to grow, experiment and see how things work.

I'll regularly recommend the talk that Tom Hoyland did at DevOpsDays London 2019: "Building and Growing an Agile Team" which I find to be a really great insight into how measuring and understanding the way your team works can lead to some really interesting insights about working towards a truly high performing team.

I recommend you not tying yourselves too strongly to any Agile framework, and instead work out what works for your team. If you're able to deliver as a team, while making sure the wider organisation can depend on your updates being fed to them in a way they understand, how you do it doesn't really - and honestly shouldn't - matter.

Don't do Agile, be agile.