the right reasons to start agile swarm development

Question

We are a fairly new team of 5 devs working on an existing code base to make MVP somewhere in Q2 2020. We do not deliver to production yet but we do demo to stakeholders on our progress. We try to work as agile as possible but because we are new (1 dev 8 months, 1 dev 4 months (myself), 2 devs 3 months and one dev 1 month) progress is not fast enough to out liking, and we find many things to refactor. But we do deliver stories for the demo.

We work using the Agile Scrum process but many stories were refined before my time. The issue now is that we do not finish all stories we commit to. But I myself can make progress now because I know more about the system.

Today one of the developers stated we could use swarm development to fix the issue that we do not deliver all stories. The idea is that we all work on one story to see if we can deliver faster.

But, I see a lot of practical problems.

1. some developers start early and some developers start later (diff can be three hours)
2. two of the five devs work only part time (2 or 3 days a week)
3. Not every dev is at the same experience level

I think that we are solving a simple problem (not enough technical analysis when refining) with the wrong solution (swarm development). Also the velocity will go up once all devs are familiar with the codebase).

I read a lot of articles where Swarm Development is brought as the (next) Holy Grail for delivering software. But I have my doubts whether this is the solution here. We are not aiming for business value asap to Production. It is OK if some stories are brought over to the next sprint, as long as we make progress.

So the question here is. When to do swarm development? What are the preconditions to do this? What are the pitfalls? What are the recommendations?

Answer 1

It sounds like when you say Swarm Development you are referring to Mob Programming. However, any impact this would have on delivering your work at the end of the sprint would be a secondary effect. There are a number of factors that can impact this, but they are almost all flow issues. That is, the cycle time from starting work (in programming this first work is usually technical analysis) to completing the work is long - at least longer than a sprint.

We know from lean and, in particular, Little's law, that cycle time is directly impacted by work in progress. Therefor, the first thing most teams do in order to complete items in the sprint is focus, as a team, on one or two items at a time, get them to complete, then move to the next. In this regard, Mob Programming would reduce your WIP which would, in turn reduce your cycle time.

Of course, other flow problems may mean that you still don't finish in time. For example, each backlog item may have too much functionality crammed into it. In lean terms, this is a batch size problem and in addition to the extra time it takes, a larger concern is it builds in a lot of risk. Alternately, you may have long wait times either in the team or outside of it. In most long processes, you find that waiting is the biggest contributor to cycle time.

I don't think your coworker is wrong - swarming can absolutely improve the problem, but it isn't really getting to the root of it. In your context, if you want to dabble with it, I've worked with teams that pick one day per sprint to get everyone in a room and swarm on an item. For them, they found it was the most productive day of the sprint, so now they do it as often as possible. Your results may be the same or may differ.

Answer 2

Sometimes progress can be held back due to developers becomes fixed in their mindset or approach. 'Owning' specific chunks of code or being attached to specific technologies.

Swam development can help a team get past this by opening up the problem to all the developers and prioritising task completion.

If you are a non technical manager facing a technical blockage you don't understand, you might call for a swam approach in the hopes that some of the other developers will find a work around which the original dev wouldn't accept.

Or of course there are tasks which are just dull and time consuming. Having everyone jump on them and removing the excuse of other tasks can parallelise the problem task and get it out of the way.

The pitfall is that too many cooks spoil the broth. If the task is just 'normal programming' then you are going to slow it down while everyone sticks their oar in and argues about solutions.

However, you say you are using Scrum. A key part of scrum is being willing to change the processes and try new things. If the team thinks that swarming might help, then you should try it, measure the change in velocity (if any) and judge the practice accordingly.

Answer 3

The issue now is that we do not finish all stories we commit to.

This is the problem your team is trying to solve. A coworker mentions swarming as a solution. For an inexperienced development team I would recommend making stories small — excruciatingly small. Putting a text field on screen with the right label text could be one story. Adding data validations could be a second story. Making it accessible to screen readers could be a third story.

A team I worked with was faced with the same situation. I struggled for 2 years of moving stories to new sprints before I just gave up and made stories extremely small.

It sounds like the stories are too big given the team's experience. I frequently use Example Mapping sessions to give the team additional information on how to break a story down. Get creative. As long as your end users can verify the functionality, it's a story. It doesn't necessarily need to be every piece of functionality they want.

Oversized stories are not a good reason to start "swarming". First try reducing the scope of the stories. Swarming is a better fit for getting appropriately sized stories done faster, but is not a good solution for stories that are too big.