I had always believed that the role of the retrospective facilitator was to guide the group in finding their own direction and making their own decisions. In preparation for a recent team ret
rospective I soon realised that I had needed to change the way I facilitated retros. In learning and applying a few new facilitation techniques I feel I have improved participant engagement in retrospectives, and made retrospectives more efficient.
Retrospectives are a key component of continuously improving a software development team. I have recently tasked myself with reinvigorating our team’s retrospectives, as we had stopped holding them regularly as a team (provide a page with the context of our team).
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.
At Auto Trader we have a strong User Experience (UX) Design team, with a combination of Informaton Architects, Web Designers and Copy Writers. As part of the Web Services team, they play a key part in the product development process and are typically involved in a project months before the software development team to shape a product and to support the business case.
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.
“Plan, inspect, adapt” is an agile mantra that i’d heard, but never really given much consideration until recently. Auto Trader’s “Owner Reviews” feature has recently gone live (www.autotrader.co.uk/car-reviews/write-review) and through working on the development project I now have a better appreciation for that mantra.
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.
- Ensuring all stories delivered “end-to-end” functionality, regardless of the size of the feature developed.
- Getting the product owner to attend daily stand-ups
- Providing the team with a more visiblity of total scope and progress
Release planning and iteration planning are a vital part of agile software development. Release planning identifies the features that need to be developed early, helps determine the resource profile needed, and ultimately provides and estimate for overall project cost and delivery schedule. Iteration planning provides the scope of the development work to be done over an iteration (be it a week or a month), and helps to validate and refine the overall 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.
- Our Velocity is tracked and reported on dev complete (as we allow a few days post iteration for final QA and regression testing before releasing into Live) which means velocity does not necessarily represent true value
- Velocity does not indiate how well the projects are performing – are we hitting our deadlines, should we be concerned?
- There is no end goal. So what if we can deliver 20 pts in a week over a 10 week period. What have we achieved?
- Organising all small enhancements into projects
- Report a true measure of value which would be the story points that passed QA (something that can only be fixed with re-orgainising our iterations)
- Present velocity in context of a goal. How many story points have we commited to delivering per product area or project?
- Feedback the velocity to the team at an appropriate time e.g. retrospective
I recently helped a BA colleague prepare and give a workshop to our newly hired team peers on how to prepare for and run an Iteration Kick-Off (IKO) meeting. Jo did a great job of facilitating the workshop, getting our tech leads, Iteration Manager and BAs to think and talk about the steps involved in preparing for an IKO, and asking the key question “why do it?” Our IKO process may seem a little heavy-weight if you consider the number of tasks involved, which include:
- 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.
- identified key constraints and risks
- identified the potential scope (through User journeys, Epic user stories, and technial stories)
- and mapped out a programme of work
- Socialise the the Business Case: What’s making the project viable? It builds confidence in the project,and justifies the effort involved.
- Capture a prioritised set of Business objectives: why are we doing this, whats the goal? These were mapped to user stories to help story prioritsation.
- Discuss and capture key constraints: what’s going to shape the development and scope of features (time available, budget available, technology/achitecture constraints)
- Discuss and capture key risks.
How was it successful?
- Delivered on time, to scope within a short space of time (4, 2 week iterations)
- Widespread praise of product during user acceptance testing by senior stakeholders
Things I’d do again on my next project
- Work with product owners and other stakeholders (e.g. IT) to articulate and capture the business objectives and constraints. Theses were captured as simple goal statements, and ranked by priority.
- Appy a “Don’t over reach” philosophy. Apply strict prioritisation and scope management, use conservative (but justifiable) estimates, make small user stories so that the product can be developed incrementally.
- Identify a minimum coherent release that represents the minimum amount of functionality we can build that will appeal to both consumers and project stakeholders. I used the story mapping technique (c/o Jeff Patton) to identify the minimum set of features needed for the product. The technique helped with identifying a set of releases for the product (in the end we identified about 7 separate chunks of functionality, and only 2 were possible with the budget available).
What i’d do differently
- Kick the development work off properly: The Project Manager and I should have given the development more context around the product before we started. Some of the mis-communication during development could have been stopped had we spent 20 mins setting the scene, and explaining the objective. An example of this was confusion around the vehicle channel we were developing for.
- Caputre and agree the Information Architecture: We made sure that the graphic design was reasonably mature before development, and that the user stories we prioritised were understood from a technical perspective. The product did introduce new user journeysinto the site, which had implications not only for the consumer, but also for page analytics. We discovered the complexity around the new user journey about 1/2 way through the project (by way of a showcase to the product owners). On reflection, we could have modelled the user journey earlier, and reflected the complexity back into the user story estimates.
