New Roles, Rules Take Getting Used To

Dealing with 'people' issues hardest part of agile adoption

By Jennifer deJong

January 15, 2008 —

Every organization that embarks on agile development finds itself in uncharted territory. Bosses no longer call the shots. Analysts, developers and testers team up and wear one another’s hats. And business stakeholders are asked to participate in software projects more fully that ever before, often putting their day jobs on hold. Navigating these new roles and rules of agile organizations feels unfamiliar, and often uncomfortable.

That’s the conclusion SD Times reached based on interviews with more than 20 analysts, consultants, developers and tool makers involved in agile projects.

One of the first things teams discover is that existing job roles correspond with project stages of waterfall development: analysis, architecture, coding and testing. That’s a poor fit for agile, where team members are asked to do a little bit of everything, said IBM Rational practice leader for agile development Scott Ambler. “Agile teams need generalizing specialists.” But that role is hard to come by, he said. Instead, teams struggle to align outdated roles with the new development approach. “What happens to the business analyst?” Ambler said. “Agile says: ‘Do analysis 20 minutes a day. The rest of the time you write code.’ That is pretty tough.”

It’s so tough that some agile teams choose not to adhere to that particular practice, said Ray Goodman, a senior vice president for inventory software developer Direct Tech, which adopted Scrum a couple of years ago. “In theory, Scrum team members pick the tasks they want to do,” he said. But in reality, people stay within their areas of expertise. “We have user interface experts, database experts [and so forth], and agile hasn’t changed that,” he said. “They stick with what they know.”

Goodman hasn’t had that luxury. The Scrum practice of self-managing teams has changed his role drastically. “I can no longer say: ‘Do this, and do that.’” When problems cropped up in the past, Goodman solved them by delegating tasks to team members. Now he retreats to his office and lets the team come up with its own solution. He is committed to the new way of working, even though he admitted it feels “a little scary, almost like you’re losing control.”

For developers on agile teams, nothing feels more unfamiliar than pair programming, the Extreme Programming (XP) practice whereby two developers write code together at a single workstation. “Every minute your ideas are challenged, and you have to explain them to someone else,” said Oxygen Media software developer Wendy Friedlander.

The cable network adopted its own variant of XP, which includes some Scrum practices, in January 2004. Even though Friedlander said pair programming “feels strange all the time,” she likes it. The Oxygen team of eight changes partners once a day, and that results in better software, where each feature is carefully thought through. “When you are working alone, it’s hard to tell if something you have done—such as the placement of a control—will confuse the intended user,” she said.

“But with pair programming, the whole team is thinking about [this issue],” added Oxygen software developer Oksana Udovitska. “You let go of ownership of your code and come up the best solution. When you’re working alone, you can never be confident of that.”

Friedlander noted that a common objection to pair programming is that the technique is inefficient, that a developer working alone can write code faster than two working side by side. But the benefits are counterintuitive, she said. “You gain things you would never gain otherwise.” For instance, there is no need for the team to stop work and discuss an application’s design. “When you are switching pairs [once a day], you know.”

Pair programming with pair switching gives management a better handle on what’s happening, too, said Oxygen vice president of software development Ken Judy. “At some level, you have to try to understand what each individual is accomplishing. In pairing, discussions over what each developer is doing are inherent.”

Geared to Avoid Conflict
Pair programming has a love-it-or-hate-it reputation. But even agile practices that don’t inspire that reaction force developers to abandon customary ways of working.

Direct Tech’s Goodman offered an example. Scrum mandates that developers focus on one task at a time. That is harder than it sounds, he said. “Let’s say the task is ‘add a new customer.’ The developer does that. Then he thinks to himself: I might as well do the update customer function and the delete customer function at the same time.” This feels more efficient. But in agile, where tasks are defined in a much more granular manner, it’s not, Goodman said. “In the long run, we get a [better] add function, a [better] delete function, and a [better] update function.”

One change that impacts every agile stakeholder is learning how to accept criticism and act on it constructively, said Agile Infusion consultancy owner Bob Schatz. Agile is all about feedback, and soliciting it early and often is crucial to keeping projects on track, he said. “If the users [you are developing for] don’t like what you’re doing, you will know within three weeks,” he said. But for most people, negative feedback is hard to give and hard to hear. “It makes people uncomfortable,” said Schatz. “We are geared to avoid conflict.”

Showing the customer what the team has come up with is indeed nerve-wracking, said Oxygen software development manager Luke Melia. “You hope that nothing blows up.” The Oxygen team meets with the business stakeholders every two weeks, and over time mutual respect has developed, he said. “There were meetings where the business thought we had worked magic.” One didn’t go so well. “We didn’t get it right at all,” recalled Melia. “We had underestimated the difficulty of the task. I felt terrible. It was uncomfortable. But I took it much harder than the customer did.”

Step Up to the Plate
Agile puts the business stakeholders in the hot seat, too. “They have to accept that the developers aren’t just order-takers,” said Greg Reiser, vice president for consultancy Thoughtworks. When new requirements come in, a dialog ensues, trade-offs are discussed, and a decision on how to proceed is jointly reached, he said. Brian Carter, a vice president for consultancy Sapient, agreed. “Business stakeholders have been asking for more involvement in application development, and agile gives them that.” But it also demands more time, dedication and focus than has traditionally been asked of them. Getting business stakeholders to commit may mean getting the boss involved. “You have to take that person out of the business and dedicate his time to [the agile effort], said Carter. “It’s hard to succeed if the business stakeholder has a day job.”

Getting everyone to show up is only half the battle. Also key is making sure the business stakeholder’s interests aren’t misaligned with those of the developers. Outdated reward systems are not always apparent, and they can undermine or even derail agile projects, said Sapient senior manager Erik Gottesman. He offered an example. “A development project has two stakeholders: one from the business, the other from IT. The business guy’s success is measured by how many features he can cram in. The IT stakeholder is rewarded according to how many delivery dates he makes.” That’s disastrous for agile projects, he said. “The business pushes for new features that aren’t needed, and IT focuses on meeting deadlines, instead of delivering [exactly what the business needs].” That is the worst way to organize intellectual work, said IBM’s Ambler. “We need to change our ways.”

What’s the right way to reward project stakeholders? “There are no perfect solutions,” said Gottesman. “You need to quantify the business results you seek to realize from features, in financial terms.” Also important is deciding how to evaluate the performance of each member of the agile team. “You don’t want to judge them solely on their individual merits,” said Agile Infusion’s Schatz. He recommended a three-part plan: one-third is the team’s overall performance, one-third is how well the individual works with team, and one-third is the individual’s skills in core areas of expertise, such as QA or coding.

Agile’s success depends heavily on how well team members interact with another, and on the team’s ability to resolve conflict, added Schatz. “If all you know is Scrum [or any other agile methodology], you are in trouble.”

Share this link: http://www.sdtimes.com/link/31657

Innovations Software enables business rules collaboration Visual Rules Enterprise Platform 4.3 provides tools for helping users create and alter business rules by managing access control and auditing changes to rules. The visual designer is based on Eclipse.

Zeichick’s Take: New Year's resolutions Alan runs down a list of things that software developers should resolve to do this year

Zeichick’s Take: With Touch, we get a new feel for Windows Microsoft's pushing of its touch technology is a welcome project from the software giant

Add comment

Name*
Email*
Country

Comment
Preview

News on Monday
more>>
SharePoint Tech Report
more>>

Download Current Issue
ISSUE 3/15/2010 PDF

Need Back Issues?
DOWNLOAD HERE

Receive the print Edition?

Google Code turns 5
Google Code Turns 5, and adds a Paxos Algorithm to make the system more stable and reliable.
03/17/2010 11:16 AM EST

Test your Visual Studio 2010 know-how
Microsoft is offering free beta certification exams for Visual Studio 2010.
03/17/2010 11:08 AM EST

Microsoft lifts the hood on IE9
Microsoft is previewing IE9.
03/16/2010 01:10 PM EST