How to Double Your Velocity in Sprints?
or ‘How to Design and Develop in the same sprint’ or ‘ How to be truly agile’
Design Thinking and Agile break each other. But they need not. Let’s understand the foundations a little better. I will keep them brief.
Design Thinking
Design thinking framework by the Design Council, UK recommends four distinct phases:
- Discover. The first diamond helps people understand, rather than simply assume, what the problem is. It involves speaking to and spending time with people who are affected by the issues.
- Define. The insight gathered from the discovery phase can help you to define the challenge in a different way.
- Develop. The second diamond encourages people to give different answers to the clearly defined problem, seeking inspiration from elsewhere and co-designing with a range of different people.
- Deliver. Delivery involves testing out different solutions at small-scale, rejecting those that will not work and improving the ones that will.
Design thinking places importance to Discovery+Definition before Design+Delivery as represented by the Double Diamond
Agile + Scrum
Now let’s look at Agile. I have worked only in a Scrum methodology and I will talk only about that here. But whatever I say also applies to Agile in general.
Major scrum events that are followed are:
We will focus only on Sprint. The rest are really harmless.
According to the creators of Scrum, each Sprint has a goal of what is to be built, a design and flexible plan that will guide building it, the work, and the resultant product increment.
Source: https://www.scrum.org/resources/what-is-a-sprint-in-scrum
Here is where things start falling apart
Scrum makes an assumption that the design is done and ready before a sprint starts.
Because design needs to be completed before coding, a popular solution is a dual track process.
Development sprint follows Design sprint like a mini waterfall.
Designers find asking themselves, “How am I supposed to do all the 4 Ds in this time box? Not all problems can be time boxed. We need some time to figure out what the problem, explore, gather insights etc. How do I account for research? Recruitment for user testing? Design iterations? Testing?”
What about Design Sprint? you may ask. It promises one week sprint for co-designing a solution with partners. Design sprint is an amazing framework for aligning different stakeholders on the problem and to validate assumptions with end-users. It’s a discovery framework not a production framework. We will cover Design Sprints later in this article.
Agile is a production framework and it assumes that the Design Sprint is done and the solution is ready to be coded. We are talking about the most impactful way for design to be embedded in dev sprints.
Dual sprint also has efficiency issues. At any given time a designer works on two sprints. Tasks within this design sprint and dev support for tasks done in the previous sprint.
This slows down both design and dev, increases rework and creates bad working relationship between partners because they slow each other down and set each other up for failure.
Expectations vs Reality of the dual track sprints are far apart from each other: (Blue, yellow and green bars represent tasks/stories done in each sprint)
Designers, Developers and QA constantly interrupt each other because they are working on different problems. They slow each other down and set each other up for failure. There is no ‘flow’ between partners.
Discovery vs Production
Not acknowledging that design and design production need to be two different things is the main reason why organizations are not able to find efficiencies in their design operations.
Scrum is a production methodology not a design methodology. But that is not to say that designers cannot work in scrum.
They can. There is a way to do it.
Split Design and Design Production into two streams — Discovery Stream and Production Stream. First two/three Ds from the double diamond happens in the discovery stream and only the last D happens in the Production stream.
But that is not to say that no design happens in production. Tactical design happens in Production and strategic design happens in Discovery.
Discovery Stream
In this stream, teams follow the first three Ds of the double diamond. The designer along with the product owner, design researcher (and in some cases, the developer) co-create the solution. It is a rough + abstract solution to the problem which captures all data points, edge cases, order of flow, some basic interaction design etc.
The designer doesn’t create pixel perfect mocks in this phase but there is a general sense of direction for visual design. This is the perfect time for you to do a Design Sprint. It’s very heavy in logistics and can leave you exhausted if you don’t have a good core team . Seek help from your scrum master and Product Owner to help you with logistics. Seek all the help you can get because Design Sprints are the simplest and quickest way to get alignment on a problem statement and a solution approach. Without these two, dev sprint can become a nightmare.
Alternately, you can be leaner and treat this as ‘refinement’ of your story in a specific format. Basecamp has a great format for this and they call this shape-up. At the end of shape up they create a refined requirement called as a pitch. You may choose to devise your own format based on your context.
In this phase, you may also create wireframes and get tested it with your users. The goal is to determine the functional design of the product/feature along with its dependencies and constraints before it can be coded.(again, not pixel perfect mocks)
This needs to be co-created with your partners. (This is crucial for velocity)
Here is an example of how this may look. I have used ‘enhancement for filters’ as an example to keep this simple. But it can extend further to more complex flows.
Production Stream
Based on the solution agreed during the discovery phase, the PO, designer, developer, QA and A11Y expert (and other relevant players) enter the sprint.
Because visual design and development are happening simultaneously, a lot of back and forth is avoided between the teams and it increases the velocity of the teams many fold.
No more working in two sprints at the same time. All partners are working on the same problem during the sprint. Every decision between the partners is taken as a group during the sprint.
No more final reviews and feedback and rework and all that headache and heartache.
Here is a partial screenshot of a chat between a designer, developer and the A11Y expert:
The team co-locates and co-builds within a sprint and they design and develop simultaneously. Because most visual design decisions are captured in design guidelines and/or the Design Systems, the designer and developer are able co-build the solution together.
Designer and developer share progress every day and conduct daily demos to each other and because of this a lot of visual design fine tuning happens on front end code. The designer immediately updates the mocks to reflect these changes.
This is how the filters ended up looking. Not bad, huh?
In effect, the whole process looks like this now:
I have been experimenting with this model with great success for more than 15 months now. The velocity of the team has almost doubled. What used to take almost 2 sprints now takes only one sprint. It is nothing less than a miracle.
Explore+Shape up first. Build+Iterate later
However, there are some preconditions for this to happen
- Everyone involved needs to be courageous to experiment — Scrum master, PO, Designer, Developer, QA and other partners
- Only teams with mutual respect and curiosity can do this. Warring factions will never achieve this agile nirvana. (Don’t even try this if your PO, designer and developer can’t see eye to eye)
- There should be NO APPROVALS or SIGN OFFS. The teams should be empowered to take decisions and own the risks. Any feedback from leads and management should happen after the sprint and should be taken up as enhancement or bug. The team should be left alone with zero supervision. This is MANDATORY. (Let them do their job. If you don’t trust them, replace them. Just don’t hover over them)
- No scope creep after a pitch is written. Any new requirement or idea should be added as an enhancement (same as agile)
- Read this book. Multiple times. Ask your team to read this. Multiple times. Read till the spirit of ‘shape up’ becomes a natural way of thinking for you.
A huge thanks to Ryan Singer for writing all this down in this amazing book. Thanks to Rami Dahhan for making me read this(multiple times). Thanks to Amir Abura, Justin Jun, Madhumathi Palanisamy, Joanna Kolbe, Ryan Ku, Cody Marshall, Ron Pesano, Pranav Shaligram and the entire dev + QA team for making this theory into practice. Thanks all 🙏🏾
If you are curious to know more details about how we managed to accomplish this and want to replicate this, reach out to me on LinkedIN. Happy to chat and spread the message.
