Agile project life cycle: incorporating design into Scrum workflows

In the first blog post of a series on the Agile project life cycle, we dealt with the topic of pricing projects. Today, let’s continue with another somewhat contentious topic: design and the Agile methodology, Scrum.

This is a well-debated topic online with no clear answer as to what is best to get great web design while also building things in a ‘just in time’ way. One view is that Scrum is an iterative and incremental model based on agile values, which means you don't have a separate design phase. The idea is that you should constantly be dealing with design, just as you constantly are dealing with analysis, implementation, testing and integration throughout the project. The reason Scrum is iterative is that the very nature of software means we never get it right the first time, as in many cases the stakeholders don't know what they really want until they have something in front of them. What's better: spending hours creating a design for a feature (that will need to be refined or most likely thrown out as the rubber hits the pavement) and communicating that design to the implementer; or spending those hours implementing a first pass at the feature and refining it through tests and refactoring? This is definitely the view of the developers involved: ‘Let’s build it and evolve the design.’

Designers often have a big issue with this approach. If design happens at a feature-by-feature level, the flow and usability of the site can be compromised, as well as potentially a less cohesive end product. Understanding how and when a user will be interacting with the site often creates a visual framework for which to develop in. Most designers that I know want the development to be more user led than feature driven, as there is a very real risk that the combination of features built without context of other features makes for a crappy user experience.

At SilverStripe, we lean more into the way of designing enough up front to create the vision, while leaving the detail to the sprint cycle. There needs to be a balance in upfront design versus sprint design.

The balance is needed because in practice:

• Designing all upfront isn’t very Agile: developers don’t get to provide as much context or potential solutions and are just being told what to build
• Designing completely within sprints is usually unrealistic: developers can end up waiting for designs, which slows things down and technical solutions aren’t always seen from the user's perspective

For example, very high-level wireframes in the planning of sprints can be a big help as another way to confirm written stories (anyone should be able to sketch these—not just designers). What we have found the best compromise is designing and user testing the Information Architecture, and some of the interactions between the main flows. Front-end developers can do a lot of work based just off these alone, while leaving the more specific design elements to the lead designer to elaborate on.

We are big advocates of not developing features right up to the end of the project budget, things need to settle and the designer needs to ensure consistency across the project as a whole (often missed during sprint to sprint as everyone is focusing on detail).

Let’s get to some specifics we often use at SilverStripe:

• If no branding guidance is provided, account for that in your timeframe, as they may need to be created, and branding can be hard to get right and can be seen as a framework in itself
• A style guide can be done pre-development usually (colours, branding, fonts…)
• Example pages (approx. 3) can be created for overall guidance direction/approval pre-development, which helps communicate the flow and main areas
• Features can be planned/wireframed when creating stories pre-sprint (ensures developers can start developing without polished designs)
• Detailed feature designs can be created early sprint (or slightly ahead of sprint if time-consuming), leaving enough time for developers to integrate designs within the sprint cycle
• Designers work with developers to ensure designs are implemented correctly during sprint
• If designs are not implemented correctly within the timeframe of sprint then issues can be raised for subsequent sprints
• Allow time for user testing designs and the work created during sprints, and give time for the feedback to be acted on

Design and development don’t need to be at odds with each other—they are two sides of the same coin. If the team involved gets this combination right, it makes for truly great web experiences that engage the user and gets the job done in the quickest way possible. If they get it wrong, the client and team often feel they had to compromise for a lesser result. I recommend addressing this at a team level, and coming up with a plan for each project together so that everyone agrees how best to approach it. It can be trial and error, but if a team trust each other and really want everyone to do their best work, it means respecting both sides of this equation and empowering each other throughout the process.