Successful teams are bound by themes

One thing I notice a lot about software delivery teams in this "post-understanding of agile" world is the rather weird adherence to bunches of words and cargo-culting that goes on with running them. The following advice assumes that you have some form of work prioritisation, and that you have some time-boxing of that work for reflection purposes, and potentially that time-boxing is also used as a convenient means to have releasable working software. It doesn't require that you're doing any particular flavour of "agile", but it almost certainly applies to all the current ways that I see companies fall over themselves and fail at delivering software. In this article, I'm going to call this time-box a "sprint", but feel free to consider any form of time-boxing as part of it - it is the same.

There's so many articles I can write (and teach) about this, but probably the biggest one for me is what others call "sprint goals".

Firstly, where does this concept come from? It comes from Scrum, and while they use the term "sprint goal", they're pretty clear there should only be 1, which makes the intent a lot closer to what I'm going to talk about, so while many people are negative toward Scrum, I'm not sure we can point the finger at them.

What do I see? I see a team of 6-10 people having "4-7 sprint goals". I see "sprint goals" that are "complete feature X".

What do I see in retrospectives? (if the teams even do them) I see "I felt disconnected". "I didn't know what the other team members were doing". "I didn't get my feature done by the end of the sprint". "We had big merge conflicts because everybody was trying to finish". "We found a lot of defects in code written at the end of the sprint"

Sound familiar? It should do, I've worked in your organisations before, and I've seen this. I've got friends working in your organisations, and they tell me this.

So, what do companies do then? They look at what they're doing and double down on "goals", because clearly, in the 4-7 sprint goals that wasn't enough goals, and we might add in some "team goals" and some "division goals" and makes sure those goals align with the "company goals". What do I do then? Well, I normally cry, go home and hug my children because I feel all is lost. No wait, there's something we CAN do about this.

Introducing "themes".

What is a "theme" - well, instead of the teams sprint alignment being some "output", we should reverse the thinking and make the sprint alignment around our "input". Instead of choosing on a per sprint the "features we're going to build this sprint" we choose "the area of functionality that everybody is working in".

Now, instead of Gabby working on the bug fixes for login, and James working on the new features for reporting and George working on investigating a new database upgrade etc, we have a theme for "the reporting system".

Every activity in that sprint, by the entire team is now aligned to working on the same area, with the same conversations, with the cohesion that comes from a team all thinking about the one focus area.

When I suggest this, I'm often met with incredulity "BUT JON, THAT WILL NOT WORK HERE, BECAUSE..." (which is, the story of my career for what it's worth) and here's the neat thing about working in themes, it helps highlight how ineffective the delivery team is, by fixing up the important pre-conditions.

1. "we don't have enough work for the sprint in reporting". Dare I say, that's complete bullshit. What a much clearer description is "we haven't done enough thinking about the overall work that needs to create a successful outcome, and we're scratching around each sprint to pack a bunch of random tasks to keep people busy". I would suggest that to resolve this you spend far more time thinking about what work is required to complete the objective, like the ACTUAL goals of the work you're doing.

2. "we have too much work for the sprint in reporting". Well, you don't have to change your theme each sprint. Just have a theme for 2, or 3, or 4 - whatever makes sense.

3. "we don't have enough features in reporting". This is similar to 1, but also is the cause of a lot of the technical neglect in systems. I'm 100% sure there's enough work in updating documentation, cleaning your CI pipelines, adding more tests, deleting tests, updating databases, updating 3rd party libraries, finding and fixing defects in "reporting" for the team to be working.

4. "if we don't have goals for the sprint, nobody will know what to do". Ummm, what? So, you're telling me that your sprint planning, your technical vision and direction, your team huddles and your senior engineers are completely ineffective, and that maybe that's the problem, and not a "lack of sprint goals".

And now, the number 1 reason why teams struggle with delivering effectively:

The customer has prioritised this feature/card to be delivered this sprint

My only real response to this is "your organisation needs to stop doing that, because that's not how it's meant to work".

In short, the common implementation of "sprint goals" is a MASSIVE anti-pattern which is actively hurting your teams ability to deliver, hurting your team morale via a lack of cohesion and significantly degrading the quality of your codebase and deliverables. Move to "sprint themes" and reap the benefits.