I was recently catching up with an old friend from school; he was interested in Scrum, as he had started to get requests for proposals that specifically asked for Agile. We were on a Stag do at the point of the initial conversation, so I probably didn’t articulate what Scrum was that well, and even if I did my friend was in no position to remember anything I said. So when I had recovered I jotted down some (quick) thoughts for him, he was particularly interested in how you manage a Scrum project and how you get started. Here were my thoughts designed to wet his appetite:
Scrum is not a methodology with all the steps that people can follow and get results, its not really a process. Scrum is an Agile management framework, that has a simple set of rules with the goal of frequently delivering valuable increments of working software to the customer.
Now you were particularly interested in how you manage Scrum projects: Scrum is actually a total paradigm shift in how we manage projects. In software developments we have struggled with late delivery, ballooning scope, technical problems, mistrust between the business and IT. With traditional management approaches we try to control this through more up front planning, tie down scope and sign it off, detailed upfront design documents, expensive tools to support methodologies, teams dedicated to assure quality and strict change control. In Agile we are trying to solve the same problems but in a very different way. Software development is a complex business that you can't plan out upfront; we need to allow room for creativity and innovation. Therefore Agile is about generating feedback so that the project can be driven forward in the right direction, we generate feedback by both the business and IT working together throughout the project to try and achieve a shared goal and by delivering the most valuable vertical slices of end to end functionality, not just a prototype but software in the real technology, fully tested, fully integrated and with no known quality issues, it may not do very much but what it does it does well. Scrum works by harnessing the benefits from having a self-organising team, who take responsibility for what they deliver, they are cross-functional in that they have all the skills to build something of value in an iteration (Sprint), that will give feedback, the team make a commitment to the business at the start of the iteration as to what they can deliver they are then responsible for delivering on that commitment. Managing Scrum projects is nothing about control, but all about creating the right environment where the team can achieve their commitments, it’s about removing the problems that are preventing the team from delivering, it is about coaching the team to a higher state of productivity and quality. Control in Scrum comes from having hyper-productive teams that can deliver regularly and in a predictable manner, if you have a dedicated team, you understand how much working software they can get through each iteration, you can start to make commitments around that.
You asked about how you would start up a Scrum project, and the short answer is you just start, there is no big up front planning needed. You probably need a business case and a Vision for what you are trying to achieve and a prioritised list of things to do (in Scrum this is the product backlog and it needs to be stocked with at least enough for the first iteration). Now you may need to setup environments, do some initial design, set-up continuous integration, etc…, but equally these can just be the first things on your list that the team do, we want the team to take responsibility for all aspects of the project, as they will know most about the problem they are trying to solve. What I would do is have the team go through a 1 or 2 day Scrum/Agile training course at the start of the project, we want them to take responsibility it is only fair to tell them what we expect of them, it also works as a good team building exercise. Ideally this training would be followed up by support from an experienced Agile Coach, as you can see this type of environment is very different from a traditional one, it is very easy to fail without that support.
For more information about Scrum see our process guidance at:
http://www.scrumforteamsystem.com/processguidance/