Creative Sprinting

Creative Sprinting

Reading Time 6 mins

The dictionary definition of sprint is "to race or move at full speed, especially for a short distance, as in running, rowing, etc." Agile methodologies use this term frequently, but organizations such as Scaled Agile Inc. instead use the more generic term iteration to refer to "a standard, fixed-duration timebox during which Agile Teams and ARTs individually and collectively deliver incremental customer value while working towards the PI objectives." The term "sprint" may imply a sense of urgency that can cause anxiety or stifle divergent thinking because the goal of each timebox is not to increase understanding but to instead move the needle by delivering increasing "customer value" through working software. This same term also implies a solo, rather than collaborative, endeavor. I rather use the metaphor of the relay race because the work product (baton) is passed between team members. Not everyone is moving at full speed, only the person with the baton. So, if every iteration is more like a relay race, what are some creative ways we may utilize our time in an iteration? I offer a few ideas that I wish we had time to teach in the joint course both LACE and HCD Centers of Excellence offer, entitled Better Together: Achieving great outcomes with Lean, Agile, and Human-Centered Design.

SPRINT 0

A "sprint 0" is used as a way to help teams organize themselves and set themselves up for success before a project's development begins. This takes team members out of their typical roles and gives them an opportunity to conduct one or many activities, including:

• Reframe the problem: Product Managers are charged with identifying feature level work items and prioritizing this work before the Program Increment (PI) begins. But what if they have only communicated the work to be done rather than the problem to solve or the goals of the PI? Product teams may use Jeff Gothelf's Lean Canvas and perform activities appropriate in HCD's defined Initiate Phase to really gain alignment by answering the why.
• Implement improvements: Good product teams hold iteration reviews and inspect and adapt (I&R) ceremonies as a way to continually learn and improve as a team. Other team building activities, including creating or updating working agreements can improve team culture and productivity.
• Design Sprint or Code Jam: During a sprint 0, full teams can innovate by being presented with a challenge, which may even give the team a head start on a PI's planned work. This can manifest itself either as a time to create multiple design ideas for feedback or workable software.

Since a "sprint 0" is technically not a development sprint, it may be structured in a variety of ways, including:

• At the beginning of a PI: Some teams might build a no-code iteration to focus on aligning as a team and determining the research and design needs prior to beginning development.
• At the End of a PI (see graphic): Some teams might take a 2 week I&P iteration (as seen in the above graphic), usually the last iteration of a PI, and use one week for PI planning and another week to focus on innovation. This sprint 0 can help teams hit the ground running when they begin the next PI.
• Outside of a PI: Without disturbing the normal cadence of a Program Increment, leadership may decide to host a sprint 0 at regular intervals, such as quarterly, semi-annually, or annually, as a way to align the team and refocus on priorities.

DESIGN SPRINT

The Design Sprint, attracting attention in Jake Knapp's Sprint: How to solve big problems and test new ideas in just 5 days, argues that teams can be very effective if they spend one week before development creating a highly collaborative atmosphere by solving a real-world problem broken down into the 5 day work week:

• • • • Monday - Map and choose a target
      • Tuesday - Sketch competing solutions
      • Wednesday - Decide on the best
      • Thursday - Build a realistic prototype
      • Friday - Test with target customers

LEAN UX RYTHMS IN EVERY SPRINT

The previous ideas tried to carve out one moment in a development lifecycle (i.e., Program Increment), when design thinking could be applied to better understand a product's consumers, create a workable solution, and gain user feedback, which would help the product team learn from the experience and improve their future delivery. The problem with these solutions is that while they may be good temporary moments that might help product teams improve upon the way they predict what work to tackle, collaborate on getting their work done, and learn from this one a PI activity, true prediction, collaboration and learning must be applied continuously throughout a Program Increment. Jeff Gothelf, in his book, Lean UX: Designing great products with agile teams, argues that there are other ceremonies we may add to sprints to aid and mature a team's capacity to predict, collaborate, and learn. Some examples include (also, see graphic):

• Ideation/Sketching: Before iteration planning, include an opportunity to ideate and sketch solutions, which may impact development in the current or a future iteration.
• User Testing: Include regular user testing, where all members of a team are required to observe users at least 2 hours every 6 weeks.

BUFFERED SPRINTS

In contrast to baking in these rythms within a sprint, another approach is to pull them out of a sprint by creating a gap of 1-3 days between sprints where ideation, planning, and user feedback sessions take place without impacting team members' commitment to their craft. For example, if engineers on a team have committed to coding a feature in two weeks, only to be strongly "encouraged" to collaborate with usability researchers or observe a user test, chances are they may be disincentivized. They may reason they are getting paid to code, not to participate in activities that are not part of their job description. On the other hand, if there is a formal 1-3 day gap between sprints where an engineer is instead required to participate in ideation, planning and user feedback sessions, then the incentive is there.

CONCLUSION

Whether it feels like a sprint or a marathon, product teams run a relay race, where the baton is really the incremental work products that lead to working software. Mature teams know how to accurately predict their work, efficiently collaborate by fostering a culture of shared responsibility, and learn and improve team efficiencies after each iteration. This is accomplished by respecting the roles and capabilities of each member of the team and finding creative ways to mature your team's working relationship and product outputs throughout a product's design and development lifecycle. If you want to learn more about effective ways to integrate research and design into agile cadences, check out the CCSQ Center of Excellence training offerings or reach out to us for a consult.