Design Sprints: Steps Involved
(Image courtesy of UXM)
One of the most talked-about areas of Agile today is the Design Sprint. Design Sprints enable teams to use the same processes and terminology that IT teams use within Agile Scrum. The goal is to foster better communication between business and IT by creating parallel processes that complement one another. At OneSpring, we’ve witnessed the struggles our clients (unfortunately) experience on a daily basis as they try to integrate Agile into their organizations.
Although there are many benefits to Agile Scrum, there are still opportunities to improve the process. Scrum – an IT-centric software development approach – doesn’t clearly take into consideration business environments and how needs are organized and communicated from the top down. Product Owners, who represent business needs and goals within an Agile Scrum project, are charged with overcoming this hurdle. Product Owners are responsible for determining what’s being built, its acceptance criteria and its prioritization.
There’s a tremendous responsibility on behalf of the Product Owner to continuously “groom” the Product Backlog to ensure the development team has sufficiently prioritized work on each Sprint. In addition, the Product Owner needs to be available throughout the Sprint to help clarify questions as they surface. In our experience, the Product Owner is typically not dedicated to the Scrum team and therefore rarely has the time to fulfill these responsibilities. As a result, the quality of work may diminish – causing “spikes” in the Sprint to surface, which leads to rework. In the worst case scenario, the project is completed, but not successful. That’s because what is built still doesn’t meet the expectations and needs of the business. Many organizations have attempted to become Agile, but still have project failures. They’ve experienced this cycle firsthand. Agile oftentimes increases the speed of output, but doesn’t guarantee the output will meet the business needs of a complex organization. Let’s dive into an example by contrasting Agile Scrum with other industry processes.
In most product development industries outside of software, the business has greater support and ability to plan the design of what is to be built prior to starting the development or build process. For example, if you want to build a house you would most likely meet with an architect and spend time upfront visualizing the design of your house based on your family needs/wants and ideal lifestyle (room layout and flow, windows, dimensions, etc). You would then bid out the work to a builder/developer who would rely on the architectural plans to produce the house. You as the homeowner would continue to be involved throughout as changes surface and decisions need to be made. The architect would be consulted with throughout the project to make sure the design stays true to the original intent. This process has been proven to work for many decades. The primary change that has occurred over the past several years is the technology used to produce architectural blueprints and designs has gotten much more sophisticated for all parties to be involved in the process. In other words, technology has made it more transparent, faster and cheaper to produce designs. These advancements are just as relevant to the software industry as they are to the construction industry. Scrum is all about iterative development which allows teams to produce working code faster and in smaller portions to help drive user engagement and increased transparency.
Even though the construction process mentioned above is similar to software development there are some key differences worth pointing out. First, the process to build a house is design focused, not textually based. Initial designs are sketched on paper then translated to Computer Aided Design (CAD) software later to identify specific measurements and constraints. The homeowner gets to see and experience the design and work out as many issues as possible prior to construction beginning. If the homeowner were to try and do this directly with the builder onsite, the cost would be exceedingly high in terms of time and money. The need for rework would inheritably drive up the cost and the homeowner would end up with a finished product that most likely misses the original intent or vision. This is precisely why a large portion of time is spent upfront designing and planning what needs to be built.
The lesson with all of this is the more time spent upfront fine-tuning the design, the smoother development will proceed. This same premise holds true for software development projects. In an Agile Scrum model the developers rely on User Stories to flesh out user needs, which are primarily written by Product Owners or Business Analysts. I won’t delve into all aspects of User Story techniques in this article but want to at least review the approach. The issue with User Stories is that they are based on myopic views of the system. In the house construction example, it would be like telling the architect how the kitchen utensil drawer should work before there was a shared understanding of a room in the house called the kitchen, where the utensil drawer would reside. In order to gain better insights, we have to move up a level to view all aspects of the software application in a single and holistic view. Agile Scrum attempts to do this via something called Epics, however, it is still difficult to clearly articulate and understand the business needs based on this high-level view. In construction you can see and touch the plans, which drives user engagement. You can visualize how people will flow through the house and how it will be lived in on a daily basis. The process of engagement is critical to construction as it is for software projects. In software, user research and usability studies are employed to help facilitate this but are sometimes injected too late in the process. In Agile Scrum, the intent is to break apart development into smaller portions so IT can test early and often to gain insights and validate user needs. In our opinion, this discovery should happen much earlier in the design phase. Therefore, this led us to evolve and enhance the process by using the Design Sprint.
The most notable organization using this technique is Google Ventures (GV). Their challenge was finding an effective and quick way to help validate business ideas and promote business decision making for their portfolio. The Design Sprint was created, tested, and proven in over one-hundred sprints with various businesses. The key value the Design Sprint provided was the ability for teams to learn and validate their business ideas without expending the time or money of building and launching a coded product first.
The sprint gives teams a shortcut to learning without building and launching.
GV’s Design Sprint focuses on a 5-day session primarily used to validate ideas. This is great for high-profile quick hit concepts but what about longer term complex systems? To account for this, we have adapted and enhanced the Design Sprint concept to better fit into complex organizational environments. Regardless of variations, the core tenants of the Design Sprint are the same. The goal is to perform a time boxed design effort to flesh out software details using the latest in design techniques while increasing user engagement and adoption. For example, Rapid Prototyping and Visualizations can be used to gain insights on the design and how software should function prior to development. The primary benefits include: consensus building between business and IT, adoption of Agile across the organization, and reduced rework.
The Design Sprint Process
OneSpring will be releasing more articles on these concepts over the coming weeks, but let me touch on one of the benefits now. Adopting Agile across the organization is one of the more challenging components most organization face. The reason for this is that Agile Scrum is an IT centric approach, which in many cases ignores the integration of business and cultural standards and norms. For an organization to successfully adopt Agile, it must consider how other areas of the organization may be impacted. Design Sprints are inheritably more business side focused because the fundamental tenants are based on fleshing out user needs and increasing engagement. If you think of user engagement as a model along with development time the graph would look something like what is outlined in Figure 3.0 below.
User Engagement versus Development Time
As user engagement increases, development time decreases. This applies to the home construction example as well to a limit. However, you can only drive down development time by so much before quality suffers. You must consider the law of diminishing returns when adding more resources to a project. Therefore, the intent is to strike an equilibrium between too much user engagement and too many developers. Excess user engagement can lead to analysis delays and overthinking. Design Sprints are meant to establish this equilibrium and to increase Agile adoption by creating a common language and procedures across the organization. Design Sprints incorporate the same language and procedures as Development Sprints. What differs between the Sprints are the outputs. For example, in a Design Sprint an output may be vetted User Stories or screen mockups, where as a Development Sprint would be finished code. The intent is to create parallel procedures using the same language and practices aimed at establishing standard processes at the business and IT levels. In time, this helps educate IT and non-IT participants which leads to greater understanding and productive habit-forming behaviors.
This article is the first in a series of articles aimed at educating users on the merits of Design Sprints and how your organization may be able to leverage some of these insights to be more successful.
