Oftentimes I have been on waterfall-ish projects* where during the design phase, things were clearly not progressing as they should. Even with an aggressive deploy deadline, our project was only creeping along and critical resource needs were being ignored. This was escalated to the executive sponsors and since we had no slack in our project timeline, it stood that we would not hit our deploy date. The sponsors listened, but at the end of the day there was no action.
This scenario is certainly not unique to me and I'm sure a lot of us have been on projects like this. So why does this happen? A possible reason is because we have not built into our project teams (this includes the executive sponsors) the ability to fail. We often talk about success, growing technical skills, fostering teamwork etc, but we rarely talk about allowing ourselves to fail.
In the scrum framework, failure is a distinct possibility in every 2, 3 or 4 week sprint. At the end of the sprint, the Product Owner looks at what has been accomplished and determines if it passes or fails to meet his or her criteria (think gladiator-style). But what good does allowing your team to fail a sprint actually do? Let's go back to my example to illustrate two benefits of allowing a team to fail during a sprint.
During our design phase, we were deficient in resources for our team. While we raised this issue to the executive sponsors, no significant actions were taken. Why? Because design artifacts and tasks are always hard to use a progress indicators. It's just a fact of software development and because of it we couldn't communicate the urgency of our situation to the executives.
Scrum circumvents this dilemma by having a potentially shippable increment (a ‘slice' of production-worthy functionality) produced and demonstrated in person at the end of every sprint. The design, build, and testing all occur in within every sprint to support the ‘slice' of product. No one needs to review a detailed design document to see if you're on track, instead progress is determined via a demonstration of the end product. If that ‘slice' is not delivered and demonstrated, the sprint could (and should) be deemed as a failure from the Product Owner. This is an unambiguous distinction happening every few weeks. In contrast, failure for a waterfall project often means not hitting deployment dates – this is the worst possible time for learning of project issues.
Being able discuss our resource needs with the executive sponsors in terms of passing or failing sprints would have illuminated, in a timely and compelling fashion, the harm to our project caused by insufficient resources.
As counterintuitive as it may sound, allowing teams to fail can actually galvanize them into action. The ultimate disincentive to work is to think that nobody cares. In scrum, every single sprint is an affirmation that the Product Owner cares. He or she demands results – and that's a good thing. The sprint review illustrates for every team member that there is no room to slip through the cracks. For correctly-estimated sprints, if one person does not contribute, the entire sprint is in jeopardy.
Moreover, with failure as a distinct possible outcome, success is so much more meaningful. Teams in which there is no utterance of ‘failure' often don't have the same respect for success. Without being able to fail, sprint reviews and Product Owner sign offs just become additional administrative meetings. However, the team that has both succeed and failed will strive that much harder to ensure that every sprint estimates correctly and delivers the functionality requested from the Product Owner.
Doing software development within the Scrum framework can be difficult. To increase the likelihood of a successful project, make sure that sprints can fail and that the failure is understood and communicated to everyone on the team. Failing early in a project can often guarantee long term success.
PS – For a great article on this notion of failing early, often (and there are many) check out this article from Fast Company.
*I know – no one calls a project ‘waterfall' these days. But let's call a spade a spade here: if you have distinct planning, design, build, test and deploy phases – you're running a waterfall project.