IT Planning with Scrum

There's a book that made a big impression on me a couple of years ago, and changed the way I manage a number of my software projects. The book is Agile Software Development with Scrum , by Ken Schwaber and Mike Beedle. The book presents an approach to software project management that, with some changes and adaptations, I've found useful in working with many of our ongoing clients. In a minute I'll give the a five-minute intro to Scrum... but here's why I'm thinking about it today. I happened to be glancing at the Wikipedia article on Scrum, and noticed the following comments: Its intended use is for management of software development projects....However, it can theoretically be applied to any context where a group of people need to work together to achieve a common goal - such as setting up a small school, scientific research projects or planning a wedding. Reading this, it dawned on me that the elements of Scrum might make a fine framework for managing the IT projects of a non-profit organization. I often hear organizational staff complaining that they just don't seem to get it together to carry out some of their long-term IT goals. I see groups trying to develop training manuals, or bring their webserver in-house, upgrade various applications, and so on. I'd bet Scrum, with its emphasis on frequent short cycles in which specific improvements are made might be of help in this situation. The purpose of Scrum. Along with other practices developed by the Agile Development movement, Scrum evolved to create a structure for modern software projects which take place in changing business environments with short lead times and continuously morphing requirements. The old approaches to application development seemed not to be working anymore: development staff were finding that by the time they had designed and built the elaborate systems being requested, they were already obsolete. No matter how carefully and quickly they worked, they always were fighting a backlog of requests, users always wanted stuff faster than they could deliver, and the change requests never stopped. Sound familiar? Scrum is an attempt to accept and work in this environment, rather than deny it. The Elements of Scrum The Sprint. Scrum sees a project advancing in controlled spurts called Sprints. A sprint lasts about a month. We have found three-month sprints work well too. At the beginning of a sprint, the tasks that will be included in the sprint are selected by the team. The "team" therefore includes key users as well as the project staff doing most of the work. The items should be realistically chosen to be do-able over the duration of the sprint. This kind of planning feels quite different than selecting the tasks, and then estimating how long they will take. The Backlog. Where do the tasks come from? As requests from users arrive, as they inevitably do, they are put into a list of tasks called "The BackLog". A task should be bite-sized: between 1/2 to 2 work-days to complete. So complex tasks need to be broken into their components. It may be that you do not know how do to this, so maybe the only task that can be entered at first is "Figure out how to approach that complex task". Someone needs to be responsible for keeping the backlog and entering requests into it. Scrum refers to this person as the "Product Owner". This is the person with primary responsibility for getting this team to function properly. The Sprint Planning Meeting. At this meeting, the team determines which items from the backlog are to be included in the next sprint. In getting ready for this meeting, the "Product Owner" may need to work clarify the meaning of requests, and get estimates from team members for the how long each task will take. Key stakeholders need to be at this meeting, so that the delaying of items to a later sprint is understood as a team decision. Daily Scrum Meetings. The team meets every day for a very brief meeting (maybe 15 minutes) to share what they are working on and what difficulties they are running into. These meetings are the responsibility of the ScrumMaster. The ScrumMaster is also responsible for trying to resolve everyone's difficulties as well as possible. This may mean coordinating logistics, making purchases, reassigning tasks, arranging a walk-thru with users, and in general assisting the rest of the team in anyway possible. As the Sprint draws to a close, the daily scrum meetings serve to make decisions such as the actual date to end the sprint and what requests if any need to be dropped from the sprint due to schedule overruns. Sprint Retrospective. At the end of each sprint, the entire meeting briefly discusses how the sprint went, and what to do differently for the next sprint. And the process begins again. The Advantages of Scrum for IT teams User acceptance of schedules. Users are actively involved in determining what features are included in each sprint. Since sprints are of equal length, there is no "real soon now" or "as soon as we can get to it" - its "Should we do this next month or not?" Set up wireless network. Next month or not? Bring our web server in house? Next month or not? And involving all stakeholders in each sprint plan reduces pressure on the IT department. Perceptible improvements. The team can win increased support from users by showing a steady stream of perceptible improvements. Instead of users waiting an uncertain time for uncertain gains, they see specific improvements to their IT infrastructure each month or quarter. Planning made possible. Since only a month worth of work is committed to at a time, up-front planning is more realistic and immediately useful. More complex planning tasks are backlog items to be done like any other, not first steps of that prevent the scheduling of work. Transparancy. Daily Scrum meetings encourage honesty about problems, delays, and difficulties that may be encountered on the way. So there are fewer nasty surprises. Indeed, Schwaber considers this openness a key value of the scrum approach that contributes to better quality. Agile and Xtreme methodologies have created a lot of excitement in the software development world in the last five years - there's no reason not to move these approaches to the daily tasks of technology management. Tags: nptech, tech_planning, scrum