Agile development spawns requirements, management changes |
 |
By Jack Vaughan, Managing Editor
12 Dec 2007 | SearchSoftwareQuality.com |
|
|
ORLANDO, FLA. -- Programmers drove the first move to Agile software development processes, but non-development team members now take on Agile methods as well. At the recent Better Software Agile Development Practices conference, experts discussed how the Agile movement leads to changes in how managers, requirements analysts, project managers and others approach their jobs.
|
|
|
|
|
With Agile projects, we need to move away from dense requirements documents.
Ellen Gottesdiener
Principal consultant, EBG Consulting
|
|
|
|
|
|
|
|
|
|
Agile processes focus on more testing (as well as more automated testing), faster feature iterations, lightweight up-front analysis, and more autonomy for teams, which are urged to set their own project pace.
Lightness is a watchword. How, for example, requirements gathering is accomplished often helps decide how agile an Agile project actually is. Requirements practices need to be adapted to individual Agile project styles, said Ellen Gottesdiener, principal consultant at EBG Consulting.
Gottesdiener told conference participants that lightweight requirements and, in turn, lightweight models have to be employed where more detailed models and analysis once held sway.
"With Agile projects, we need to move away from dense requirements documents," Gottesdiener said. That may mean filling out fewer forms and using simpler document types. Documents in Agile projects, Gottesdiener added, may include user stories and other requirements that may be represented on index cards and even Post-Its, which in turn may be captured with digital cameras and added to requirements repositories.
Project management goes Agile
AgileEvolution project specialist Stacia Broderick, who formerly served as scrum master at Primavera Systems, said the traditional role of project manager is redefined as Agile comes online. At first, she resisted.
"I used to be a command-and-control freak," Broderick said. "I said, 'You can't just turn people loose!'" But Broderick saw that teams were meeting deadlines, and her views changed.
In Agile projects, "the timing and depth of planning changes," she said. "We can't predict every task along the way. What we want to do as a project manager is set high-level goals and manage to those goals."
The project manager in such a scenario becomes more like a coach -- sometimes the role is known as "scrum master" -- or a guider. Project managers, Broderick said, must let people manage themselves day-to-day.
"Back in the day I thought I could control everything. Now I know differently, and I feel better," she said.
Agile for managers
What is different about Agile for managers? Actually, some of it is familiar, said Esther Derby, principal consultant at Esther Derby & Associates. For example, one of the roles that managers must sometimes assume is the job of protecting their teams from undue outside influence. This takes on new importance with Agile projects in which teams pledge to exercise some self-determination. A manager acts, Derby said, as "a boundary manager."
"That involves keeping distractions at bay and making sure the good [user input] gets in and that the distractions stay out," she said.
Given the still experimental nature of Agile processes, managers must be prepared to champion their teams, Derby added, and, most particularly, to help the team interface with the rest of the organization.
It has always been the case that there are 'steering managers' and 'facilitating' managers, she indicated. The former directs while the later enables teams to be self-directing. It is the latter that is more in tune with the overriding theme of Agile development.
|
|
|
|
