Why Choose Scrum for Web and Mobile Development
It's never surprised me that scrum has a bit of a controversial reputation. While some praise scrum for its effective and straightforward approach to software development, there are professional software developers who have staked their reputations on arguing that approaches such as scrum are at best pointless, and at worst detrimental to an effective software development effort.
Scrum may well have encouraged such heated debate, not because of anything intrinsic to scrum itself, but rather due to misconceptions and misapplications of the terminology and the technology that have grown up around scrum. And if your team is working on web and mobile development projects, scrum may be the best possible solution out there for managing your projects.
So What Is Scrum?
Scrum is one of a family of approaches to organizing software projects that fit together under the umbrella of agile. Other agile techniques include kanban and extreme programming. All of these approaches share a few common principles about how people should work together in software development, and how to optimize that process, such as:
- Delighting the customer
- Delivering working software frequently
- Business people and developers working together
- Measuring real results based on work that is completed
- Allowing teams to self-organize
- Reflecting regularly on what's working and what isn't
In particular, scrum is optimized for teams working on projects that can be broken down into complete slices of functionality able to be delivered within a fixed and regular time frame of usually one or two sustainable work weeks, known as sprints in scrum. Scrum uses the term stories to describe those slices of functionality, and strives to improve the team's ability to estimate how much effort would go into completing a story.
Unlike traditional software development approaches, often lumped together under the label waterfall, scrum doesn't involve long and detailed requirements documents full of specifications crafted by product managers that all need to be spelled out before the team can get started working.
Scrum is flexible enough to allow a team to get started based on just enough stories to keep them busy for a couple of weeks. In that time, if there's new user feedback, the market changes, new information comes up from outside or inside the company, or the technology underlying the product shifts, new stories can be introduced and worked on for the next couple of weeks.
Scrum also favors regular face-to-face communication over detailed specifications. This is usually helped along by having every member of the team stand up in a group daily and report on what they've done the previous day, what they're planning to do the current day, and whether they have any blockers. Scrum also recommends other regular face-to-face meetings, called rituals, for planning, demonstrating, and doing a retrospective every sprint.
While the prospect of a daily meeting may sound off-putting to a lot of developers, it's important to remember that these are all finely tuned scrum rituals managed by a scrum master, with fixed times and clear agendas. For example, the daily standup should never take longer than 15 minutes.
Roles such as scrum master and product owner are also defined within scrum. And you may have noticed that the vocabulary of scrum sounds a little funky for a professional technical environment. That's kind of the point. Scrum defines roles, rituals, and artifacts in such a way that you can't confuse them easily with other approaches.
Why Is Scrum Controversial?
The promise of scrum is alluring. Teams adopt scrum because experts say it will improve the team's ability to estimate the amount of work they can do, provide flexibility when market requirements change, improve transparency into the process, and foster an environment where everybody is encouraged to learn more and improve constantly while putting in a sustainable amount of effort. How can you argue with that?
Well, it's easy to argue with something that sounds too good to be true. And in fact, the more scrum promises, the harder it is for scrum to deliver on those promises. But I think scrum, and agile processes in general, have suffered from a fundamental misunderstanding about where they fit into an organization, and how they are distinct from the hierarchy of a business.
Scrum provides a way to make the best use of the resources you have available while remaining adaptable to a constantly changing market. It isn't a magic formula that you can pour over your team and suddenly have the results you've always dreamed about. If anything, scrum will expose problems such as technical debt, inadequate resources, or information hoarding quickly, bringing them to the surface instead of allowing them to hide behind job titles and self-limiting traditions. And as a result, scrum may get blamed for those problems in the first place.
But I don't want to come off as glib here. One of the reasons I believe scrum gets blamed for problems in the workplace may come from the temptation to pretend that you're using scrum when all you're actually doing is using the terminology or the tools. As with any cultural institution, the rituals and vocabulary of scrum can be mis-applied or even abused unless everyone is willing to learn the actual intentions and defend the original intent behind the practice.
In a nutshell, if scrum isn't working for you, go back to the definitions and make sure what you're doing is actually scrum. If you're choosing scrum because you think there's something wrong with the people on your team, you have an underfunded organization, or you think you may have product-market fit problems, you may need to address more fundamental issues before you can realize the benefits of scrum.
Why Scrum for Web and Mobile Development?
Scrum emerged in the 1980s, and began to take hold seriously in the 1990s. This is around the same time that software development started moving away from monolithic shrink-wrapped applications delivered on an annual basis, toward smaller more focused apps delivered constantly through web and mobile technology. I don't think that's an accident.
When the timeframe for delivery may be a year or more, a more traditional pattern involving detailed specifications defined up-front and worked on over the course of many months may make sense. But web and mobile technologies change very frequently. User expectations can be different from one week to the next, as new browsers, updated mobile operating systems, and unexpected competitors enter the market.
Scrums's focus on flexibility, transparency, sustainability, reflection, and the ability to estimate resources is perfectly matched to the expectation that companies with products in the web and mobile space can only survive if they are, well, agile.
Making the Move to Scrum
While the fundamentals of scrum are straightforward, implementing scrum effectively takes training, practice, and willingness. That's one of the reasons I wrote Scrum: Novice to Ninja. The aim of that book is to help introduce scrum to people working in web and mobile development who may not be familiar with scrum, and offer teams having trouble implementing scrum the opportunity to reflect on how they apply the techniques. I hope you'll check it out, and let me know what you think.