Design Sprint and Dual Track Development

Context

The current typical model of starting a large program is to have a discovery workshop for the program followed by detailed project inceptions. The project inceptions are spaced and detailed.

There are not a lot of discovery workshops we do that is mutual discovery. It is more of sense making of an earlier discovery process.

The Pitfalls and some thoughts

With the discovery process feeding into the project Inceptions was great. it gave direction. However, validation of the direction based on feedback from projects seems to be missing.

The reason the feedback is missing is 2-fold:

#1 - The discovery workshops don't seem to have a cadence with the project Inceptions

#2 - The team that does discovery workshops is to involved with the project inceptions and vice versa,

Some Thoughts around the problem statement

• Not all the discovery workshops are sense making.
• Yes not all of them. We have had the opportunity to work with clients that have involved us in their discovery process. 
• Not all discovery workshops use a separate team.
• Yes, The project team is involved with discovery as well However, the typical structure has been that the discovery workshops tend to morph into a program inceptions.
• Post that, we plan one or more project inceptions. This process does not allow us to have the project teams involved in discovery since the project teams come in a lot later than the discovery workshops.
• Why do you think feedback needs to go from project inceptions to discovery workshops
• What we find during our project execution is also important to consider for the program direction. This might influence other projects in the program as well and hence is important to feed into the discovery process to set the right direction.

A few Ideas discussed

• How do we provide feedback from Project Inceptions to discovery workshops?
• Since the cadence for a discovery workshop is pretty long, the feedback takes time to percolate back. The best way for us to accomplish this is to have a cadence that is parallel to the Project execution.
• We discussed the Dual track development model as discussed by Jeff Patton. We used the picture below for our conversation: http://jpattonassociates.com/dual-track-development/

• What are the Key thoughts of Dual Track Development? [Shamelessly copied from the website]
• Discovery and development are visualised in two tracks because it’s two kinds of work, and two kinds of thinking
• Discovery is a necessary part of product development. Practice it with the same agile and lean principles in mind.
• If we’re doing discovery right, we substantially change and kill lots of ideas.
• While a product manager, designer, and senior engineer may lead and orchestrate discovery, they must involve the whole team in discovery tasks wherever possible. Keep discovery work and progress visible to the whole team.

• Is this going to be time - consuming? It typically takes a good amount of time setting up the discovery workshops?
• Yes it does take some time. We can draw some inspiration from the Design sprint concept that Google venture uses. More information here: gv.com/sprint/

On Monday, you’ll map out the problem and pick an important place to focus. On Tuesday, you’ll sketch competing solutions on paper. On Wednesday, you’ll make difficult decisions and turn your ideas into a testable hypothesis. On Thursday, you’ll hammer out a high-fidelity prototype. And on Friday, you’ll test it with real live humans.