Allan Kelly has held just about every job in the software world, from sys admin to development manager. Today he provides training and coaching to teams in the use of Agile and Lean techniques. He is the author of "Changing Software Development: Learning to become Agile" (2008) and "Business Patterns for Software Developers" (2012) and a frequent conference speaker. Allan is a DZone MVB and is not an employee of DZone and has posted 80 posts at DZone. You can read more from them at their website. View Full User Profile
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.
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.
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.
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.
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.
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.
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.)