There is a tacit understanding that projects using scrum or agile (mostly) succeed while projects with other methodologies are more likely to fail. Scrum failures do occur, but it’s more like “death with a thousand cuts”, and you rarely notice the patient bleeding, that is, until the patient is pronounced dead. There are many places where one can find “success formulas” for scrum/agile. We are instead considering all the things you can do to ensure the failure of a scrum/agile project.
- Do not have a product backlog! Product backlogs provide an execution road map, if they are well planned they can keep your team occupied and productive throughout the development and beyond. When the product backlog is properly aligned to the release plan the team will in due course become your knowledge repository. Do not use scrum language! A shared language makes for a shared understanding, this may lead to (not guaranteed) a success of sorts. Hence, obfuscate, by mixing language from different methodologies, this can be very effective with an immature team lacking the correct scrum experience. A combination of no (or some thing that comes close to zero) backlog and a lack of domain expertise (in the team) means the team can never second guess the backlog. If zero backlog troubles your conscience, create a small number of the “user stories” in such an airy-fairy language that they are all but useless.
- Ensure that the stake holder puts a representative in charge (perhaps as a proxy product manager) who is highly skilled, but who is stuck in a “water fall” time warp, and will insist that nothing should be coded until the design is poured in cement and documented. The frustration amongst the developers becomes quite palpable, as sprints come and go, but, there is little or no coding being done, because the cement is still wet on the design.
- Do not hire an experienced scrum master. Someone with no actual agile project experience would be an ideal choice, better still, someone with no project management experience is even better suited. The rule here is simple, the more important the product/project the less experienced should be the individual. How do you know when you find such an individual? Let the candidate sit crossed legged on the floor and meditate on scrum/agile, if he repeats the incantation “scrum”, “sprint” and “stand-up” with the occasional “burn down chart” and “backlog” thrown in, you have found your ideal scrum master. Remember, anything more than this, and you may have (god forbid) the possibility of a successful product/project on your hands.
- Sprint cycle can be used to create a keen sense of frustration amongst the development team. The more immature the team (technical and project experience) the shorter the sprint cycle. The reverse is also true the more mature the team, the longer the sprint cycle. Their frustration levels will rise at not being able to show a working product and not seeing any release milestones in the horizon. This should lead to a development team that is dislocated, downturned, dysfunctional and deflated.
If you have read this far and noticed the tongue firmly in the cheek, then you would also have grasped the point of this blog. These are not points that are to be followed for successful product/project execution. They are the obstacles (just a few), the holes on the road to a successful development of a product/project. Those who do not learn from others failures are condemned to repeat them.
These obstacles should at all costs be avoided not embraced, unless the aim is to fail! Product or project development is not only about the plan or the process, these are important, but what makes it memorable is the people and the events that occur during the execution. To fail to recognise the blend of talented people required for success is to mark your road map for a sure failure or to set a very low expectation of success.
Note, we have used scrum and agile to be synonymous, some purists may not approve, but considering the purpose of this blog, you should be lenient.