The Unicorn at the Heart of Scrum

The Scrum development methodology was designed to provide a flexible framework, to be used by multi-functional teams to work together to complete all of the tasks that are required to produce a functionally-ready product increment.  Each increment builds on the previous increment to eventually produce a complete solution that meets the customer requirements.  So far, so simple, and, let's be honest, quite enticing.  It's certainly a more dynamic and empowering vision than the "small cog in a big project" feeling that Waterfall provides.


But once you start applying this enticing theory in practise, most companies run up against a fundamental problem.  Scrum is deliberately designed to allow any (or at least most) team members to pick up any task that is Ready.  In this way the "multi-functional team passes the "ball" [sprint backlog tasks] back and forth on the way to the "goal line" [completion of the Sprint]".

The fundamental problem with Scrum is that multi-functional teams don't exist in practise.

Peter Measey, CEO of the agile training and coaching company Radtac, and a man with over 20 years experience of working with agile teams (agile methodologies have been around a lot longer than most people realise) once told me during a training session that he has only ever seen 1 truly multi-functional team. 1. Uno. Less than 2.  And given that no-one else I've ever met has ever seen one at all, it does seem like a truly multi-functional team is something of a unicorn - desirable, unattainable and quite possibly mythical.

I've addressed the question of why there aren't more multi-functional teams in a different post, but in brief, it's mainly because the specialisations that you need to master in each area - e.g. development, testing, documentation - are too varied, too large and too constantly evolving and updating for it to be realistic for most people to master all of them.  So if it's unrealistic to expect a multi-functional team, how does this impact your Scrum implementation?


Well, primarily it means that Water-Scrum-Fall, where jobs are done largely in a linear fashion within a sprint, is a very common implementation of Scrum.  And of course, for us writers, it means that we are at the end of the queue for work.  Testing can't complete until Development completes, and Documentation can't complete until Testing completes (which is something else I'll expand on in a later post).  So the writers sit at the end of the sprint accordion, and if development and testing don't finish in plenty of time then the writers' time to complete their tasks will get squeezed as the accordion closes and the sprint will fail.  Therefore this unicorn feeds directly in to the answers to possibly the most difficult Scrum question for agile writers: Should Documentation be in the Definition of Done?

Because of this unicorn at the heart of the Scrum theory, and to prevent the Water-Scrum-Fall problem that arises from it, it is important to recognise an important and often overlooked truth about Scrum: The power of Scrum doesn't lie in the Scrum team. Instead, the power of Scrum, and its ability to smooth the linear Waterfall-style progression within each sprint, is dependent on the following:

1. The quality and timeliness of the user stories and associated artifacts such as wire frames that are produced by analysts and designers who are working outside of the Scrum team;

2. The provision of proscriptive standards that allow testers and writers to produce skeletons and outlines for consistent testing plans and documentation deliverables, based on the artifacts and information from the ceremonies, before seeing the software.

3. The prioritisation by the Product Owner of UI elements that can be front-loaded in the sprint by development so that testers and writers can see the software as soon as possible.

4. And, most importantly of all, high quality client-company communication and constant feedback by the Product Owner to the scrum team in the form of real-time backlog prioritisation.

If these 4 elements are present then Water-Scrum-Fall can at least be made more Scrum than Waterfall, even if there will always be an element of linear progression in the absence of Scrum's unicorn.