How to Foster Agility in Fixed Scope Projects – Part Two

Innovating Our Process with the Design Sprint

This is the second half of a two-article series on applying design thinking methods with deliberate constraints to increase agility, specifically in fixed-cost fixed-scope projects.  In part one, we discussed how design thinking methods, specifically the Discovery, help us mitigate risk while increasing our agility by using deliberate constraints. In part two, we further explore our opportunities as Product Managers to innovate the most important tool we have, our process.

The design sprint process during Discovery allows for rapid prototyping in order to find a solution quickly. By employing this same design sprint process during the delivery phase of a project, I have found that this has allowed my teams to maintain an agile, user centric approach within the constraints of fixed-scope fixed-cost projects.

Our Design Sprint Process Leads to Innovation and Agility

The design sprint was created by Google. Put simply, it is a set period of time to ideate, prototype and test ideas. The specific period of time is typically a sprint. A sprint is a repeatable fixed time box used in SCRUM, usually constrained to two weeks. It is deliberately short so we don’t over commit and we get working software as quickly as possible.

During delivery, product and design lead ahead of development so we can be a little more flexible with our process. Here’s how it works:

We don’t track how many design sprints it takes to get to an approved design, we make sure we get an approved design by the end of the design sprint. This deliberate constraint is where process and design changes the game for fixed-scope projects. The design sprint process is the innovation and agility in the fixed-scope fixed-cost project.

The design sprint begins with the highest priority feature, which is agreed upon during Discovery. As a team you walk through the feature and requirements and agree when we have enough requirements to get the designer(s) started. The designer might lead collaborative workshops to dive further into the ideas for the feature, or they may decide to work heads down. It depends on the requirements we have and the solution we are designing. This creative process results in a wireframe that meets the business requirements and is considered doable by our technical SMEs and leads.

The deliberate constraint of the sprint being so short, and the team committing to delivering a solution by the end of the sprint forces the designer to make design decisions that keeps the fidelity of the solution easy enough to complete in two weeks. The cross-functional team ensures that the development effort is equally manageable since you’re all focused on getting a solution approved in a short period of time. The client approves it, and then those features are broken down into user stories and moved into the development backlogs for the software delivery lifecycle to begin.

Learn fast and iterate accordingly

This is not a problem free process. Typically, agility encourages mistakes and lessons because that is how we learn and improve. This short time frame allows us to realize mistakes early so we can learn fast and iterate accordingly, always improving our product and our process. So, what’s the catch? It’s simple if everyone is invested in this rapid design process.

In order to be successful, there are some key areas that should be prioritized as a team:

  • Commitment from the client
  • Lead with a Product and Design-driven approach
  • Avoid Product vs Technology Silos
  • Commitment from the designer(s)
  • User Testing
  • Cross-functional collaboration

Commitment from the client: This approach takes commitment from the client. It is not easy to prioritize what is minimally viable but it is essential in fixed scope projects. This is a mindset that is not easy to adopt.

Lead with a Product and Design driven approach: Conversations easily move to technology and what this needs to do on the backend can quickly take over. Viability is just as difficult for a solution architect. We all want the best experience, so it takes commitment from everyone and strong facilitation to drive conversations to viable outcomes. Otherwise you get caught in the details– details that might not have an impact on your customers’ experience.

Product vs Technology Silos: Without commitment to the process from the cross-functional team, the very important considerations of implementation can get missed and you may find yourself with changing requirements mid development sprint, and all the other well documented problems of working in silos.

Commitment from the Designer(s): Constraints aren’t for all designers. The designer must be committed to minimally viable solutions and not the absolute best user experience possible.

User Testing: Not all organizations have access to their users and setting up user testing can be time consuming. Ideally, you can throw a design in front of a user and get some feedback. Typically, a small set of five to seven users will provide you with enough meaningful feedback. If you can’t do this it is advisable to at least learn about user behavior with analytics, through user experience audits of the current application, by checking out your competitors’ products or sending out surveys that focus on what you think the highest priority areas are for your users. At the very least, make some assumptions that you can look to validate at a later stage.

Cross-functional collaboration: Similar to the Product vs. Technology silos, it is essential to be cross-functional during the design sprint. This includes the client SMEs for product, marketing, support, and technology. Ensure that you have at least the ‘Amigos’ present (Product, Tech Lead, Quality Analyst and Designer). Without this, you risk creating designs that can’t be implemented or don’t actually meet the needs of the users and the business.

In agile software development we use deliberate constraints everywhere. From the timing of the sprint to the way we break down features into INVESTABLE user stories. Having agility is important at every level of an organization. Being nimble is not just for the small, tech startup with no cash. It is a tactic that keeps you competitive and it allows you to maintain relevance in a very fast paced, global market. Lean Startup revolutionized the way we approach starting a business, focusing on small, inexpensive experiments. Now, Lean methods have not only touched every corner of software delivery, but people adopt Lean practices in their daily lives, all the way to Enterprise level executives making billion dollar decisions.

Fixed-scope fixed-costs projects challenge us with their inherent agile anti pattern. We could quite easily adopt heavier planning phases with more agreements up front. Waterfall methods of planning, however, are becoming less relevant in this fast paced global market. Adopting deliberate constraints that force you to be lean and committing to these methods allow us to deliver our fixed scope of work within budget, on time and all while working with agility and creativity.