 | |||
|
|
||
| |||
| |||
| |||
|
||||||||||||||||||||
| |
|
Home > Software Quality News > Turning agile skeptics to believers at Blueprint Systems |
| |
|
|
|
|
| Software Quality News: |
|
||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||
But when he took the chief technology officer job at Blueprint Systems a year and a half ago, he also had to make believers out of everyone there in order to effectively change their development method from waterfall to agile. Buy-in, he said, was critical. "First I had to get buy-in at all levels; it was not just an R&D initiative," Crisp explained. "I had to convince the other executives that this is the way to build software to give us the business benefits we were not seeing. Testing, product management, documentation -- everybody needs to buy in, even the sales team, because the way you build software is different." Then he had to hit the road. The new guy had to tell the team in Russia they were changing the way they did development. "It was interesting to do [this] with a team I hadn't worked with," he said. "The team was offshore and I introduced a new way my first month." Crisp walked the Russian team through the basic principles of Scrum, went through a few examples, and "just started," he said. "We had to jump in with both feet." The result? "We didn't do very well to begin with. People tried to do classic waterfall in agile iterations." But over time they all learned the principles. He said the group embarked on its agile journey by starting with a small release that took about three months, "to get them used to thinking and behaving in an agile way." Blueprint has about 21 developers and testers in Russia, and the rest of the 30-person development organization is onshore. All business analysis and product management functionality is done in Canada. They are primarily a Java shop using the Eclipse IDE, but Crisp said they do have a few .NET components; they have scrum of scrums leaders both in Canada and Russia. While having colocated teams is the ideal for agile, Crisp said, "we live in a world where software is built in a distributed way. It doesn't matter if it's waterfall or agile, you need to deal with distributed teams." So distributed teams have to adapt agile to fit their needs, and communication is key, he said. Blueprint uses the classic mechanisms for distributed teams: telephone, IM, videoconferencing, Skype and so on. But the team also uses its own product, Blueprint Requirements Center, to automate the processes of requirements elicitation, elaboration, validation and acceptance. "What our tool does is take the requirements we need to communicate to Russia, where the coding is done, and puts them in a form easily communicated," Crisp said. "We never produce a document for requirements; it's always in the tool. We review and simulate using the tool, but we never put it on paper. We just don't find that valuable." Crisp said developers, testers and product managers are all involved with reviewing the requirements. "Testers and developers think differently, so it produces a more validated spec," he said. One experiment that didn't work, according to Crisp, was having the testers write the formal requirements models used in the Blueprint tool. "We still need to have business analysts do that. The testers need to give feedback, but not drive the process." The role of quality assurance (QA) and testing, however, has changed as a result of agile, Crisp said. Just putting testers and developers in the same room together changed the dynamic. "The behavior before was that the developers would write code and use testers to find bugs," he explained. "That doesn't fly for me as agile. Testers aren't there as a compiler. I wanted to foster a team. I want testers to feel good when they find a bug and developers not to feel bad when testers find a bug. It's a change in camaraderie. Physically putting them in the same room was a big step [toward] a joint ownership." QA is also involved much earlier, from the first sprint, he said. Blueprint does daily builds using test scripts and Apache Ant. "Were continually testing through the whole lifecycle versus at the end, which doesn't work that well." In terms of the process, they started with four-week sprints but moved to two weeks, because developers think they can get a lot done in four weeks, Crisp said, and so tended to overpromise and underdeliver. "We reduced the sprint to eliminate the problem, and [estimates] got more accurate," he said. "Now that they're more accustomed to agile we will go back to a three- to four-week sprint. It gives them more time to stretch their legs and get stuff done, and be more self-directed." Blueprint completed six releases in its first year of using the agile methodology, compared to a previous average of one release every year and a half. This year Crisp expects to do four releases. The upshot, he said, is that agile increased velocity "by whatever we decided it to be," as well as enabling adaptive planning. He cited as an example an eight-month major release project that changed direction to a minor release because of market changes. "In month 2 we decided we wanted to release at the end of month 3, because that's what the market needed. Try doing that with waterfall; it just can't happen. That's where adaptability comes in to play; [agile] really does work." Crisp believes that putting out fast releases that are in line with what customers want has contributed to Blueprint's triple-digit sales growth. "It's all about reducing waste and focusing the entire organization on building the things that are most important. That's the spirit of agile," he said. Spoken like a true believer.
|
|
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
About Us | Contact Us | For Advertisers | For Business Partners | Site Index | RSS |
|
|
||
|
|||||||
