Retros i’d previously ran followed a similar pattern – Reasonably long periods of data gathering, with the facilitator (me) reading out individual stickies and grouping them, whilst the team were either passive, explaining their stickies or discussing the point they’d made.  Feedback i’d recieved in a “retro of retros” identified the need to make sessions more engaging, so I decided to take a different approach to facilitating.
I used Ester Derby’s book (http://www.estherderby.com/books/agile-retrospectives) … and www.agileretrospectivewiki.org to research retrospective formats and structure.  Ester provides some excellent, practical advice on facilitating retrospectives, which I have since applied with success, including:

• Introduction of an exercise that gets everyone to speak in the first 5 minutes (describe this iteration as an ice cream).  Fun and revealing.
• Time boxed data gathering, and strict timekeeping.
• Getting the group to manage their data gathering
• I encouraged participants to read through stickies (retro data was captured on stickies), group and re-group the stickies, and name the group.  Once one person started reading and grouping, everyone else followed.  It meant all stickies were reviewed, and ambiguities discussed/resolved.  I acted as a guide – making sure all stickies were grouped & everyone understood the group names.
• Action brainstorming: Ask the question – what could we do to resolve the raised concern, or what could we do to improve on the last iteration?  No discussion, just ideas.  Really helpful in allowing everyone to participate without getting bogged down in too much detail early on.

As I was facilitating the retrospective, I soon realised that allowing the team to self-manage data gathering and analysis was a powerful way of engaging participants in the process.  It helped the group to think for themselves, and direct for themselves.

The software delivery team has successfully released new products to live over the last few years, yet throughout those projects there has always been a slight friction between design & development teams.  Not devisive or disruptive, but sufficent to make you think “could we collaborate better?”

There are steps that an Agile software development team and creative design can take to minimise frictions between these two.  These steps begin at the product inception, and continue throught the product development and delivery process.

In this blog post, i’ll talk about my experiences into this topic, what i’ve learned and what I try to apply when working with our User Experience Design team.

I’ll start first with a few sound bites that I often hear both design and developement teams say during the lifecycle of a project:

UX Design team quotes:

“…dev can’t deliver our User Experience”

“…the User Experience doesn’t work without the x thingymebob”

“…all of our good feature’s aren’t there””All of the features are there, but where’s the finessing?”

“We have n’t seen what you’ve been developing”

“Why have n’t you tidied up the layout, drop shadows, used the correct icons, used the correct copy…?”

“All I want is for my designs/UI to look & behave as designed”

“…why is the User Experience design being questioned?”

Dev team team quotes:

“The designs don’t match the scope we’ve committed to”

“Why have they made that interaction so complicated, it’d take half the time to build it if they did it like this…?”

“Why does the layout and copy keep changing?”

“That’ll never work”

Ok – so these are n’t necessarily voiced out loud at every showcase, stand up or retrospective, but I have heard these sentiments expressed during projects, and in conversations with new joiners talking about their previous experiences.

My observations are

1. User Experience design is preferably done up front (not all, but most)

The User Experience design process requires research, discussion designing, testing and reviewing to ensure the envisaged product is both useful (meets the User’s goals) and usable. A mature User Experience design is important for stakeholder buy in.  A design that has been thought through, and has been tested with focus groups or low-fi prototypes will build confidence in product owners and sponsors.  In my experience, product owners and User Experience designers like to take a mature UX design into a development project.  Other product development activities such as marketing, sales team briefing, and internal business process change can also rely on the outcomes of User Experience design, and have their own lead times and deadlines.  Its not sufficient to consider the User Experience a few weeks before the start of development.

2.  Significant changes to a mature design is hard

Changes to a User Experience is sometimes necessary during a delopment project, but can be difficult.  Any change will require further stakeholder buy in, which can be time consuming and require several design iterations.  Any change also still has to work with site’s overall style & layout framework.

3. User Experience designers don’t have all the answers, up front

They don’t know all of the interaction edge cases, and rarely have all of the extreme data sets.  What happens if a dealer has a long and addresses combination? What if only a couple of search results are displayed, not just a full page? How should the buttons appear while searches are being retrieved…?

4. Developement teams are as passionate about User Experience as the Design team

Developers and testers may not be User Experience experts, but they understand the core concepts of usability (consistency, adequate feedback, simplicity).  They also are familiar with the data sets that are used, are detailed focused, work with the site day in and day out, and have an understanding of the business context.  Devs and testers are good at recongnising inconsistencies, and want to understand more about reasons behind UX design.  They have as much interest in the site’s success as the UX designers.

5. You can’t incrementally release a coherent User Experience

Agile software development practices strives for frequent delivery of releasable code that provides value to its consumers or customers.  There is a point in time where, for a new product, website or application that incremental features combine into a coherent User Experience.  Releasing software before then, however, could expose a company to reputation risk and discourage users from returning.  Agile’s desire to release frequent and often has to be weighed against a product owner’s desire to release features that deliver a compelling and coherent User Experience.

The key, as with many problems faced by agile teams, is to solve it with close collaboration between teams, shared committment and buy-in, adopting a culture that embraces change, and making decisions at the last responsible moment.

I’ve put my thoughts about how i’d like to see the relationship between development teams and UX design teams work, the context of:

• “Product definition” (developing ideas for the product, exploring the User Experience, orders of magnitude costings)
• “Project definition & planning” (Establishing a business case, project execution planning)
• “Project execution” (building and deploying the product)

Product definition

• Establish and test key architectural features
• Think about having just enough features

Project definition & planning

• Build a culture of  “change will happen”
• Adopt design baselines, not “design freeze”
• UX design helps shape the release plan

Execution

• “Selling the experience” to the development team
• Get IAs and BAs to collaborate
• Get User Experience developers (JS & CSS) and User Experience designer collaborating
• Get your designers to sign-off stories
• Don’t forget to add the finesse

Currently our development at the end of a phase of work to deliver a new piece of search functionality to our site.  In total it is a 14 week project, which started with a story gathering, estimation & release planning phase.
The release plan was used to set expectations to the business around scope and timelines.  The intial scope was identified at 82 points (which grew to 85 with some change in scope for some stories, and trading of others).

The development team, which remained reasonably consistent in terms of personnel for the duration of the project, conducted a velocity modelling exercise, based on their understanding of the stories.  The team estimated that they could achieve 12 points per iteration (for 3 pairs of developers).

We also conducted a story steaming exercise, to work out what stories could be played in parallel, as most of the stories touched the same area of the codebase. These modelling exercises and overall scope identifed the timescales for delivery.

Our eventual team shape was 4 pairs, 1 UX developer, 1 full time  and 1 1/2 time QA.  We picked up another work stream of development, to accommodate the 4th dev pair.  Our actual velocity (over 7, 2 week iterations) was 13, or almost 18, when ignore the first 2 iterations (in which 4 points were signed off).  That’s just over 4 points per pair.
On the face of it, we performed as predicted.  Our velocity tracked reasonably well (i.e. it was predicable) and progress meant we met our deadlines and scope.  Thinking back to the modelling exercise, the team didn’t predict the issues we have faced with our Continuous Integration environment, unexpected releases which took up testing resource, or recruitment which took out key team members.  Does this mean we were too conservative in our planning, as without the blockages we could have gone faster?

The streaming exercise did prove a good predicter, as we encountered problems early on with merging conflicts, so we had to be strict around which stories could be picked up.  It did encourage thorough communication across our (two site) team.

I have learnt that planning velocity is just that.  Its good for planning, and it’s perhaps coincedence that a team hits its planning velocity.  I would, however, prefer to commit to a velocity that a team is happy with and then exceed it (rather than assume that the figure is too conservative or optimistic).  As long as your assumptions are sound and justifiable, then there is no reason to doubt it.  In the future I’d also encourage teams to think about an “ideal estimates” and “ideal velocity” when initially deriving a planning velocity, and discourage any thought of blockages, drags or team changes.  This can then be layered with any manner of risk analysis afterwards.

Owner Reviews was a 6 month development project, and its scope was continually refined over its duration.  Our key constraints were the go-live date and cost, with scope being the lever for planning changes.

A release planning exercise over May & June helped drive the scope to an achievable amount.  A user story back log and architectural approach was created using wireframes and an understanding of the 3rd party API we were to use. The project was sized and costed at least three times in order to establish a scope that met product owners goals for launch, the UX director’s ambitions for the site & the team’s ability to deliver in the timescales.

The project followed a typical agile development cycle – two week iterations, daily stand-ups, end-of-iteration retrospectives and showcases.  Mid-way through the project an agreement was made to change the architectural approach, changing the way we obtained our data from the 3rd Party’s application.  This meant building and deploying a new application & database tables, in addition to changing our front end.  New stories were created and estimated, old ones were ditched or parked, and our release plan was updated using our velocity figure.  The desired scope could not be achieved in the time available (by about 1 iteration).  We worked with the stakeholder to manage the scope accordingly.  He was able to set expectations of scope to the wider business (marketing, editorial, sales) using our release plan.

As a BA I have a responsibility to manage project scope, and in most projects, to manage delivery expectations.  My experience of Release Planning and Iteration Planning is based on copying the (hopefully) good practices of the PMs and BAs i’ve worked with, and i’m reinforcing my experience-driven knowledge with some book reading.  Amazon recently delivered “Agile Estimating & Planning” by Mike Cohen, and I have been reading and taking notes from “Planning Extreme Programming” by Kent Beck and Martin Fowler. 

Already, I can see the benefits of technical task breakdowns for User Stories to help iteration planning.  I’m looking forward to learn more about managing iteration hangover, estimation good practices, and progress reporting.

• Short tech reviews of stories by our dev pairs and QAs
• Identifying and managing blockers before an iteration
• Working out “hangover” effort remaining – points left in-dev or ready for dev
• Working out any remaining defects to be fixed
• Gathering the team together
• Presenting the stories in the IKO and providing iteration level estimates
• Ensuring we can fill our parallel development streams
• Bringing in enough stories to fill our estimated capacity

The process has been honed over about 1 1/2 years, and was part of a bigger programme to take the development team from working waterfall to agile.  Our team is relatively large (7 dev pairs, 5 UX developers) spread evenly in 2 UK locations.  The team develops in the same code base, and therefore effective communication and knowledge sharing is essential.   Pairs swap regularly, and are generally skilled in all areas of the codebase, from our search engine technology to writing Java Script.  The IKO fosters knowledge sharing and also ensures the team’s provided with the wider User Story.  We’ve also found that a thorough IKO drastically improves the quality of the User Stories, reduces the number of story blockers and clarifies the technical approach for a story.  Our IKO preparation speeds up the flow of information and context sharing in the IKO.

We’ll be investigating ways of making our IKO process that bit leaner, but for now it is the best way we’ve found of starting an iteration.

How was it successful?

What i’d do differently