Dream Week - a tool for agile innovation

A team that I have been working with for a while now recently came up with, and executed, a great idea for inspiring innovation and improving collaboration in an agile environment.

It is worth noting that this has only been performed by the team once, so I am making some assumptions about how it may be executed in the future. The goal of this post is not only to document what happened but also provide a framework for moving the technique forward in the future.

What is the context of the product team?

Everyone works in different ways, agile or not, so here is a bit of context about this team that you can bear in mind if you want to apply the idea to your organisation.

The product team consists of two delivery / feature oriented sub-teams. Each of these teams contains programmers, a UX professional and a business analyst. There is also a product owner (from the UX discipline), a chief architect and another UX professional 'floating' across the two delivery teams. The entire product team works on two week sprint cycles, performing a demo and retrospective at the end of each sprint. A product release is performed every few sprints.

What is Dream Week?

At the beginning of a new release one week is set aside as Dream Week. Each member of the team comes up with ideas for work to be performed within the week. The only limitations for the ideas are that they must benefit the product and must be deliverable within the week. The ideas are then pitched to the product owner at the beginning of the sprint. The whole team helps to work out a common understanding of the idea, during which time the idea may change and go through a number of quick iterations. Once all the ideas have been pitched the product owner prioritises the ideas and then the team cracks on with delivering them in priority order.

The ideas that are pulled into the sprint are built to production quality and go into the product. Ideas do not have to be product features, they could be paying back technical debt or investigation into future technologies. However, the ideas are prioritised by the product owner, so just like every day stories, the payback of technical debt must be justified against improved product capability.

By running Dream Week at the beginning of a release it gives the team and the product owner the most freedom to follow potentially controversial ideas as any mistakes made can be corrected throughout the release. It is the least risky time to innovate.

Why only a week?

"Constraints breed creativity"

http://37signals.com/svn/archives2/constraints_breed_breakthrough_creativity.php

For many people given a free reign to come up with new product features, wild and fanciful ideas start to bubble up to the surface. This is a good thing. But that creativity needs to be harnessed. By requiring the idea to be implemented within a week, the would be innovator needs to pare down the idea and get very creative about the potential solution to allow the goal to be achieved within one week.

"A change is as good as a rest"

By using a shorter time period than the team is used to there is a buzz of excitement about the weeks work. The regular heartbeats of agile iterations are useful for creating a rhythm that the team can get into and create useful touch-points for the rest of the organisation. However, the change of pace and focus for a short period is good for getting the collective heart pumping.

How does it improve collaboration?

Anyone can suggest an idea, programmers, UX practitioners, business analysts, but everyone needs to be involved to deliver. The ideas are fresh so anyone has a chance to get involved to shape the solution. The time scale is short so everyone has to pull together to meet the deadline. Because the idea has originated from within the team there is an increased sense of ownership.

Dream Week creates a vacuum of time that must be filled by work generated within the team. It's more than likely there will be too much work to fit within the time. Sound familiar? In this environment your idea is competing for space with all the other ideas being presented, so you better sell it well. Figuring out the needs of the person you are selling to, and pitching the idea, is a great way to improve communication skills.

Did it work?

The team certainly seems to think so. We fixed a number of usability issues that had been hanging over the product for a while and introduced a new pattern to achieve a user goal in a much more effective manner. The teams enjoyed the process, the product owner is happy with the delivery and the next Dream Week is scheduled for the first week after the next release.

The team have actually decided to call it Innovation Week as this makes it an easier sell to business sponsors, but I'm personally a fan of Dream Week as innovation has become almost as overused as Agile.

XPDay 2009 - Fostering collaboration between developers and UX

I convened an Open Space session at XPDay 2009 on the subject of fostering collaboration between developers and UX in an agile environment. Participants in the session were invited to tell a story about their experiences of working in an environment where software developers and UX professionals worked together to deliver a product. The stories could describe a positive or negative experience, and anything in between. We then pulled out and recorded positive and negative properties from these stories. These properties are recorded here.

None of these stories were thorough experience reports, but they were, to the best of my knowledge truthful and an accurate representation from the perspective of at least one person.

Negatives

Solutioning stories too early

An emerging pattern when integrating UX and Agile development is to have the designers work as part of the customer team to help drive the prioritisation of what gets built. This was a common theme for most of the stories, and seems to work well. However one story highlighted the need to be wary of performing too much design work before passing the user story to developers to implement. The developers in this story started to feel disenfranchised with the solution and unable to make suggestions for changes to the design.

UX is a more volatile resource

Another story told of having UX practitioners working in sprint with developers, only for the UX resource to be frequently pulled out of the sprint to work on other tasks with the customer. This had the effect of obstructing the flow of work as the developers were unable to complete the story without help from the UX practitioner.

BDUF was a source of conflict

This is a more extreme example of a UX team solutioning stories too early. In this case the UX team would produce large amounts of design documentation for each feature to be implemented, and then hand this documentation over to the developers to build. This ended up being a source of conflict between the developers and the UX team as the developers did not want to read through lots of documentation to build the feature. To get round the problem business analysts would 'paraphrase' the documentation to let the developers get on with building the features, which understandably, caused a lot of friction between the various groups involved.

Positives

UX contribute to definition of 'done done'

UX practitioners on the team contributed to the definition of the 'done done' criteria for a story. This means the values and the overall integrity of the experience of the product can be controlled by UX practitioners on the team. In addition, every single person involved in delivering the product is acutely aware of the standards that each and every feature needs to be delivered too.

UX sitting with devs and working in sprint creates a good flow of work

More than one story told of successful working environments when developers and UX practitioners sat together. One story in particular told of a transition from the UX members of the team moving from sitting with the rest of UX people in the company to sitting in the same space as the developers. While this transition was difficult in the short term the team experienced a much improved flow of work as it was easier to coordinate the different tasks that needed to be performed by developers and UX for the completion of a story.

UX working in sprint improves understanding and empathy

Having UX and developers working together throughout a sprint to achieve a common goal gives a real opportunity to gain a deeper understanding, even a level empathy, into the effort that is required to deliver a story from both the perspective of developers and UX practitioners. The specific example given in one story was that, by being involved in the estimation process, UX understood better the amount of developer work required for certain solutions.

Allow developers to collaborate on design without forcing it

We were fortunate enough to have Jeff Patton with us in the session. He relayed the story of an experience report at Agile 2009 Feature Teams - Collaboratively Building Products from READY to DONE. This company moved from a process of designing and planning work separately from the development team to what sounds like a 'by the book' scrum process of performing all activities necessary to define the work, design and deliver the required features within a single sprint. This allowed the developers to be involved in user interaction design as it became just another activity to be worked through on the road to delivering a feature within the sprint. The interesting point for me in this approach is that not everyone had to be involved in the UX work. For example, developers that were happy not to get involved in the solutioning of stories were free to work on repaying technical debt while the solutions for the stories were being worked out. Thus giving the opportunity for design collaboration if the developers wanted to provide input, but without forcing the issue.

Innovation Sprint \ Dream Week \ FedEx Day

Three ideas around the same theme, giving a delivery team more ownership of a solution and improving collaboration and innovation all tumbled out at the end in quick succession. The innovation sprint is something that people at Yahoo were toying with, please correct me if I'm wrong here. Every fifth sprint is an innovation sprint where the team get to decide what to work on. The idea being to try and introduce innovative, potentially risky ideas, that would not normally be prioritised by the product owner. I'm not sure if the result of this work is committed and deployed or if the work is all prototypal in nature to feed future stories? Interestingly the amount of time this takes away from delivering customer features, is 20%, the same amount of time as the Google Innovation Time Off.

Dream week is something that the team I am currently working with has come up with. The idea being that, at the beginning of the week anyone in the team can suggest an idea for something to work on that will add to the value of the product. These ideas are pitched to the product owner who prioritises them to be worked on and delivered within the week. Keeping the time available down to a week increases the focus of the solutions and reduces the risk.

Taking the focus on innovation company wide, another company would hold FedEx days. The idea being that you had to deliver something at the end of the day. The entire company would be arbitrarily grouped into pairs for the day. Each pair had to deliver something of benefit by the end of the day, The pairs can choose their own thing to work on, or can pick ideas out of a hat. The pairings are arbitrary so you can end up with anything from product owners and developers pairing to sales people and UX practitioners pairing. Of course something of benefit may not be software.

Explore many ideas up front

Another suggestion for improving the collaboration between developers and UX practitioners was to follow an approach of exploring more options up front, together as a team, and then focusing in on one option for delivering the solution. I believe this was given as an alternative to gradually iterating towards the solution through frequent delivery.

I would like to express my thanks to everyone who participated in this session. I thoroughly enjoyed hearing all of the stories and your experiences. I was glad to hear of so many positive experiences working on products with heavy UX and development involvement.

A number of the stories come back to what I have been learning over the past couple of years, which is, there seems very little cause for irresolvable conflict between agile developers and UX practitioners and in fact, the solution to many of the problems can be found by taking a step back and reviewing the principles of the agile manifesto and tailoring the implementation of these principles to your own environment and context.

Here are a few of those principles that I see as being particularly relevant to the positive experiences that were reported during the session:

* Business people and developers must work together daily throughout the project.

* Build projects around motivated individuals. Give them the environment and support they need and trust them to get the job done.

* The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

Take a moment and have a look at the rest of them.