I led the product delivery team to create software that was fit for purpose using lean methodologies. My role in the beginning was to teach my team and stakeholders how to run design sprints and guide them to the process. At the beginning my role was really hands on, helping with almost all the activities in the design sprint but with time, my team got a hold of the process and they were running with it, which allowed me to detach a bit from it.
The biggest win was to get a really big team working together harmoniously with a common goal, which in Canon's complex environment was daunting and seemed far-fetched.
Just as I did in ‣ with the ‣ and Gavelytics with the User Centred Design process I followed. Canon was not too different, only better. This process is a continuation of the work done in Product Strategy.
At a very high-level, this is how the Design and Development process looks like. Design and Development Sprints running in tandem. Sprints lasted 2 weeks and take ambiguous roadmap items as input.
I used this graphic to help stakeholders that were not that close to development, how would tackle the design and development process.
This process is my own take on Sy and Miller’s “Staggered Sprints” model.
As mentioned before the purpose of a Design Sprint is to take an ambiguous roadmap item and convert it through its processes into a design and development specification.
Then of course, the purpose of of the Development Sprint is to convert that Design and Development specification into tested working software features.
To reduce the risk of producing foul software we test during both, the design and development sprints, this will help identify flow gaps and reduce user friction before creating the spec, and at the same time the development sprint is tested for logic and runtime bugs to make sure that the outcome of the effort is optimal.
I have already showed you what the Staggered Sprint approach looks like at a high level. Now let's deep dive into the details of what happens in the design sprint.