Why Scrum is still one of the best project management methodologies today
Published: May 2, 2017
Project Management Approach
While many organizations are adept in leveraging a variety of the industry’s best methodologies and tools for managing software and design projects, by far the best methodology for software development and/or interface design projects is Agile Scrum, or “Scrum.” Scrum provides the communication and feedback loops while working with rapid change through the development process, allowing for adaptation and use of best practices when developing quality software. The iterative and user-centered design, leveraging rapid prototyping tools and processes is advantageous in any project management approach. It helps teams respond to the unpredictability of building software through incremental, iterative work cadences, known as sprints.
What Is Scrum?
Scrum is a sub-methodology of Agile that allows for a rapid, highly interactive, iterative approach to development. It has a simple implementation designed to increase productivity and reduce the time it takes to benefit from a software/product development. Importantly, it embraces adaptive and empirical systems development.
Adaptive and empirical are two of Scum’s most valuable principles. Most project management methods and techniques are very prescriptive; they tie down the team to a fixed sequence of events and offer little in the way of flexibility. Fortunately, Scrum is mature and has a track-record for success. Similarly, it is scalable as it works on projects of any size. “Scrum teams” allow Scrum for management of enterprise-level projects.
Scrum also promotes and lends itself to managing eXtreme Programming (XP) based projects. XP uses “soer on site” as a means of ensuring answers to the development team’s questions, but also to ensure that the development team is producing exactly what the customer wants.
While some consider the waterfall approach, where work on the analysis starts as soon as some requirements exist, and subsequently, as soon as some analysis exists, work begins on the design, and so on throughout the process, Scrum embraces the opposite. In other words, small pieces of the project can be done at a time, in an iterative fashion. Iterations consist of some requirements gathering, some analysis, some design, some development and some testing culminating in an iterative release cycle.
Scrum revolves around simplicity, resulting in delivery of something that moves the project forward. It achieves this by proposing the following questions:
|Scrum asks…||Fundamental Project Management issue|
|What was done during the last 24 hours?||This is progress, it’s work completed to date|
|What is planned to do in the next 24 hours?||This is forward planning; it is work ready to be completed|
|What prevents work within the next 24 hours?||These are the impediments or obstructions; it might be dependencies requiring resolution or more planning. It’s also an identification of immediate risks.|
Scrum uses three roles: Scrum Master, Product Owner, and the Project Team.
- Scrum Master – maintains the processes (typically in lieu of a project manager)
- Product Owner – represents the stakeholders and the business
- Project Team – consists of a cross-functional group who do the actual analysis, design, implementation, testing, etc.
The base Scrum process is best described by Figure 1 below. Most projects have a list of requirements (type of system, planning items, type of application, development environment, user considerations, etc.). Scrum records requirements in a Product Backlog. Requirements need not be precise nor do they need to be described fully. As with most projects, the requirements are sourced from the expected users or the business. The Product Owner prioritizes the Product Backlog: items of importance to the project/business, i.e. those items that add immediate and significant business value, are bubbled up to the top.
The Project Team responsible for doing the actual work then creates a Sprint Backlog: this is comprised of Product Backlog items for completion within a 30-day period. The Project Team may liaise with the Product Owner and others to expand item(s) on the Sprint Backlog. After 30 days have elapsed, the team should have a “potentially shippable product increment.”
The Product Owner, the Scrum Master and the Project Team will make an initial pass over the Product Backlog items where they work out roughly how long each item will take. Initially, these are estimates, best guesses. As time progresses, well within 30 days, the team will know if the project estimate was even close.
Scrum lets the team refine estimates on-the-fly. If the belief is that a task will take longer than envisioned, team members can say so before the task starts. By only working with small work packages (time-boxed to 30 days), any schedule/requirement issues are dealt with as soon as they are identified, not much further downstream where the cost of recovery is considerably higher.
What does this “potentially shippable product increment” mean? Put simply, every 30 days, the team should provide something of value to the business, something they can use or something that provides considerable direction.
The beauty of the 30 days’ approach is this: if the Product Owner, customer or the business likes what they see at the 30-day interval, they can then re-prioritize the Product Backlog. This is important as it means that the development teams are only ever producing goods that will be used by the business.
While there are many more benefits to leveraging the Scum Methodology in software/product development, this post was intended to provide a high level overview. To find out more about best practices in custom software development and design, or if you are ready to discuss a development need and want to leverage a proof of concept, contact Microexcel at email@example.com.
Test drive our services and capabilities with a smaller engagement. Explore how easy it is to work with us.