Incremental Product Delivery
At the End-of-Sprint demonstration, the team really impressed management with its pragmatism. With only the resources it had on hand, it had proven that its approach was technically feasible. In fact, it had put the technology to use for customer service functionality. Although a thorough requirements study might have uncovered better technical approaches, the team had used available resources to solve the problem both for the customer service team and for the company as a whole. The team had run performance measures on its solution and proven that the approach could handle the expected transaction volumes. In an online session, it showed management part of the transaction going through the middleware to the databases, retrieving and displaying selected data, and doing so with performance and scalability that could be sustained.
The team presented an increment of product that was successful, could be discussed, and could be built upon. If the team had not gotten its act together as well as it did, the organization as a whole would have been thirty days closer to a transaction volume meltdown. Instead, because of their efforts and initiative, the organization had something that worked and that could be modified and built upon. Incremental product delivery can be very powerful, providing an organization with real progress in a short period of time. Previously, the organization was wrapped around its spokes discussing how to proceed.
The team had provided a starting point, a prototype that validated the approach and could be built upon. The team quickly gained formal status and funding, and eventually came up with a solution for legacy database access.
By using Scrum, the team was able to cut through the noise and start delivering valuable product. Time that would have otherwise been wasted was spent working. The team was able to focus itself and management was able to help the team stay focused. The team continued for another year, building a general-purpose middleware business object server with access to specific databases. The team members then became consultants to other organizations that used the middleware. As they consulted, they spread Scrum.