If I am pressed to come up with a methodology that is a somewhat close fit for my own thinking on how software development should be managed, it would be Scrum.
Scrum, for once, is not a clever acronym; instead it is slang for a group huddle in the game of Rugby, where the players cooperatively strategize about how to move the ball down the court. Although often used with Agile processes, Scrum actually has nothing inherently to do with Agile or eXtreme Programming — or even with software development, as it’s used in other fields of endeavor, too.
Scrum has been (mis)appropriated in various ways, including probably by me, but I like the general concepts.
First, Scrum recognizes a few uncomfortable facts of life:
- Requirements are never fully understood at the start of a project. Even when you think they are.
- Requirements (and your understanding of them) always change during a project.
- The introduction of any new tools or techniques into a project renders it even less predictable.
Scrum is a way to manage projects with lots of unknowns — projects, such as software development, that need an empirical approach, not a fixed methodological approach.
You can find a pretty good 30,000 foot overview of the Scrum process here.
In essense, top management (or the project champion — whoever is the ultimate paying customer) conceives a project, chooses a team, and then gets the heck out of the way so they can do their job. This implies the first principle of Scrum, which is to trust and respect your team; after all, you picked them! This means that Scrum will never happen under a micro-managing, insecure, or abusive champion. The very idea of Scrum will terrify such a person. Managers who confuse leadership with browbeating or puppeteering, need not apply.
The product champion who initiates a Scrum project recognizes that it’s his or her job to support the team with resources. In almost all cases, the team will ask for the resources it needs; a good manager need not and generally should not offer to “help”.
Often, resource requests come in the form of reports of impediments to the project’s progress that require management authority to remove. In organizations of any size that have been around for any length of time, there are many well-intentioned procedures, processes and practices that do not serve effecient and effective software development. Product champions in a Scrum setting need to be prepared for the political chaos that can result from removing such impediments. That is why the champion needs sufficient authority (or at least real backing from higher management) to overcome these impediments.
More than one project I’ve been associated with has gone by the wayside when the progress of that project was at odds with the bureaucratic and political intertia of the organization; that is why you always need a champion with sufficient power to get obstacles removed. It’s like qualifying your lead in the realm of sales. There is no point in doing business with a champion with insufficient authority and clout.
I emphasize the management / sponsor / champion side of Scrum because it’s usually overlooked. The part that captures people’s attention seems to be the daily “scrum meeting” where everyone touches base about what they did yesterday and what they will do today. I personally consider this the least interesting aspect of scrum, as other than the daily frequency it’s a common-sense ritual of any methodology. But I suppose that organizations that don’t understand that meetings are productivity killers consider the scrum meeting to be profound because it’s only 15 minutes long. In addition, most organizations are meeting-addicted and don’t feel right about not having a meeting.
Scrum meetings are run by a “scrum master” who is responsible for making sure every developer answers three questions: what did you do yesterday, what will you do today, and what if anything is hindering you from your objectives? This strikes me as a little bit annoying and insulting unless done with considerable finesse; it could make the “scrum master” equivalent to the hated “hall monitor” (aka snitch) of grade school days. I wouldn’t formalize this role, but over time and on average, every team member does need to provide this info.
There is nothing about a scrum meeting that can’t be accomplished via something like a teleconference, IM, Groove, or even email. In fact it doesn’t necessarily require everyone to contribute at the same exact time, though it may well be convenient and logical to do it first thing every work day.
If I have a beef about scrum as it’s traditionally presented, it’s that it is a team sport metaphor that implies a team that is physically present in the same location on a daily basis. I am a believer in virtual teams, and cutting out the Amway-style back-slapping whoo-hoo yeah-team bullshit. For a good developer, doing insanely great work on an interesting project is all the motivation that’s required, and mutual respect of team members for each other’s technical capabilities is far more important than less relevant and less universally accessible bonding experiences such as a weekly game of tag football or meetings with free pizza.
The other key feature of scrum is the concept of “sprints”. A sprint is essentially focused work towards an agreed-upon monthly milestone. A lengthier, more formal monthly scrum meeting is used to present the work in progress. The goal of each sprint is to release a runnable, and as much as possible useful, version of the software under development.
From meeting to meeting, a list of backlogged work is kept — really just a prioritized to-do list; again, nothing profound here.
All of this is very common-sense and easy to understand. I like that sort of thing.
Like any Good Thing, scrum can be mis-used and abused. For example at www.controlchaos.com, a prime scrum promotion site, it’s suggested that you kick off a project by first setting the scope and deadline and then telling your team that they are charged with getting it done in half the time — and don’t be surprised if some people will even quit in protest. No kidding!
I reject that sort of arbitrary, manipulative crap. It contradicts other things that site says, such as that the objective is to do as good a job as possible. Any idiot knows that a deadline generated by marketing or just some dart thrown at a calendar is meaningless — things take as long as they take. Longer, in fact. Get over it.
Of course in the real world a project may be useful or valuable only if delivered before a certain date — in that case as long as everyone understands that the date is a constraint on what features and functionality can be implemented, that’s fine. Regardless of the underlying development methodology in use, scrum emphasizes delivering value in milestones at regular intervals (monthly is standard). It encourages discovery, design, implementation and QA in parallel.
So with scrum, what keeps the stakeholders happy is regular and open status meetings, plus early and frequent product deliveries and demos. That, plus the knowledge that people are hard at work doing their level best — whether or not the stakeholder had to compromise any on deadline or features.
