Agile methodologies, processes, tools, and techniques are not new to software or product development. They have been around for many years. However, as companies start seeing an increased need to improve their time to market while maintaining quality, they are looking to adopt some of these agile techniques in favor over the traditional waterfall methods. Projects in many organizations are claiming to be using agile. They may be using XP (eXtreme Programming), AD (Agile Database Techniques), AM (Agile Modeling), or any number of other agile methods. They may also be using Scrum. The question being addressed here is whether, in fact, projects are using Scrum, or picking and choosing some of the techniques and calling it Scrum.
What is Scrum?
First, let’s look at what Scrum is. According to the Agile Alliance, Scrum is an agile, lightweight process that can be used to manage and control software and product development using iterative, incremental practices. Scrum does not dictate which engineering practices must be used. However, often times you will see it combined with XP to generate the benefits of agile development with the advantages of simple implementations. Scrum, used properly, significantly increases productivity and reduces time to market while facilitating adaptive, empirical systems development.
Scrum adheres to the values as defined in the Agile Manifesto:
“Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan.”
In addition, Scrum principles are the same principles embraced by the Agile Manifesto:
- Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
- Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
- Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
- Working software is the primary measure of progress.
Scrum also has its own characteristics and practices:
- Three basic roles: Product Owner, ScrumMaster, and Project Team
- Product Backlog
- Sprint Backlog
- Sprint Planning Meeting
- Daily Scrum Meeting
- Thirty-day iterations, delivering increments of potentially shippable functionality at the end of each iteration
- Sprint Reviews
Remember, I stated earlier that Scrum uses an adaptive, empirical process for systems development. This approach demands flexibility and adaptability. Each project is different; that is why this adaptive, empirical approach can adapt to each project’s needs and provide for increased productivity and reduced time to market.
What Isn’t Scrum?
So, to the question of whether a project is, or is not, using Scrum. Let’s look at a few situations:
The project decides to use Scrum to manage a software development project. Management gives approval to use Scrum but insists that the team follow the prescribed software development processes to ensure the team is doing what they are supposed to be doing.
The project decides to use Scrum to manage a non-software development project. The team is not collocated and the Product Owner doesn’t have time to prioritize the Product Backlog. The Product Owner indicates everything is top priority.
The project decides to use Scrum to manage a software development project. However, the team decides it doesn’t have time to conduct the retrospectives at the end of each iteration. They also decide to conduct the daily Scrum meeting only twice a week.
I could go on an on about project teams having to follow certain practices that are contrary to Scrum/agile methods, or skipping certain practices, or not adopting the characteristics inherent to Scrum teams. The question some are asking, are those projects still using Scrum? Is it smart to use only some of the Scrum techniques and not others? Employing and adhering to all of the techniques and characteristics of Scrum provides the synergy necessary to produce optimal results. Why would you want to settle for less?
Abandoning some of the practices that make Scrum successful gives the naysayer more opportunities to claim Scrum doesn’t work. One would have been much better off espousing the individual techniques that were used than claiming that the Scrum methodology was applied.
Using only certain Scrum techniques and adopting only some of the Scrum characteristics may not preclude you from claiming you are agile. However, I would use this analogy to show why you cannot profess to be using true Scrum: Can you say you've made a batch of chocolate chip cookies if you leave out the chocolate chips?