Salami Agile

More than one software development team has encountered the situation when the team want to be more “Agile”, the organization and management might even be asking them to be more “Agile” but, there are still many “requirements” in a big requirements document and the expectation is that all these will be “delivered.”

Ideally I would not set up and Agile development like this. Yes I’d set a few requirements to seed the first iteration but I would take a more goal directed approach. I’ve written about this elsewhere - see Time for Goal Directed Projects.

Basically Goal Directed means: the team have a goal, the team will determine what needs doing (requirements) and do it (implementation) as part of the same project. The team will be staffed with everyone they need to do both sides of the work (BAs, Developers, Testers, etc.) and will be judged by their success on reaching the goal. They will not be judged on how many features they implemented from some big initial set.

But, as I started by saying, some teams do have a shopping list of things they are expected to deliver and they will be judged on how many of those items are delivered and when.

So what do they do?

This is where Salami Agile comes along.

Think of the Big Requirements Document as an uncut piece of Salami. Someone on the team - preferably someone with Business Analysis skills but it could be a developer, project manager, or someone else - needs to slice the requirements into thin pieces of salami (story) for development.

There is no point in slicing the whole salami in one go. That would just turn a big requirements document into a big stack of development stories. The skill lies in determining which bits of the document are ready (ripe) for development, which bits are valuable, and which bits can be delivered independently.

Some slices of salami will need to be thicker than others but thats just the nature of the world. Over time, with more skill at slicing salami it will improve.

Ideally, the pieces of salami are delivered to the customer early, and over time they start to realise they don’t need some parts of the requirements document, some salami can be left unsliced and simply thrown away. Other pieces of salami will be cut and then thrown away. Thats not failure that’s reducing the work and is good.

And some requirements which were not though of can be easily incorporated. To stretch the analogy, you switch from German Salami to Danish Salami and back again if you so choose.

I imagine some readers will recognise this development approach, good. Now we have a name for it: Salami Agile.
(Picture from André Karwath on WikiCommons under Creative Commons Attribution-Share Alike 2.5 Generic license.)