This post is part of a series on approaches to software development.

Updated June 2013

Scrum is a software development methodology. When it was invented back in the 80’s, it was known as an all-at-once model, based on a team approach. While modern Scrum can still be described as such, it is now known as an agile methodology, and looks nothing like it did in the 80’s.

The traditional view of software development is to associate a phase of activities with the same name. Thus the requirements phase is associated with gathering requirements, the developing phase is associated with developing the solution, and so on. The reverse is also held to be true – the activities of a phase are bound to that phase, so you wouldn’t do any development in the requirements phase.

Scrum is an all-at-once methodology. Activities are bound to other activities, and not to phases. Phases seem to be done concurrently. Scrum is, in essence, a one-phase approach. This is why Scrum, at first, seems like the undisciplined hacking Boehm rightly complained about. However, it’s not that at all. It is a way of developing software when not only the solution, but also the problem is unknown.

When Takeuchi and Nonaka first described Scrum in 1986 [1], it consisted of choosing an elite team of experts, throwing them into a room, and telling them to solve a problem with seemingly impossible goals. This unsettles them somewhat, but you persevere. You tell the team how they do it is their business. Your business is to support them by providing all the resources they need. Management is decidedly hands-off, so you leave them alone but give advice when asked. After a while magic happens, the team self-organises, and a product starts taking shape.

The premise is that if you’re committed to the team and the project, and if your manager really trusts you, then you can get on with being productive – not justifying your existence.

So much for Scrum's beginnings. Scrum today looks a little different:


You need to learn a whole new language to get your head around modern Scrum. Terminology includes phrases like scrum master, burn down, sprint, backlog, stand-up, epic, spike, tracer bullet, velocity, sashimi, and planning poker (replete with cards) [2].

Scum today focuses only on building the solution. It does nothing to define a vision and scope for a project. Scrum eschews up-front planning, so there are no security, deployment, availability, support, migration or monitoring plans. There also aren't any quality goals. Scrum relies on the client for requirements, so business, system and operational requirements also tend to fall by the wayside. This makes it rather difficult for the project team (or the client) to understand what "finished" looks like.

On the subject of documentation - many Scrum proponents refuse point-blank to do any. Whilst I'm all for avoiding documentation where I can, there are times where it's just not an option. Say for instance you're an external dev house building a system for a customer, and the ops team starts asking questions about hosting your app. A conceptual design (.doc) and at least a logical deployment model will go a long way to help smooth the transition into production (.mpp). Documentation becomes an even bigger issue when facing regulatory compliance requirements, such as PCI/DSS or, if you're working in a government department, security accreditation. If you're still not convinced about the importance of it, consider that documentation is the only "truth" the team has to fall back on when things go wrong.

In Scrum a daily project team meeting occurs. It’s called a daily scrum, or stand-up. The stand-up has guidelines, including limiting the meeting length to 15 minutes. My experience is that this never occurs – stand-ups usually run on for at least half an hour. The worst stand-ups include managers – their presence turns any self-respecting stand-up into a status report.

Modern scrum has the concept of masters. According to the guidance, all team members should rotate through the scrum master role. That rarely happens, however. The guy with the certification becomes master, and stays in that role for the duration of the project. While the role is intended to have authority over process, and not people, keeping the same scrum master in place almost naturally shifts perception of the master to manager, thereby elevating the scrum master’s standing above that of other team members. This particular attribute is getting so bad these days that masters often don't even code[3], but have authority over technical decisions.

In closing, this is not a critique. I love Scrum, and I've seen it work beautifully - in some contexts Scrum is without doubt one of the better ways to build software. As with any other process methodology, chances of success with Scrum are directly related to the degree of the team's expertise, the political environment, and the context of the project. As long as it's limitations are understood, and catered for elsewhere.

Sadly, Scrum has become a poster child of the Khomeini Effect - the True Believers who, with loud voices and assertive personalities, put themselves in charge and cry "Do Scrum, or die!" There's no shortage of dogma. Philippe Kruchten discusses some of the other proverbial elephants in the agile room [4], including management, up-front design and commercial interests.

[1] Hirotaka Takeuchi and Ikujiro Nonaka. The New New Product Development Game, Harvard Business Review, January-February 1986.

[2] Dave Thomas. The death of agile (video); blog post; HN comments, 2014.

[3] Jonathan Rasmusson. Where did all the developers go?, Agile Warrior, 2013.

[4] Philippe Kruchten. Agile's Teenage Crisis?, Agile Alliance, June, 2011.

Updated with references.

Home | Blog | Photos | Contact | About and all content copyright 1995-2019 by Michael Wittenburg, unless otherwise stated.