Into the Fire: A Transition to Scrum
Stories Columns Opinions Resources
Sun extends Groovy, PHP support to NetBeans
Version 6.5 of the IDE will see complete support for those two languages along with comple...
|
Sun reorganizes its software production infrastructure
Facing economic hardships, lost revenue and loss of employees, Sun has split its software ...
|
Adobe steers Flash toward RIA implementation
At this year's Adobe MAX Conference, the focus was on Flash, this time making Flash more o...
|
BigLever builds a bridge to SCM with Gears
The Gears Universal Configuration Management Bridge allows CM systems to integrate with Ge...
|
SOA Watch: New economic realities
In the current economic downturn, agile programming and SOA are attractive options that bu...
|
Integration Watch: A new twist on threads
The key to raising the efficiency of multiprocessors is to shrink the overall workload by ...
|
Integration Watch: The Return of NetRexx?
Java scripting languages are seeing a surge in popularity, with NetRexx looking particular...
|
Windows & .NET Watch: Transaction crowd gets a boost
With multicore chips becoming the standard for processors, the need for a flexible, usable...
|
From the Editors: Election should shake up JCP
Rod Johnson has the right ideas for opening up the Java Community Process, and he may be a...
|
Letters to the Editor: Sun gives REST, SOAP choice
A reader takes issue with a headline on our story about Sun working with REST along with S...
|
Guest View: Be smart and lazy
The optimal solution for problems is the simplest one, so always aim to streamline your ap...
|
Zeichick's Take: From EXEC to EXEC 2 to REXX to NetRexx
Andrew Binstock's column last week, "The Return of NetRexx," brought back some fond memori...
|
Practical tips for saving money on code maintenance
If software design is expensive, well, code maintenance is even more so. When you look...
|
Transform your app-dev quality by involving the whole community in testing
As the saying goes, the more eyes you have on software, the shallower the bugs. That’...
|
Build your dev and test labs for less – a lot less – with virtualization
You don’t have the budget to equip developers and software test teams with all the har...
|
Software Common Hacks and Counterattacks: A Guide to Protecting Software Products against the Top 7 Piracy Threats
Software piracy continues to be a growing epidemic. This white paper examines prevalen...
|
By Edward J. Correia
April 22, 2008 —
Last week I wrote from STPCon in San Mateo, Calif., about a brief and telling encounter I had with industry guru Rob Sabourin, lover of Scrum and all things testing. I also promised to share one of his recent adventures in transitioning a test team to the practice.
As part of his consultancy, AmiBug.com, Sabourin helps fix broken development projects. “Several companies have consulted me recently regarding problems in their implementation of Scrum,” he told me. The Scrum process calls for short sprints that deliver working code. A look at one of Sabourin’s stories can help you avoid the same problems these companies faced when migrating to Scrum from traditional lifecycle models. Read all three telling stories in the June issue of Software Test & Performance magazine.
The Case of the Weak Pilot
Sabourin tells the story of TBU, a major data-processing corporation that decided to implement Scrum in an effort to improve its failing waterfall model. The company was experiencing turbulence in its product requirements phase as well as market pressures from small niche competitors who were able to come up with competitive solutions quickly. “Rework due to changing requirements was getting out of hand,” Sabourin explains. “The heavy delivery cycle, although rigorous, was not fast enough to compete” with the newer, more nimble competitors.
TBU’s small software engineering group was dedicated to refining the lifecycle model and excited about possibilities of implementing Scrum, Sabourin says. He also believed that Scrum would fit well with the company’s need to shorten its development times. “Short incremental delivery cycles with working shippable code would be an important part of meeting the new market pressures.”
Though its engineering group is small, TBU runs several dozen development projects at once. “The organization has a rich history in delivering high-quality solutions and has come to depend on its independent testing team,” Sabourin explains.
Indeed, the TBU system testers have saved the day many times, Sabourin says, by finding important show-stopper bugs before release. “The team has considerable political power—and a tendency to block initiatives [that] they feel will risk the quality of product delivery.”
After piloting Scrum for more than six months with a series of three-week iterations, several problems occurred, and Sabourin was called in to perform a task analysis and recommend how to get the pilot project back on track. Here’s what he found:
Pilot Selection and Kick-Off
TBU was careful and inherently conservative in selecting a project to pilot Scrum. It had to be a project that would have minimal impact on the business if it failed, and involve absolutely no lost business. The developers were given basic Scrum training, and one developer was assigned the role of Scrum Master in addition to his normal activities.
It wasn’t until after the first Scrum iteration had started that the testing team was informed of how Scrum would work. “Testers were not aware of the process [and] there was a lot of confusion as to what was expected of testers in the iteration,” Sabourin explains. The testers continued to work in a lab far away from developers, where they couldn’t easily meet or interact.
Double Entry of Bugs
Because it was an experimental project, TBU’s director of testing wanted to make sure that bug and test data weren’t lost at the end of the project. So the testers were instructed to enter all bugs found in the traditional bug-tracking system as well as in the new Scrum tools. Testers managed the double duty of bug and test data as well as documentation of test cases.
Product Owner Absent
Since this was a low-priority project for TBU, the owner was involved with numerous other responsibilities. “At the onset of the Scrum implementation, the owner actively participated in the planning meetings,” Sabourin explains, “but was not available to the team whenever prioritization or clarification was needed.”
Team Interruptions
“The development team was constantly interrupted by support issues, often related to basic system operation,” Sabourin says. Developers normally provided second-line support, he adds, but in this case were continuously being sent calls directly from the help desk. The Scrum Master was apparently unaware of the problem, which chewed up much of the team’s development capacity. But the developers treated the calls as “a necessary evil and a part of life.”
Scrum Master Also a Developer
The work of the Scrum Master was often in conflict, as he was responsible for important development activities in addition to his duties of coordinating the team, representing the team to stakeholders and escalating issues to management. “Should he spend the time writing critical code or helping unblock another team member? The Scrum Master made sure the mechanics of Scrum worked fine, but he neglected to ensure that the dynamics of the team were fluid and effective,” Sabourin explains. "Escalating a problem to management is not the same as solving it.”
Tester Received Builds Too Late
Compounding the confusion caused by involvement in changes after they were already implemented, testers didn’t receive builds until very late into the Sprint. The effective result of this, Sabourin says, was a “microscopic waterfall model within the Sprint. Developers did not coordinate work with testers.”
Their hands tied by late-stage build delivery, testers did little to automate tests, and developers spent little time building a framework to support automation. “No application program interface (API) was established to support automation by developers for their unit testing or by testers to help exercise the user stories,” Sabourin explains. “Testability issues were not found in the project backlog and were never prioritized as part of an iteration.”
Over-Reliance on Hardening Iterations
“In some Scrum projects, an iteration will be dedicated to hardening the code base [and focusing] on bug fixing,” Sabourin says. “Hardening iterations could be used to explore how applications work on different platforms, in different development contexts or when different co-resident third-party applications are running at the same time,” he adds. TBU used hardening iterations as a placebo for traditional system testing.
The Fix
As a result of his detailed task analysis, Sabourin suggested a few changes to make TBU’s Scrum implementation more effective:
1 Make sure the Scrum Master isn’t on a critical path of the project.
2 Eliminate the redundant bug-tracking system.
3 Have testers work directly and in close proximity with developers.
4 Do everything possible to ensure active product ownership. Have the role seconded if the product owner is distracted by other responsibilities.
5 Choose a more important project for the next pilot.
6 Allocate time to support issues before planning.
7 Have testers engaged in the planning meeting.
8 Ensure that testability issues are in the project backlog (trust me, they’ll bubble up in priority quickly).
TBU wisely scraped the initial Scrum pilot, deciding that it would be better to try again with a fresh project. A group of three pilot projects in a much more important product area are underway, using active product ownership. There is less redundant work, but the corporate inertia of the traditional testing role is hovering like a vulture waiting for the next weakness to be exposed.
Pick up the June issue of Software Test & Performance for two more tales from the real world of Scrum migration.
Share this link: http://www.sdtimes.com/link/32068