You work in IT. You’ve heard about Scrum, but aren’t sure what it is. People claim it’s the answer to all our prayers. Others say it’s doomed to fail and a waste of time.
For that past 9 months I have worked with Scrum in a large company and want to share my experience through a series of articles. In this very short introductory article an explanation of what Scrum is.
1. Scrum in a nutshell
Most people are aware of the fact that most IT projects are still over budget, not delivered in time and/or do not necessarily provide the functionality that the end user needs. Many project management frameworks battle these problems in various ways. Scrum is basically one of them.
Of the three complaints mentioned above the most important one is not getting the business what they need. Seriously: delivering on time and within budget means nothing if the end product is useless. However, time and budget are also essential because they’re the principal reasons for aborting projects!
In the Scrum method much focus is laid on making sure the end product is what the business needs. To achieve this users have to be involved not only at the beginning and the end, but through the whole process. The sooner we know we’re on the wrong path the better, because it means less (and easier) rework and thus less time and money.
This is achieved by working in a series of timeslots, called sprints. At the end of a sprint the newly built functionality is demonstrated to representatives from the userbase. They can give feedback and approve parts certain parts, saving time later during acceptance tests.
The second focal point is cutting all unnecessary time loss. During software development many steps are mandatory that only serve the process and not the goal. Excess documentation is a good example. Modest documentation is enough. Communication is much better served by a live demo or sitting behind someones pc. Note: nobody said to do away with documentation altogether!
A big step towards cutting time loss is reshuffling of the teams. In the traditional waterfall method gathering requirements, designing, developing and testing are strictly separated. Each phase awaits conclusion of the previous one. But not all scope items in a release take an equal amount of time to process.
Scrum tries to tackle this by forming multidisciplinary teams based on scope items instead of profession. One team is responsible for one scope item at a given time. This means they don’t have to wait for other scope items that are more complex than theirs.
This has been a very short explanation. In the future I hope to publish some more articles about Scrum, drawing on my own experience. If you have any questions, please feel free to contact me.
Ed Luijendijk (30-05-2010 )
