This chapter is from the book
This chapter is from the book
This chapter is from the book
Respond Empirically
After ten days, the team started to feel like it was going to fail. The technology was all up and working, it had figured out the Corba wrapper, and it had accessed the appropriate databases. However, team members felt that they couldn't get the entire selected customer service transaction set mapped and linked to the database within the Sprint. The transaction data was too complicated and involved too many tables and indices for the mapping to be completed in thirty days. The team had incorrectly anticipated the complexity and the scope of the work it had assigned itself. But had it failed? Not in the eyes of Scrum. Working with a host of difficult technologies and unknown transactions, the team had built the development environment, put up a middleware server using Tuxedo, and had started implementing the customer service transactions. It was doing great. The team had done the best that it could do, rather than sitting around and doing nothing.
Again, I focused the team on the art of the possible. What could it do within the Sprint to meet the goal? The goal wasn't to complete the entire transaction set, even though that was what the team had expected to be able to do. The goal was to prove the viability of a middleware object server providing database access to the customer service transaction set. No one even knew whether management would approve and fund this approach. The team quickly identified that they could address a reduced scope of transaction data elements involving fewer tables and indices, and then proceeded to automate this.