Agile Zone is brought to you in partnership with:

Programmer, solution architect, user group and conference organizer, conference speaker and traveling fun code evangelist. Johannes tries to apply Agile principles to large software projects, but what he's really passionate about is sharing the experience of more fun programming with other coders around the world. Johannes is a DZone MVB and is not an employee of DZone and has posted 35 posts at DZone. You can read more from them at their website. View Full User Profile

Use Scrum Even If You Don't Want To Be Agile

06.07.2012
| 5795 views |
  • submit to reddit

An “Agile” project is one that actively seeks to incorporate changes as the project progresses, rather than assuming that the plans from the beginning of the project will work for the whole project duration. Not all organizations want to adopt “agile” as their project metaphor. And some organizations that do adopt methods such as Scrum do it without becoming as “agile” as Scrum promises. Instead of criticizing these organizations of “agile heresy”, I would instead like to offer some useful experience from Scrum, even if the word “agile” doesn’t appeal to you.

Track your progress with small, well-defined milestones: The Product backlog of Scrum is essentially an ordered list of work items. Good backlog elements are either completed or not completed. Partially completed milestones are not counted. A more Agile project will let the product backlog change throughout the project, while a more rigid project may set down the whole backlog at the beginning of the project.

Using a product backlog that is complete ‘up front’ makes your project less agile, but using a product backlog lets you track progress better than most traditional project plans.

Demonstrate progress to stakeholders: The earlier a project gets feedback on the work it has completed, the better it is able to anticipate and deal with misunderstandings. The expectations of stakeholders is often misunderstood until everyone can actually see what is being constructed. Scrum requires Sprint reviews at regular intervals of a couple of weeks to demonstrate progress. A project with less communication with the stakeholders may have fewer and less regular reviews, but every review you do have will reduce your risk.

Communicate daily within the team: Just as there will be misunderstanding between the project and the stakeholders about the proper outcomes, there will be misunderstandings within the team about the proper strategies to complete the project. Scrum requires a daily standup meeting to enforce communication within the team. Other teams may be geographically distributed, dislike the ritual of the standing meeting or work on non-overlapping tasks and decide that they need less communication.

Regardless of the form or frequency of communication within the team, the project should evaluate whether they are making repeated mistakes because of lack of shared knowledge and awareness. And whether their rituals waste or preserve the time of the team.

Make decision making explicit: In Scrum, the decisions about what the team should work on rests with a single individual: The Project owner. Many organizations cannot invest the authority that this role implies with a single individual, or cannot find an individual with both the business understanding and the technical knowledge to make confident evaluations.

Regardless of whether the authority rests with a single individual, a project needs to make decisions about what it should create and in what order. Identifying who needs to be involved in these decisions will make the project run more smoothly.

You don’t need to “drink the Agile cool aid” to benefit from the experience of Scrum over the last 20 years. And many projects that profess being Agile just be using the rituals from Scrum within an old mindset. You will not get the same benefits from Scrum as a truly agile team, but that doesn’t mean it’s not right for you.

Published at DZone with permission of Johannes Brodwall, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Tags:

Comments

Jilles Van Gurp replied on Fri, 2012/06/08 - 2:17am

The experience of scrum of the last 20 years is largely a completely unsubstantiated myth propagated by people drinking way too much of the coolaid. The cold hard reality in our industry is that the number of failing projects is a constant, regardless of the methodology. I've not seen any compelling evidence that the ratio of success and failure has changed in any way since the fifties in our industry.

If you look for it, you will find plenty of anecdotes (often mistaken for evidence) suggesting that scrum is the best thing since sliced bread but very little properly conducted studies and surveys that actually confirm this. The problem is the anecdotes are biased, one sided and part of a sales pitch. You only get to hear about the (alleged) success stories. No self respecting agilist will go on record admitting he did everything by the book and completely failed to deliver good quality software on time. Yet that happens all the time (and don't go tell me they werent doing it properly, that's just so lame). Worse they'll take credit for a great project and leave before the shit hits the fan even going as far as trying to present it as a success. I've seen spin put on projects that I knew were failures being cited as actual success stories.

The reality is that there are tons of very confused & misguided agilists imposing scrum inappropriately and failing miserably. I've seen teams that were completely paralysed going through the moves of doing scrum. Post its on the wall, introspectives, estimations and everything. Only problem: they didn't get a damn thing done and what they did had to be rewritten from scratch later (i.e. by me).

Also, iterations are very nineties. These days you should be practicing continuous delivery and deployment. Scrum actually gets in the way of that. No more release cycles. No more sprints. Just work coming in, being prioritized, and getting done. Not very appropriate for the overpaid throw it over the fence and run away consulting crowd but very appropriate for product or service delivery teams that have to support and evolve a product for several years.

Edwin Keeton replied on Sat, 2012/06/09 - 11:18am in response to: Jilles Van Gurp

Jilles, you speak the truth.  Scrum has joined the XP literary movement, seductively presenting half-truths as the whole truth.  

 But if only I would buy this book and attend that expensive workshop/seminar, perhaps I would finally see the light.

Paul Russel replied on Sun, 2012/06/10 - 7:46am

I fully agree that this is useful for anyone running an IT-related project, agile or not. 
I don't think everyone is aware of the great impact that these techniques have on the motivation of the team members and the productivity of the team.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.