Dork Intervention: Bringing Design to Agile

Loose notes from SXSW 2011 session: Dork Intervention: Bringing Design to Agile

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.

Karl Nieberding
Interaction Designer
eBay

Kris Corzine
Consultant

I arrived late for this session (started in another), but the woman sitting next to me, also a fervent note-taker, graciously sent me hers! The first section of notes below are kindly provided by fantasai at inkblade.

———-

Agile development is broken – no room for design, no cohesive design vision.
“almost as if they added a feature, then added another feature…

Waterfall:
Make the full spec up front, then develop in agile.
Problem: Still waterfall: has no redesign involved in development
If design is only up front, can’t adapt based on testing and new information.
Design is produced in a silo: no collaboration with development.

Mini-waterfall:
Put design in every sprint: every sprint starts with a design phase, then
a dev phase, then a testing phase.
Problem: Sometimes need more time for a feature, needs more research, etc.
All same problems as waterfall, not collaborative, no room for backtracking,
squeezed timeline not practical.

Just in time:
Design works 1-2 phases behind developers. Current best-practice.
Problem: When design leaves time continuum… disconnected from dev reality.
– working on sprint 5, collaborating on sprint 4, testing sprint 3, can’t
fix problem in sprint… too many complex interactions for designers to
track. Designers unfocused and unhappy. :(

Problem: Teams weren’t collaborating and communicating.
Think whole team needs to be involved in design process, both for communication
and buy-in.
Designers, get your team involved.

Design sprints:
Every few sprints, at the beginning of release or milestone, get whole team
collaborating on dsign.
Took some work to convince people to leave their “real work” and participate
in design phase.
Vision setting, communicating vision setting.
Problem: Throws off rhythm. Developers time best spent developing.
Pros: whole team involved in design process
Cons: clunky and disrupts project velocity

Fused Innovation: Designer-Devloper partnership
– Requires shared language
– Requires designers and developers to be located physically near each other
– Articulating reasoning behind design and allowing feedback from other team
members means whole team buys into design vision.
– Create prototype instead of just mockups, with developer and designer
working together: brainstorm together, developer goes to set up framework,
designer works out details.

Want to fail faster, and learn from happy accidents.

Other disciplines and industries have this same problem and have solved it:
How do you blend vision and the technical camera operation in film? Have
director and cameraman sitting together.

Agile is about individuals and interactions over process and documents.
Working code over comprehensive documentation.
Responding to change over following set plan.
Instead of having assemblyline, rekindle startup spirit that has everyone
on team working together.

7 Rules of engagement:
Vision: Don’t just have a vision, share it. Have a multi-disciplinary shared vision.
Engagement: Engage the whole team. Keep the team on track, look at big picture,
get everyone excited about that.
Stakeholder Buy-in: Get stakeholder buy-in. Best: supported the project, but kept hands
off, not micromanaging.
Excite with prototypes: When you work with developers, can prototype code and
show stakeholders.
Sit together. Also helps if everyone on project spends most of their time on
the project. Large corporations: often put specialists together
not projects together, and often specialists work on multiple
projects. Better to sit together, be able to turn around and ask.
Include QA, too!
Communicate. You’re working with people. Make sure designers can empathize
with developers, and get developers to understand designers, too.
Get out of the way! Set expectations, then let the team work.

Remember that these are tools and not magic bullets. Select tools based on type
of project you have, and resources available.

———-

Fuse design and development processes. Learn from happy accidents.

People aren’t machines. Like the left and right brain, like the editor/writer relationship, like the writer/director bonded bliss, teams should fuse innovation.

Responding to change over following a set plan. Instead of treating teams like assembly lines going through design, develop, QA, do all of this at once if you want to make something great.

Another reason to start coding early – VPs love working prototypes.

Vision shouldn’t be locked up – should be a set of open goals everyone agrees to.

1) Vision
2) Engage team
3) Stakeholder buy-in
i.e. the stakeholders need to buy into the fused innovation process
4) Keep the business informed and excited with working prototypes
Prototypes get people excited.
5) Sit together.
Have your team work physically close to each other
6) Communicate
Eliminate the walls to throw things over. Make sure designers and developers can empathisize with one another.
7) Get out of the way!
Let people report their progress at check-ins, without getting bugged every day.

Innovation comes from happy accidents.

Leave a Reply

Your email address will not be published. Required fields are marked *