The concept of Scrum was invented for use in software development in the 1980s. It took a while for the concept to catch on in project management circles, but the idea has evidently stood the test of time. Now, even PMs far outside of the software industry have at least heard of this iterative method for project execution. There is actually an entire website (scrumalliance.org) devoted entirely to the exploration and further development of this concept.
The Scrum approach is often praised for its simplicity, agility, and results-oriented focus. Proponents of this methodology place a high value on collaboration, function, and flexibility over more traditional concerns like detailed documentation and plan adherence.
The actual project management process involves 3 sets of players. The Product Owner is the individual who ensures that the project outcome has real world value to stakeholders such as customers and the business organization as a whole. The ScrumMaster oversees the team to facilitate productivity and resolve any conflicts/roadblocks that may keep work from getting done. The Team is responsible for performing the project work as well as determining the processes by which the work is accomplished.
Step by Step
The Product Owner is responsible creates a product backlog that lists the work product items desired in order of priority. The Team selects a few items from the top of the list that will be addressed in a short burst of focused work activity called a “sprint”. The team is responsible for coming up with a realistic plan for how to achieve these project objectives quickly. This work period is short (less than a month). The team gathers once per day for a Scrum meeting to evaluate progress and make any necessary adjustments in their approach to achieving the sprint goals. The ScrumMaster referees the overall process as needed to keep the team on track. At the end of the sprint, the work product should be complete and fully functional. The sprint and its outcome are reviewed to capture any lessons learned. Then the whole process begins again with the next batch of items from the product backlog.
Can Any Project be a Scrum Project?
With highly creative processes, Scrum has obvious advantages. It permits the project scope to be rapidly modified on an ongoing basis as collaborative planning sessions open up new avenues through which to achieve the project objectives. While it doesn’t have a lot of safeguards in place to keep costs and schedule within reasonable parameters, it does make an effort to ensure that whenever the project is terminated there is something of value to show for all that work.
Proponents of Scrum sometimes state that it can be used for any type of project at any scale. However, this is not necessarily true. For example, a project undertaken as part of a government contract could have very specific rules about milestones, accountability, deliverables, and documentation. This might not mesh well with the highly fluid nature of Scrum project management.
In addition, not every project team is the right fit for this process. Some employees would prefer to simply be given clear instructions to follow to accomplish their schedule activities. Finally, in some situations the nature of the desired end product is straightforward enough that scheduling daily meetings to reevaluate how the project work is getting done is simply not a reasonable use of time.