Continuous Improvement of Discovery
A Rude Surprise
A software solution provider hosts a discovery workshop with a new customer to find out what they need from a solution. Stakeholders representing everyone who will use, manage, and support the solution participate in the workshop. They agree on a scope, then find every possible business need within the scope, including exceptions and forgotten cases. All workshop participants share enthusiastic confidence that they covered all the business needs.
The solution provider develops a solution to meet the customer’s needs and delivers it for acceptance testing. The customer stakeholders experience frustration as they test the solution. It does not meet their current needs.
What went wrong? Everyone agreed the solution met the customer’s needs during the discovery workshop. Since then, the customer’s needs had grown and changed, making the solution fall short of what they needed. The solution provider learned discovery should not have stopped with the workshop, even though everyone was sure that they accurately captured all the business needs.
Continuous improvement of discovery stays on top of what a customer needs from a solution, avoiding the rude surprise shown in the above case. The case below shows how continuous improvement of discovery benefited ticket management for a major sponsor of the Olympic Games.
An Olympic Case
I developed ticket management apps for a major Olympics sponsor. They receive thousands of tickets to games and ceremonies as part of their sponsorship. The company has dozens of groups worldwide requesting tickets for the games. They needed a way for each group’s ticket coordinator to easily request tickets online.
When developing ticketing management apps for the company, I had teleconferences once or twice a week with the ticketing manager and program manager. The ticketing manager was the subject matter expert, overseen by the program manager.
Sometimes a new issue or business requirement would come up after a teleconference. If the new issue couldn’t wait for the next teleconference, the ticketing manager and I would discuss it via email. If we had more than ten or so email exchanges about issues between calls, we scheduled a quick teleconference to resolve the urgent issues. While I captured all the issues that arose during the ongoing discovery, we only resolved issues in the current scope. I kept out-of-scope needs for future versions of ticketing apps.
When I delivered a ticketing app, the ticketing and program managers got what they expected because we had discussed it at least once a week.
Continuous Improvement of Discovery with a CAUSE
Development of a ticket request solution in time for the Olympics required continuous improvement of discovery with a C.A.U.S.E.
Capturing and Acknowledging Ticket Request Needs
I collected ticket request needs from the ticketing manager on our weekly discovery calls. I later entered the details of these needs into Elements Catalyst, shown below:
Understanding Ticket Request Needs
I started understanding the ticket request process by dividing it into high-level steps:
Browse games available for ticket requests
Narrow down list of games with available tickets - criteria needed!
Enter the number of tickets wanted for each game
Submit financial commitment
Putting the steps in a process map showed the ticketing manager my understanding in a clear, visual way. Each box depicts a step, connected by arrows labeled with the motivation for each step.
Showing Understanding and Getting Additional Information
While the process map demonstrated my understanding of ticket request needs so far, I had questions for the ticketing manager:
What criteria does a ticket coordinator need to filter the list of games?
What game information should appear on the list?
What are the rules for making some games available to some groups and not others?
I asked the ticketing manager to answer the first two questions by mocking up the ticket request form, showing column headings for game details, and which columns a ticket coordinator could use to narrow down the list. The ticketing manager provided a worksheet showing the columns that should appear on the form, in order. He also specified filter choices above each column heading.
The worksheet illustrated what the ticketing manager and program manager finally wanted. Continuous discovery revealed ticket coordinators wanted to filter their list of games by venue area, or games with medal ceremonies. The original mock-up did not have those filters, so we added them for the developers to implement.
Agile software development arose from the need for software to adapt to rapidly changing customer requirements. It begins most effectively with continuous improvement of discovery, capturing new requirements as they emerge from the customer. Continuous improvement of discovery demonstrates understanding of what the customer needs, so that development can quickly fulfill urgent needs. Customers remain happy with their solution as it keeps meeting their needs through continuous improvement of discovery.
Continuously improving discovery positions a solution to reach its ultimate goal of meeting or exceeding what the customer needs from it.
For a video presentation of this article, see Continuous Improvement of Discovery at Center of Excellence Virtual Summit.