Agile Processes Mean Developer
Accountability"> So, have you found developers in non-agile-development shops defining their success in terms of producing code rather than actually meeting the business goal? In a waterfall model, [developers are] pretty insulated from accountabilityand they like that. Its not that theyre slackers. Its not that theyre not doing a good job. Its just the basic nature of engineers to be conservative and nonconfrontational.Doesnt a label like "scrum" hit all their hot buttons at once? Isnt it a red flag saying, "Youre going to be right in the thick of all the hard parts of the process, as exposed as any product manager or business process owner to the volatility of the environment?" It does say that its a team activity, that everyones accountable and visible. It fits very well. If youre talking to a manager whos heard the distant drums of agile methods, how would you pave the way for that manager to start thinking about agile adoption? What potential concerns or misperceptions would you want to head off before they have time to take root and get in the way of that process? There are lots of things involved. I think the biggest misconception is that agile development puts out a lot of junk code, that its a down and dirty way to get a product out faster, and quality be damned. I think one of agile [developments] greatest strengths is that it brings much better quality into a productand all engineering managers really live for quality. When they understand that agile [development] will give them better quality in their products, they start to buy in very quickly.
Guru Jakob Nielsen offers advice on designing applications for usability. Click here to watch the video.
So, would you tell people to promote agile methods for quality improvement rather than schedule improvement?
Absolutely. Theyll get much better acceptance from engineers and from engineering management with that approach.
Do people think of agile development as depending on close collaboration, using techniques like putting two programmers on a workstation or having regular morning huddles? How well does that fit with a geographically dispersed development team using outsource talent?
Its certainly throwing in all the challenges you can when you go to that [distributed] modelbut weve demonstrated for 18 months that you can do it. The key to agile [development] is about communication, not about location: that daily phone call for 15 minutes.
It wasnt just [the challenge of developing in] Russia. We also have engineers in Canada; Portland, [Ore.]; Denver; Salt Lake City: five locations where were working. Its [about] the visibilityeveryone seeing whats expected and how to go forward.
Theres typically a one-month development cyclewhat agile teams call a sprint. The teams have their daily calls, but theyre isolated during that monthexcept that we do it in two weeks. Theres more of a chance to get off track when youre distributed, so I wanted two-week visibility into the progress we were making.
We structured the working schedules at all the locationswhich was a challengeso that they had a good hour and a half overlap in the development day. After the daily 15-minute call, there was time for e-mail to get into more detail and follow up. We facilitated very strong daily communication.
We had a two-week sprint, where at the end of the two weeks we did a Web session where everyone saw what was being demoed and everyone participated. It gave a sense of one team at one location, even though we were spread around the globe.
At IBM, at one time I had engineers in 32 different countries working on the same piece of code: Im used to facilitating distributed development.
Have a comment or suggestion? Please e-mail Solutions Series Associate Editor David Weldon at email@example.com.
Check out eWEEK.coms for the latest news, reviews and analysis in programming environments and developer tools.
Agile [practices] make every person in the process accountable: every product manager, every engineer, every QA. Thats what makes people uncomfortable, initially.