dork intervention — bringing design to agile

Brief

Agile is broken. How can designers help deliver products that users will love while grappling with the constraints of agile in corporations? With large companies rapidly adopting agile methods, it is crucial that these teams include designers to create great products. But the agile framework available to larger companies doesn’t take into account the work style of design team members. Agile, by its nature, shortcuts the design process without considering the value that design brings, not only in providing on-the-fly design solutions but also when crafting the vision of a product that the team can build towards. We are designers with agile team experience in the corporate world. These are our stories of triumph and tragedy. Come hear what worked for us and share your own war stories.

Agile wasn’t created with design practices in mind. It was about developers figuring out quick solutions and pushing out code as fast as possible. Innovation projects are off release schedules/calendars. Modern software needs design (because we’re no longer bounded by what the technology can do, we are more and more concerned with how and how well it can do it).

Attempt #1: Design up front (Waterfall)

The problem with doing design first and only developing in agile is there is no collaboration on what is possible, no “working design”, and it’s a blackbox/silo’d design. It’s still waterfall and doesn’t count. Pro: Certainty in design boundaries. Cons: Design can’t respond to change based on testing/new information. A good team doesn’t have conversations like “well, we did our job, it’s your problem now.”

Attempt #2: Design at the beginning of each sprint (Mini-waterfalls)

All the same problems of waterfall, but in every single sprint. Not all design problems can be solved within the timeframe of a sprint. There is no chance to re-think.

Attempt #3: Design working in front of Development (Just in Time)

Finds a compromise between doing all design in advance and doing design in each sprint. Places design 2 sprints ahead of developers, who play catch up. Seen as best practice. Still means you can’t foresee tech issues in design ideas. The farther ahead design is beyond developers, the less agility you have because of colliding processes/splintered design focus (inefficient time usage). Testing is too late to respond to development issues.

Attempt #4: Design Sprints

The entire team needs to be involved in the design process (communication and buy-in). It’s more fun to solve problems together. Every few sprints (release/milestones), bring entire team together to collaborate on vision/strategy and come up with a framework. Felt like we were pulling people away from their work to talk about someone else’s work. Disruptive: tends to throw off the developer rhythm. Risk of team members getting poached because they are in a “down sprint” when the team shifts back to vision/framework collaborations.

Attempt #5: Designer/developer partnerships (Fused Innovation)

The partners speak each other’s professional language and should be located physically near each other. You’re effectively re-creating the JOAT but as a team. It means that developers are constantly explaining capabilities to designers, and designers are finding new ways to solve problems. Starts to break down the inherent project prioritization/gatekeeping of developers over designers. Also breaks down the diva designer whose designs are unassailable. When everyone gets involved, you have more opinions on the table but more opportunity to unify opinion. This is where early vision articulation is key. Brainstorming can get both on same page early, meaning prototypes are built while sketches are solidifying (side-by-side). Then you are watching each other the whole time, and share what you’ve learned/done (good ideas and happy accidents). Iterate quickly and fail faster. You can’t know the perfect design before you start testing, so this gets you to testable faster.

So how do teams get to this level of “bonded bliss”?

Original Principles of Agile

Make a crucible of innovation. Emphasize individuals and interactions over process. Make working code. Responding to change instead of only following a set plan. Teams aren’t assembly lines, rekindle the engaged collaborative feel of a startup team.

Rules of Engagement

Create and share a vision with all team members and make sure they can agree with the goals (multi-disciplinary)

Designer: Engage the team to keep the team on track with the big picture

Get stakeholder buy-in on this process; acknowledge risk and high potential for reward

Use working prototypes to keep the rest of the business informed on progress

Sit together (physically close working environments; work on a single project at a time)