Flickr Badge

Sunday, August 20, 2006

5 dangers when adopting agile processes - and what to do about them

The last couple of years have seen agile software development 'cross the chasm' from the early adopters to the mainstream. This is great news for agile, but there are some dangers lurking in the background. Here are five points that companies need to watch for when adopting agile processes

  1. Unfamiliarity: When early adopters practice agile, they really understand what agile is all about. Mainstream companies are less likely to understand the principles of the process. They've heard about 'this agile thing' and want the same benefits on their projects.

  2. Top-down thinking: Most organizations practice top-down management, where managers make decisions and staff follow them. Agile processes work bottom-up, where the team is empowered to take many decisions, and the team is responsible for changing the process. This can be uncomfortable for many managers.

  3. Culture change: Agile processes not only demand a change in they way software is developed, but a change in culture. Agile processes value a culture of openness, cooperation and collaboration. The mantra is "get work done", instead of "cover your ass".

  4. Incomplete implementation: Companies that implement agile processes sometimes change the process out of convenience, without an understanding of the process. 'We don't do retrospective meetings because they waste a day of work', or 'Everyone knows what to do, a daily standup is not required' are some forms of process change that are instituted under the guise of 'tailoring the process'. Tailoring the process is good if you know what you are doing, but can lead to disaster if it is done just for convenience.

  5. Silver bullet syndrome: Agile processes are not a silver bullet. They will not magically deliver your software, cure all ills and create world peace. There are many components to a successful project, and the process is just one of them. You still need a good team to do the work - in fact a good team is even more important in an agile process than in traditional processes. There are many components that determine project success or failure - management support, effectiveness of the process, quality of the team, familiarity with the domain and technology, to name a few. Agile can help with the process, but don't ignore the other components.

Right, so what can you do about it? Here are three ideas to help you get started with agile

  • Learn about agile: The best thing to do is to learn about agile. I mean really learn about it, not read a single article in a magazine about how agile is the next big thing. There are lots of great online resources for learning. Check out agile websites, blogs covering agile or agile groups on Yahoo! Groups. You will find lots enthusiastic people just waiting to help out.

  • Start small: Start small, refine, repeat. Implementing an agile process is not something that can be done throughout the organization in one shot. Accept that the first few months will be unproductive as everyone comes to grips with agile, its culture and its values. Choose a small project as a prototype, and iteratively refine the process. When you are comfortable, move on to another project, then another.

  • Examine the organization culture: A big stumbling block is reconciling the existing organization culture with the values of agile processes. Transitioning to agile involves change, and like all change it is easy to see things not work out at the start, get frustrated and return to known, comfortable ways of doing things. Take some time to learn the values of agile, and how it can be incorporated into the organization.


This post is a part of the selected archive.

5 comments:

Casey Helbling said...

I don't believe that unfamiliarity should be considered a danger. I suggest buying a book and just jumping in...

Refactr .com -- Dangers When Adopting Agile - Response

Anonymous said...

Heres a problem with scrum. Humans, when you try to measure their work, try to maximize the metrics, rather than the work. Check out what happened in the USSR.

With Scrum, you may start seeing the following:
1) "shaving" estimates to make sure you meet your scrum target
2) "banking" finished work to get yourself a day (or week) off.

Whaddya think?

Siddhi said...

Completely agree, for every metric there are a bunch of people out to maximise the metric. I am quite wary of metrics.

The difference in Scrum and most agile methodologies is that the control lies with the customer (or whoever is representing the customer). In the end, the customer has to accept the features that have been implemented.

So if you shave estimates to increase the work done, but the customer does not think that it has been implemented properly, it goes back into the queue.

The principle is to measure the value delivered rather than the effort put in.

As for "banking" work, (which if I understand correctly means inflating the estimate) there are a number of solutions. In pair programming environments, there are two of you working together. Similarly for colocated teams where everyone is nearby. There should also be the desire to do more every iteration. Add to this non-agile techniques like having motivated, aligned developers with a shared vision. All these tend to inhibit inflated estimates.

Coming back to the original question of metrics, this topic came up in the scrumdevelopment Y!Group recently. Check out the thread here: http://groups.yahoo.com/group/scrumdevelopment/message/15384

KLR said...

Hi

Will agile work for a fixed bid engagement?, where the scope and effort are predetermined. But customer might have some changes to requirement at end state.

Regards
Kannan

Siddhi said...

Yes you can.

More information here - http://alistair.cockburn.us/Agile+contracts

And another approach - http://www.codesqueeze.com/how-to-sell-agile-to-fixed-bid-contract-clients/