In my previous two posts (part one and part two), I discussed one of the benefits that Borland derives from delivering working software to customers at the end of each sprint. Allowing customers to try out and provide feedback on sprint builds is probably the most obvious goal of the first agile principle: Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
But Borland also derives other, perhaps less obvious, benefits from demonstrating working software at the end of each sprint. The first such benefit is that Borland's management is able to concretely monitor the progress of a product release. Here's how (somewhat oversimplified).
At the beginning of a release, stakeholders in the application hold an agile roadmapping session. The product of this session is a prioritized list of desired functionality for that release. The product owner further decomposes this functionality into prioritized and roughly scoped user stories. Based on the scoping of the stories and the development team's historic velocity, the product owner is able to draw a line in the product backlog and tell management what amount of functionality the team should be able to complete in the release.
At the end of each sprint, management can see the stories that are checked off the top of the list of user stories targeted for the release and therefore see whether the development team is roughly on track. Furthermore, management gets feedback from customers that the completed stories actually meet their needs.
How does Borland's management benefit from this type of progress monitoring?
For one, they don't panic if a team gets behind on their planned work. Change is a given, not an exception. If a conventional waterfall project gets behind schedule, the entire release is at jeopardy and the only real option is to extend the release date. In the agile process described above, however, only the functionality at the bottom of the prioritized user story list is at risk. Furthermore, management has two options for dealing with this: if they feel that all targeted functionality is necessary for the release, then the choice is to move the release date. If, however, they decide that they can release without the incomplete functionality, then the release date is firm and content is the variable. Since the unfinished functionality was prioritized lowest to begin with, and since so many other company activities depend on the release date, at Borland we tend to assume from the beginning that the release date is firm and functionality is not. This acknowledgment, in turn, affects user story prioritization from the beginning. In fact, for some products, I've seen the product owner draw a 'must-have' line that is well below the team's total velocity for the release, followed by a 'nice-to-have' list of stories. That makes it even clearer that functionality is the chosen variable.
Management's ability to feel confident in the accuracy of their monitoring of product development has been a huge benefit at Borland. In fact, our SVP of R&D, Pete Morowski, has been giving presentations all over the place about the benefits he derives from agile within his organization. In fact, you can listen to a podcast of Pete's thoughts on Borland's Agile Transformation site. (When I've heard Pete's presentations, I have agreed that he's accurately portraying our situation, not sugar-coating it for marketing reasons. That says a lot coming from a cynical guy like me).
How do members of Borland's agile product development teams benefit from all this?
I think the most obvious benefit is the relationship of trust that has developed between management and the teams. Management is trusting the teams to take care of their business and not 'managing' their work so much as monitoring it and changing plans based on their progress. That makes for a pleasant, low-stress workplace.
Comments