A year ago, during the startup of a new project, I wrote a series about scrum and the context around a scrum project. The project is now can finished and it’s time for a retrospective, evaluating what worked well and what didn’t.
The major impression is that the project and the way we used scrum was a huge success, but of course there are areas that didn’t work so well. It’s always nice to look at the success stories, so let’s start with them.
I started the series by pointing out that scrum’s view of the world is very developer centric, focusing on making the developers as efficient as possible. That is a very different perspective from traditional project management that tends to have a deeply rooted top down perspective. In the project we kept scrum focused on the development team, but also acknowledged that there are important areas in a project that scrum doesn’t account for.
I’m definitely not saying that scrum is wrong, my experience is that scrum improves the success rate for projects considerably. But as good as scrum is, it isn’t perfect nor a complete project model. By addressing the parts of the project that are outside of scrum, the success rate is even more improved.
When starting up a scrum project, I often use a sprint 0 to get started. The purpose of sprint 0 is to get all the prerequisites for the first sprint planning in place.
The need for a sprint 0 probably varies across different businesses. I’m working as a consultant which means that at the start of the project the team usually doesn’t know each other well, the customer doesn’t know the team, the business analyst doesn’t know the business and the team doesn’t know the inherited legacy code (if there is inherited code).
Every single one of those issues is an impediment for a successful sprint planning. Together they make an effective sprint planning impossible. The purpose of a sprint 0 is to overcome these issues. The purpose of a sprint 0 is not to work in an unstructured manner and postpone the planning.
Sprint 0 Goals and Planning
As every sprint, sprint 0 should be planned and have a sprint goal. In my opinion, there is only one valid sprint goal to set for sprint 0:
Sprint 0 Goal: Make proper planning of sprint 1 possible.
Fortunately only two things are required to plan a sprint: a prioritized backlog and enough knowledge of the domain, technical aspects etc to make relevant time estimates.
Unfortunately those two things can be really hard to get. Until you have them, you’re running sprint 0.
A project saboteur is a person doing his/her best to sink a project and cause it to fail through a variety of methods. Effective counter sabotage to identify and deal with project saboteurs as early as possible is a key success factor to any large project because there will always be a saboteur somewhere…
Know Your Enemy
To successfully counter any sabotage attempts you need to know your enemy. You definitely have to know what behaviour you want to counter. If you can find out the motivational factors for the sabotage it is even better. Often it is not possible to defer counter sabotage until the reasons for the sabotage are identified. In that case it is best to start acting against the destructive behaviour, watching the saboteur’s reactions to find out who he/she really is.
Counter Sabotage Methods
There are a number of basic methods for project counter sabotage. Most of them are good habits for any project, so go ahead and use them anyway. If no saboteur shows up in the project, practicing these habits has probably been good for the project anyways.
- Documentation, Documentation and Documentation.
- Meeting Discipline.
- Take Conflicts when Needed.
- Avoid Conflicts.
- Use Humbleness Wisely.
- Take the Saboteur Hostage in the Project.
While the methods of project saboteurs are similar, any project in the wild may encounter very different kinds of saboteurs. The Project Saboteur Taxonomy is an attempt to shed some light on the saboteurs in the wild.
Saboteur Types
This taxonomy contains five types. I am sure that there are plenty other types – please feel free to add more as comments!
- The Insecure Person
- The Lazy Worker
- The Personal Enemy
- The Evil Sceptic
- The Enlightened Sceptic
There are many ways to sabotage a project. Recognizing them is the first crucial step to counter them. In this brief handbook I will present a number of ways of sabotage that I have encountered in various projects. This post is the saboteur’s handbook. The countermeasures will be saved for another post.
Enough of introduction. It’s time to enter the dark mind of a project saboteur…
The Project Saboteur’s Handbook
The key success factor to sabotage a project is to draw attention and drain energy from those areas that are important to make the project successful. Any behaviour that draws the attention away from important work or drains energy from the project is allowed. Use your imagination and creativity to make sure that you never miss an opportunity drag the project one step closer to failure.
Strategy Overview
To give some inspiration on how to make a project fail I’ll present some strategies in this handbook.
- Focus on border issues to prove your own “knowledge”.
- Ask questions that you don’t understand the answer to. Keep ask for clarification.
- Avoid documentation.
- Avoid clear decisions.
- Ignore tasks assigned to you. Extra efficient if combined with the two points above.
- Focus on other’s few shortcomings.
- Keep meetings unfocused and avoid agendas.
