Agile guru Ken Schwaber says that “[Scrum] is so trivial I sometimes wonder what the big deal is!” When the inventor of the method (although he refuses to take that title saying he just pulled together a number of existing ideas) says this you’ve got to wonder what a whole bunch of training companies cover in their £1000 plus “Scrum Master” certification courses! There is a great danger in believing that training alone makes you an expert in a field. Courses like Prince2 Practitioner and Scrum Master only teach the theory; to judiciously apply it takes years of experience across a range of projects preferably supported by coaching Scrum Master.
My advice would be to save your training budget and read a book, watch a video or get online and use the multitude of free Agile resources. One of the best teaching tools I’ve found is a YouTube video called Scrum in Under 10 minutes.
Once you’ve understood the basic ideas of Scrum the hard work begins. Schwaber likens it to chess. Learning the rules of the game is easy, but applying them can be very difficult indeed. The problems posed by any one game could be one of an almost limitless permutation of possibilities of infinite complexity. That’s why I always baulk at the idea of becoming a “Master” at Scrum after a two-day course. Imagine calling someone who’d taken 10 minutes to learn the basics of chess a Grand Master and pitting them against Garry Kasparov!
To position Scrum as a set of rules and methods is getting away from the very essence of the approach. Scrum isn’t supposed to be a prescribed set of steps that you can turn to at any point to tell you what to do next. Its invention was in response to the many prescriptive methodologies that appeared in the 80’s and 90’s. The Agile ethos is to liberate product development teams and to get them to think for themselves.
Some people seem to think that because of its lack of management process agile is either an easy option or results in chaos. However I find the opposite is true. Scrum’s attributes of working in small teams, meeting regularly to discuss progress, working in short sprints which result in a finished product means that people work hard in an extremely focused, results-orientated way. Also at any point in time it is very clear exactly where we are both, for better or for worse. In projects running to more traditional ideas it can be all too easy to obfuscate the situation behind a barrage of Powerpoints, forms and processes and introduce many unnecessary delays.
In the next part to this series of articles I will look at the background to Scrum and some of the key themes to the approach such as transparency, releasing something that is “done” and cross-functional teams. If you are using or thinking of using the Scrum approach or any other of the Agile ideas – please feel free to comment below. I would also be interested in any comments from people vehemently opposed to it!