Scrutinizing Scrum

A few months ago I first heard about agile planning methods in software development from Christian (see this blog in April,  Nobody’s perfect) and now Helmut is busy reading up on Scrum. Scrum is a project management method which focusses completely on the customer and the quality of the product.  How? It progresses in very short cycles to develop a product and checks that progress against a grid called the product backlog, a description of the product and a to-do-list that is maintained by the product owner and communicated to the whole team on a daily basis. That may sound like a lot of work, but it cuts unnecessary ballast out of work processes and keeps the project on track.

“Scrum” is actually a term from the rugby playbook. After an infringement or a break in the game, the forward players huddle in several rowslocking heads and shoulders, working as a unit in a powerful collective effort to regain possession of the ball.

To “lock heads” also means to come together to do some intensive thinking.  And that is essentially what happens in Scrum.

All “players” work very closely and in short sprints to achieve closely defined targets. Scrum includes short, frequent, and tightly structured meetings with highly effective documentation (the “sprint backlog“) so that everyone knows what has been done, what needs doing and who is doing it. The meetings are part of the iterative project framework, built with a tight work schedule but an evolving definition of the production process and the product itself. The goal is to produce the best quality possible, getting rid of planning constraints that could compromise that quality. The product has to evolve as it is tested and critiqued, improved and redefined. The incremental changes and targets are broken down into small jobs delegated and monitored in the sprint backlog.

Then there are roles that need to be defined, and responsibilities to be delegated. Scrum acknowledges that not all of the parties involved will be equally dedicated to the outcome. The authors divide the roles into “pigs” and “chickens“, as defined in a joke:

A pig and a chicken are walking down a road. The chicken looks at the pig and says, “Hey, why don’t we open a restaurant?” The pig looks back at the chicken and says, “Good idea, what do you want to call it?” The chicken thinks about it and says, “Why don’t we call it ‘Ham and Eggs’?” “I don’t think so,” says the pig, “I’d be committed but you’d only be involved.”

So the chickens – the users, managers and other stakeholders who contribute to the outcome – are all important participants, but the bacon will come from the product owner (the person keeping the product definition up-to-date in the product backlog) and the scrum master (the person making sure that everyone is working together as they should be) and the team itself – the people doing the programming.

That all sounds very good, and promises to save money and secure very high quality. But there are a number of puzzling points that are worth scrutinizing. First of all, it’s very tricky to get around the problem of not having a neatly defined product when you set up contracts and budgets. After all, the managers involved want to know what they will be getting.  Now, the product backlog is a great resource that shows you exactly where you are. But at the outset it is not clearly defined where exactly you are going – that evolves during the entire process. Additional costs may be incurred, or targets may need to be redefined. By contrast, standard projects have contracts with extensive functional specifications that define the targets in great detail and lay outbinding schedule in advance. With Scrum, who is to say if a project is running according to plan at any given point in time?

This is not as much of an issue if a company is applying the method internally, with the product owner marketing the product for his team. But if production has been outsourced and external service providers are producing the software, the product owner is in fact the product buyer. He needs to be involved in the Scrum process in a way that requires an unusual level of collaboration between the buyer and the seller, and this close collaboration is more native to internal projects, especially those run by innovative smaller companies.  One of the key issues, then, is risk management: Who bears the responsibility if problems arise that could postpone the delivery date, cause additional costs or change the focus in ways that were not foreseen and accepted by management? Interesting issues, aren’t they? So from what I have read and heard so far, Scrum seems a great way to go, but the people responsible will certainly be scrutinizing Scrum.

englishlernen – learning english – englischlernen – learning english

Published by


Teaching English for business communication skills, writing online for learners, translating, sailing whenever I can, from Washington, D.C.

One thought on “Scrutinizing Scrum”

Leave a Reply

Your email address will not be published. Required fields are marked *