Designing in (and around) Agile
Agile is all the rage right now. But designing within the Agile process is challenging. When does it make sense and when is the right time to do design up front?
In the spirit of collaboration and efficiency designers are often confronted with having to design within the Agile process. Let’s be kind and assume the purpose is to do better work together and not purely motivated by the desire to cut time and costs to maximize profit. The point has been made many times that agile was created specifically for developers with no thought to design. I could give the example of hiring an architect, a framer, a plumber, a roofer, an electrician, and an interior designer and tell them to build a house in two-week sprints. I could make the argument that this is development-centered, not user-centered. The challenges are well documented, but let’s look at the nuts and bolts and define the challenge and explore some solutions.
Design is generally a sequence of events moving from conceptual to some kind of high-fidelity deliverable. Sometimes the designer chooses to back up and redo previous activities. Maybe they skip a few steps. Maybe the designer knows how to code. There’s your deliverable. At ACST we currently take this approach. That sequence of events is known in the land of methodologies as a waterfall process. It’s a bit of a bad word these days, why on earth would anyone do anything waterfall when there’s so much efficiency to be gained using agile?
So what does folding design into agile development sprints look like? First, let’s consider the design tasks that would need to happen.
Sizing of design requirements
Developers break tasks up to be very granular because its required for them to be properly defined and actionable. These are usually called “user stories.” The challenge is that these are so granular, that the designer requires something larger, something with more context. But not something so large that it can’t be designed, built and tested in one sprint. It would need to be relatively small as the designer would likely only have a few days of the sprint to create the initial design (assuming a standard two-week sprint).
Delivery of designs
Creation of an actual design deliverable would probably take a relatively small amount of time as the work would be scoped so small. But this also introduces the problems that come with incrementalism.
User Testing
In addition to the technical testing, validation testing with actual users would need to fold into the sprint. Typically this would be done in large chunks, but in the spirit of agile, it would need to be done within the sprint so the team would know if they can move on or need to take another swing at this next sprint. It could be chunked up, but then the team would proceed without the design being validated and potentially have to change course to revisit.
Yes and no. Anytime a collaborative, cross-disciplinary team can step back to plan and design together to kick off a project is very beneficial. But the output of a design sprint probably isn’t sufficient to break the project into pieces small enough to design within a sprint. In our experience, we rely on this output primarily for concept validation and light usability testing. There are lots of thorny details regarding use case and business logic that still need to be sorted. Also, if the goal is primarily creating efficiency, having key developers from a feature team invest a week in a design sprint is often not desirable.
Let’s assume both design and development require the same amount of time but share sprints. Let’s look at a visualization to demonstrate:
Some things jump out right away. Utilization looks the same, but in reality, is probably much less. The reason is that the process only moves as fast as its slowest moving part which results in reduced efficiency.
Which part will move the slowest? Well, it depends. Development is challenging to size and execute on plan. And development effort is not a 1:1 with design effort. Adding a new filter might be an easy design task but require a large development effort. In which case the designer is idle while development catches up.
Design might also be the slowest part. Even worse, design might create rework for the development team. No design project comes with every bit of information already available. Designers fill in these knowledge gaps with assumptions. These assumptions apply not just to the UI but extend to the underlying business logic. That’s why we validate, it is the primary way we know if we made good or bad assumptions. If the designs are validated in sprint, but before development, any redesign will delay development. If designs are validated in sprint but after development, we greatly increase the chance of rework.
Typically the development effort to implement a set of designs is much greater than the design effort. Doing a large portion of design before development allows a design to support multiple development teams provided they can offset the work to not overlap. Designing in sprint will likely require more design resources as there is no way to plan and offset the heavy design portion of the sprint work.
In a perfect world, it might be. But nothing goes perfectly. And an ideal process has the right amount of flex and rigidity. A healthy process is efficient and measurable. It provides people with adequate time and resources to be effective at their work. And it seeks to minimize the cascading effects of one part of the process negatively impacting everything else.
Collapsing design and development into the same sprint and removing any padding greatly increases the risk that one team negatively impacts the other and inc, increases time to market. Any efficiency is then lost. And utilization potentially declines. Also, moving validation post-development means that in the event validation doesn’t go well, not only is redesign necessary, but also redevelopment. Unfortunately, the temptation to release features that do not test well is too great for many companies to resist because at this point the time and cost to improve them are too great.
A quick glance at the central principles of agile reveals a lot of common ground. There’s no problem aligning with a focus on working software, valuing teamwork, pivoting as necessary, and collaborating with customers. In fact, those things are central to user-centered design and any healthy design process. So how can we align our processes to accomplish these shared principles?
A lot of design production consists of details. And this can still happen within the agile process after the initial concept and design have been accepted across the team (and by stakeholders) and given the green light by a sample of people who actually use the product. Sprinting with the development team looks like being assigned user stories, collaborating on a weekly basis and delivering design solutions for the team to quickly implement.
Complex problems take time to solve. While incrementalism can be valuable, it often fails to get its arms around big issues. In fact, many problems are produced as a result of incrementalism and the only solution is a big step back to take inventory and ideate solutions. This does not mean however that every design problem deserves a large effort to design up front. A big factor in how this is actually implemented is the size of the team and org structure. Some things that should happen up front:
Large projects can often be broken into smaller pieces to go through an expedited design process up front. At ACST, we find a typical design process takes about three to four sprints (design workshop through user testing). Our process scales down easily to help expedite smaller projects while being careful to not fall into the pitfall of incrementalism. This keeps our design process lean, fits our organizational structure, preserves the benefit of user testing pre-development and allows our designers to work within Agile sprints to support the implementation of their designs.
Have you tried designing in (or around) Agile? I’d love to hear what you’ve learned.
📝 Read this story later in Journal.
🗞 Wake up every Sunday morning to the week’s most noteworthy Tech stories, opinions, and news waiting in your inbox: Get the noteworthy newsletter >
Designing in (and around) Agile
Research & References of Designing in (and around) Agile|A&C Accounting And Tax Services
Source
0 Comments