Agile Development -- should I switch?

Agile Development -- should I switch?

Postby LoveGolf » Sun Jan 24, 2010 3:02 pm

I hear a lot about Agile development and a few of my newer developers are recommending we switch from our "classic" method as they call it, to something more modern. Where can I read some good information about it and what are the pros and cons I should consider? I am also worried about how long a switch would take as we have some near term milestones to work on, so what's the best first steps to take?
LoveGolf
 
Posts: 37
Joined: Wed Jan 20, 2010 7:58 pm

Re: Agile Development -- should I switch?

Postby akw » Sun May 09, 2010 11:10 pm

This topic is a hot one these days. Agile software development is a philosophy used to turn ideas in to code. Your first step is to get familiar with the philosophy to see if it fits within your environment.

The basic tenants of Agile from the agile manifesto are:

"We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more."

Some of the challenges
- All parts of the organization have to embrace Agile. It doesn't make sense to be churning out "shippable" code every 3 weeks if the marketing team needs a 3 month lead time on the exact feature set for brochures and collateral

- A basic tenant of Agile implementations is that people know best how to organize themselves. This poses some HR/management problems. How do traditional managers hold scrum teams and individuals accountable? What exactly is the role of a manager within an Agile organization? Teams should be self organizing and decide who is on the team so what happens when someone isn't right for "the team". What are the legal implications of this type of structure. The traditional manager often gets so far removed from the subordinates work that it's nearly impossible for them to give an accurate evaluation of their direct reports. We still haven't solved these problems completely but have made in-roads by using peer reviews.

- People sometimes use point #2 as a reason to not create documentation. This causes problems with bringing new people on board and slew of other problems around maintaining a consistent architecture/vision for the product, avoiding the "hit by a bus syndrome" etc. One piece of advice is to make sure your team still has the same documentation requirements as they did before. You can use the definition of done as a place to do this.

- You need to have very good senior people at the helm. This kind of organizational structure requires people that can predict issues, are empowered to breakdown roadblocks and feel empowered to do so. They also need to be able to convince people to get things done without having formal authority over them. Not easy tasks if you don't have the right individuals.

Length of time to implement a switch

I believe this is based on team size. A small company with 4 to 5 developers, a product manager and a project manager can easily use a flavor of agile to accomplish their goals. This could be done quickly and easily with some basic training. My experience was in rolling out scrum to a team of 30 people. It was somewhere on the order of a couple of months to get all the kinks worked out.

Generally the more people you have the longer it will take to roll out. If you have near term milestones you could make those the first things your team focuses on using an agile method like scrum.

Best First steps
- Some say start small - others say switch all at once including revamping all surrounding organizations (sales, marketing, HR). We did a phased approached where we had a few dev teams run in scrum mode and then gradually had more. This

- Decide if your environment really needs this type of structure. If you are working in a fast paced start-up then consider it more heavily. If you have 200 developers spread across geographic locations then you'll need to do some more thinking.

- Pick your implementation agile and get your team trained. We went with the scrum methodology and hired Mountain Goat Software to do our training. I would suggest inviting a few trusted people from other parts of the organization (sales, marketing, HR) so you can get their input on the impact of the switch

Akw
akw
 
Posts: 63
Joined: Sun May 09, 2010 10:31 pm
Location: Toronto


Return to Development

Who is online

Users browsing this forum: No registered users and 1 guest

cron