©2007 Johanna Rothman
This article was previously published in Better Software, May 2005.
Brent and Deidre, both technical leads, poked their heads in Myrtle’s door. “Myrtle, we have a problem.”
“OK, come on in. What’s up?”
Deidre started. “Remember on our last project we had trouble integrating the entire system? Testing couldn’t start until later than we wanted. And, when they did start, the testers found a whole bunch of things we hadn’t considered? Well, Brent and I think we could be doing the same thing again.”
Myrtle asked, “Why? What have you seen?”
Brent took up the story, “Well, I’m leading a design review with the other middleware developers, and Jon asks me how we’ll get the data from the GUI, and who will verify the data is good. I said, ‘The GUI will.’ Jon said he checked with Nancy, and she said, ‘You guys will.’ So I fixed this potential problem, but there are dozens of others we haven’t talked about.”
Deidre added, “Right, we’re running into the same thing in the backend/database group and with the stored procedures. I discovered one problem, but there are plenty more I haven’t dealt with yet.”
Myrtle thought for a few moments, considering the information her team leads had just provided. She answered, “OK, both of you are the technical leads for your areas. If we bring in Nancy, can’t you three
deal with all of these issues and solve them?”
Brent looked at Deidre, and then shook his head. “No, there are just too many little details we have to resolve with each feature. We can’t do all the design up front. We need a way to interact with each other as we build the system.”
Deidre burst in, “But we have an idea! We can work a little differently, integrating as we build.”
“But, we already build every day. What do you mean?” questioned Myrtle.
Deirdre said, “Right now, the GUI team does all the GUI work for the whole release, the middleware team does all the middleware, and the backend/database team does all of their work. But what if we took each feature, like the one we’re working on now, enabling payment from two sources, and worked on each feature—and just each feature— with a cross-functional team?”
Deidre went on to explain how they could have several concurrent teams working on several features at one time, but with someone from each area—GUI, middleware, and backend—working together.
“If we need a few more people from each team because a particular feature has more complexity, OK, we get more people,” Dierdre offered. “We can use people who are not on our teams to review our designs. But the key is that we implement by feature, not by architectural component.”
Brent added, “But we need testers as a part of that cross-functional team, because we don’t want to wait until all the development is done to test. That way, we’ll know that we’re actually creating pieces that work together.”
Myrtle considered their proposal. “Well, it means our project schedule is toast, but from what you’ve said, it’s toast anyway. It sure would be nice to know that when you guys say the product works, it really works. Can we start with just a piece of the system, maybe the two payment sources piece, just to see if we can do this?”
Brent nodded. “You bet. In fact, if you give me these people,” he pointed to an organizational chart, “I can finish two payment sources in a week.”
Brent arrived in Myrtle’s office four days later. “Hey, Myrtle. We’re done with two payment sources.”
“You are? You’re a day early. But did you test it? Do you really know if this works?”
“You bet we did. In fact, we tested lots more than we normally test, because the tester was able to focus on just this one piece.”
Myrtle was thrilled with their progress, but knew she wasn’t ready to rush a new practice into use across the project without trying it again. She asked Brent to suggest another couple of features on which to try the same practice to ensure that the first success was not just an anomaly. Brent agreed and soon those features were implemented with similar speed and reliability.
Once the other cross-functional teams completed their features better and faster than expected, Myrtle took the risk and reorganized the project to create integrated feature teams, and continued to implement feature by feature. The project was a success.