Agile Designer / Developer collaboration with Scrum

One of the biggest challenges for us moving away from an up-front design approach to a Agile / Scrum approach is figuring out the best way to incorporate the work of our visual designers into the collaboration.

We want designers to join in with the ongoing design and development in a way not too dissimilar to another developer (or developers joining as another designer). In order to do that we need to avoid the perils of: excess inventory, feature creep, and ‘throwing pixel tweaks across the wall’.

We will walk through a few techniques to help keep the process lean and the collaboration flowing organically.

Traditional Designer / Developer collaboration using mock-ups

Traditionally, designers will create mock-ups representing how the application’s UI will look at some point in the future. This work may be the culmination of wire frames, user testing, and several other forms for UX design methodologies. It may also involve developers during the early preparation.

Design mock-ups can take many forms. These mock-ups may be fully designed images that will be used for later pixel-perfect comparison. They may also be static HTML pages that will need to be made dynamic and integrated into the build. They may contain ‘nice to have’ features which can be used to discuss with developers and see what can fit into the current iteration. These mock-ups may be formal: used as a way to define a commitment of work, or they may be loose artifacts for idea generation and sizing of a project.

It may be blurry to a developer exactly what they represent- what are they signing up for?

Traditionally, there is an up front exchange between a designer and a developer where the developer gives estimates as to how long a particular design will take. There may be a couple of iterations in the mock-up to accommodate the feedback of the developer. After the developer agrees to a particular design, the design can be considered “signed off” and then is handed off to the developer for implementation as a prototype.

After the design is implemented, the designer reviews the prototype and creates notes on how the implementation needs to change to more closely match the intention of the design. This may take many forms, but commonly a list of changes is presented to the developer- moving pixels to match the original design, changes to the design based upon recent discoveries, etc.

Wash, rinse, repeat until the design is considered fully implemented, or Done from the designers perspective.

A project manager helps facilitate the collaboration between designers and developers and guides the business decision making.

Challenges with the Traditional Approach

There are a few issues with this traditional designer / developer collaboration that can hamper open collaboration and slow down team velocity.

Change Management

If there aren’t some clear rules defined in the Planning Game, then feature and scope creep can easily swerve a software project off into a ditch of “interesting ideas to try out” and “hidden assumptions”.

Developers are placed in the position to constantly push back on new cool ideas because they are out of scope of what was originally agreed. If the developer is the only one that is pushing back, or it taking the overall team resources into consideration, then there will be some real problems.

Developers traditionally, don’t enjoy negotiating and estimating as much as building cool features. Additionally, there is an overall industry trend for under estimation.

But the software does not have a neutral estimation problem. The industry data shows clearly that the software industry has an underestimating problem.

Steve McConnell, “Software Estimation, Demystifying the Black Art

It is risky to put the burden of change control solely onto the shoulders of the developers. Bringing in a project manager for arbitration isn’t the leanest approach either- it quickly grows into a negotiation game, when really developers and designers should just be ‘jamming’ together.

Pixel tweaking across the wall

We can also find ourselves in a situation where mockups are emailed repeatedly to developers with little pixel tweak suggestions and other design notes (i.e. “please move this button 5px to the right and make it 10pt Verdana”). It may look ‘good enough’ to the developer, but doesn’t match the quality that the designer is expecting.

Some of these notes may include work that would put the estimates at risk. All of this needs to be communicated back to the designer.

The developer may attempt to fix many of the design problems only to see that more issues introduced that the developer didn’t notice. The designer will then put together another set of notes, and that set of notes will need to be communicated again, with an additional round of estimate negotiation.

If sent ‘across the wall’ in this manner through indirect communication this can take a significant amount of time and can be quite inefficient. It is also at such a level of technical minutiae that a project manager would prefer to be left out of as much of this communication as possible.

Making this back and forth too formal can also hamper the creativity and spontaneity of the process as a whole.

Excess Inventory

This is a core Scrum concept: don’t create excess inventory. There is a metaphor here between product inventory from a factory and artifacts created during the software development process. A factory will be less profitable if it creates more products than can be sold- the excess inventory will need to be stored and then eventually disposed of by some means. There was cost in creating it and cost in disposing of it, but no revenue from selling it.

Unused feature ideas in final mock-ups are excess inventory or team over stock.

This isn’t to say that the iterative design process of auditioning many several ideas to arrive at a final proposal is excess inventory. Rather, all of the feature ideas that will most probably not make it into the iteration are excess inventory.

An unused screen or an idea which is not part of the story that the team is currently working on will need to be explained, estimated, and then eventually rejected. There is a cost to the entire team to go through that process of negotiating a tangential feature idea out of the mock-up.

Sometimes this is unavoidable, but it should be considered an expense that the team should work on reducing.

Techniques to facilitate agile designer / developer collaboration

What we want to do is create lean process where designers and developers can collaborate together focused on only those stories that the team signed up for during the iteration without the overheads of game playing and negotiation of project constraints. We want to keep the process lean and focused. Below are a few techniques we have started using to help us move in this direction.

Technique 1: The “no excess inventory” final mock-up

As described above, we want to remove overheads associated with excess feature inventory in our mock-ups. Right after the Sprint (iteration) begins a designer on the Scrum team should create a final mock-up representing the features that the team signed up for during the sprint but no others.

No speculative ‘nice to have’ features should be included.

This represents a great communication tool for the team itself and between teams. It basically says, “By Sprint’s End the software is going to look like this- no more, no less”.

The team should also carefully consider if the mock-up should be updated once the software has been partially implemented. Each update of the mock-up runs the risk of being excess inventory unless it can be argued that the communication the updated mock-up yields offsets the development cost.

It is often much more efficient to just refer to the current state of the daily build. This is also a strong argument for first implementing a non-functional visual prototype to move the team away from the mock-up.

Technique 2: Time boxed paired development

During kickoff, for each story involving UI development, reserve some Timeboxed tasks for a developer and designer to try out different ideas while sitting together. This can be considered the equivalent of ‘paired programming’ but for interactive design.

Because it is Timeboxed, it forces both the designer and developer to make choices as to what design tweaks should be worked on. Designers will need to account for the actual time it takes developers to implement features by sitting along side and seeing the build compile and seeing the nuances of getting the layout right.

I don’t think that this is the most efficient technique for the initial development of the view, but rather enhancing the base visual prototype. It is a smart technique in facilitating the collaboration between designers and developers without the overheads of traditional change management.

If there is a risky idea to try out, they can prototype together and see how far they can get in the reserved time.

If the pair gets to the final hour, the focus on what they are jamming on will be quite clear if they know that after that hour, it will be shipped as is. They are both responsible for it.

Technique 3: Replace “Pixel tweaking across the wall” with Timeboxed paired development

Use the Timebox paired development mentioned above for “pixel tweaking” notes. Rather than emailing several rounds of design notes, developers should sit alongside the designer that has an ordered backlog of design notes.

The most important design tweaks will get done first, and when the reserved time is complete no more design tweaks get in. If all the notes have been completed and there is still time remaining, then free-form collaboration can happen to just try out some ideas.

What typically happens is that designers can see for themselves those little changes that seem like they should be simple but are in fact time consuming to implement. On the flip side, the pair may find that they were able to breeze by something that might have seem complicated. The designer, being aware of the time remaining in the session, can then direct the developer to work on other “low hanging fruit” that will have a higher likelihood of getting fixed.