Last month I was lucky enough to try out a completely new approach to running a stand at a software tradeshow, in Texas. Over 3 days we designed and developed a prototype for a new software tool. Using rapid prototyping techniques (paper and HTML/CSS prototyping) and Agile development methods, we were able to get feedback from prospective customers and iterate our designs during the tradeshow.
Our stand was specifically designed to provide a UX area for working on designs and gathering customer feedback, and a development area with a Kanban board to track our progress. We made the process completely transparent by putting up all the feedback we received on the walls of the stand.
I’ve written a case study of the ‘Live Lab’ concept, describing the process we used, on the Red Gate UX Blog. I’ll also be writing up the lessons learned in a separate post very soon.
In September I’ll be doing a talk on this case study at Agile Cambridge 2012. I did a warm up talk at UX Camp London last Saturday:
In advance of this year’s fantastic UKGovCamp (aka #ukgc11) I pitched a session idea on lessons learnt from using an Agile project management method to manage web development. My idea for the session arose after some interest in a blog post I wrote recently and the discussion on the UKGovCamp forum thread.
So on the day I came armed with my slides and stood in line to pitch my session. I was joined by Stefan Czerniawski and Catherine Howe, who pitched a second session to explore the potential for applying Agile principles to policy. This is an area I am very interested in, but as I have limited experience of working with policy makers I ended up taking more of a back seat in their session, to observe, absorb and blog some loose notes.
Thankfully Catherine has written up a brilliant blog post about the session. Which is a relief, as I was flagging a bit at that point and was finding it hard to stay mentally alert. I think I used up all my energy facilitating the first session and also felt a bit ropey from having stayed out too late the night before – my only regret about the whole day!
The session went far better than I could have hoped for. It was well attended and resulted in an open and fascinating discussion about the practicalities of implementing Agile methods and applying them effectively.
Photo by Paul Clarke
There was a real mix of participants. Some with loads of experience and some who knew very little about Agile, but were curious to find out more. In preparing for the session I hadn’t really considered that some of the participants wouldn’t be familiar with the Agile manifesto, terminology or methods like Scrum and the roles involved. So I did my best to explain the concept of Agile and the Scrum method in simple terms in limited time and some gaps in my own knowledge. But I realise that pitching the session at the right level, to address the varying experience and understanding of those in the room, was a challenge. I look forward to Julia’s notes on the session (as mentioned in her write up of the day) as a relative Agile newbie.
I explained that we have used the Scrum method in my organisation (a county council) for about 18 months for web development projects, with varying degrees of success. Here are the slides I presented in the session:
The following notes are written up from memory, as I was too busy talking (as usual) to write down anything during the session. I haven’t attributed these insights to individuals (in case I do so incorrectly!), but they were a combined effort of the participants who attended.
It can be difficult to introduce Agile methods when senior managers are sceptical. I recommended starting small by applying an Agile method to development of a mature platform, rather than choosing a project with significant risks and unknowns.
Someone asked if you can do Agile covertly. And the consensus was – yes absolutely! Agile can fit within existing, more traditional project management processes quite neatly, e.g. within the ‘product delivery’ phase of Prince2. It was even suggested you could do Agile within the ‘implementation’ phase of a waterfall method and by the time you get to the ‘verification’ phase, you’ve already done the testing you need to. Business people don’t want to know how you are delivering something, just that you deliver results.
But…and there are two big buts…
When a development team learns their velocity over time, introducing someone new to the team can throw things off balance. Estimation poker can help the estimation process, because developers have to discuss and resolve why there are differences in their estimations.
Developers can sustain their pace when working in sprint cycles. Following a waterfall method can result in a huge rise in stress levels as you approach a big bang launch and everyone is working overtime to get a product finished. Instead there are small rises in stress levels at the end of a sprint, but developers should be able to leave work at 5 pm and maintain their pace in a sustainable way.
The velocity of the team (progress over a series of sprints) can be greatly improved by having a UX designer produce designs in advance of the sprints.
Agile involves developers in business strategy, so they work towards achieving business objectives.
Although the Agile principles promote face-to-face communication and co-location of teams is often cited as being important, it is possible to use geographically dispersed teams if you make good use of technology. An example was given of how a team which is distributed worldwide use Skype to manage daily scrums.
Not everything gets finished at the end of a sprint. Developers must be prepared to throw code away.
Be flexible about the method and techniques you use e.g. user stories could be written up on cards and stuck on the wall, kept in a spreadsheet or a specialist application.
Agile can be applied outside IT contexts. One participant said that his organisation has applied Agile principles to business strategy projects.
I’d like to extend my thanks to Dan Hardiker, Andrew Woodward, Catherine Howe and Sharon O’Dea who all pitched in with excellent insights based on their experiences of working in an Agile context. I personally learnt loads from the other participants.
Which goes to show if you’re willing to share your own experiences, you get back a bucketful of new insights and knowledge from others in the process!
There’s been a flurry of conversation on Twitter in the last few days about the potential for the use of agile methods in the public sector. As a result @pubstrat created the hashtag #pubsecagile and started a thread on the UK GovCamp 2011 site.
I wrote a post back in November 2009 about some of the potential barriers to introducing agile methods to manage web development projects in a local government context. In the local authority I work for we’ve been using Scrum to manage web development projects and we’ve learnt some useful lessons, which I’ll discuss later on in this post.
In recent months quite a few public sector bloggers including @brianhoadley, @curiousc, @pubstrat, @publicsectorpm and @loulouk have written about agile methods. Some have touched on using agile principles and methods in different contexts (i.e. to software development) within the public sector. Some of the posts mentioned here suggest applying agile concepts within the public sector in non-IT contexts.
Agile methods such as Scrum, DSDM or XP were originally designed for managing software development projects. I won’t go back over this as I described the differences between the more traditional waterfall methods and agile methods in my previous post. Much of what has been written about agile methods (in books and online) also relates to software development.
The use of Lean methods has also been picking up pace in the public sector in recent years. Lean is a technique developed by Toyota to reduce wastage in their manufacturing processes. Lean has now been adapted for use in the public sector and is ideal for transforming public services to improve productivity and efficiency and achieve the holy grail of doing more with less.
Agile is known as a being a mindset or philosophy rather than a method itself. Looking at the Agile Manifesto it is quite possible to see how the concepts can be used in different contexts to software development. I’ve re-produced the manifesto below and simply changed the word ‘software’ to ‘systems’ (by ‘system’ I am referring to socio-technical systems that comprise people, processes and technology or non-technical systems i.e. just people and processes).
Individuals and interactions over processes and tools
Working systems over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on
the right, we value the items on the left more.
While researching this post I found a great presentation by David Anderson which he gave at the Agile 2008 conference. David spoke about the potential for using agile concepts in non-IT fields like marketing, design and recruiting. It seems from David’s presentation that even within the agile community the idea of using agile methods outside of IT software development projects was relatively innovative back in 2008.
More recently, the Agile Business Conference in October 2010 (organised by the DSDM consortium) focused on the naked truth of how agile methods are being used in non-IT environments and included a public sector track with an NHS case study. I would be really keen to see how those interested in the #pubsecagile Twitter conversations can tap into existing agile for business networks where conversations are already taking place. Interestingly the DSDM community members government list is distinctly lacking representatives from local and central government organisations.
But my feeling is a more open discussion is needed which as far as possible is agnostic of any particular agile methods. So bring on UK GovCamp 2011!
Where possible I am also trying to follow some interesting and innovative discussions in the agile UX community, for example the Agile UX Retreat.
So onto the second part of this post…
If you’re going to use an agile method make sure any team members responsible for delivering interdependent parts of a service redesign project delivery and senior managers are on board. You can’t expect other stakeholders to fit into your time boxes when you need them to, or to understand what you are doing. You must clearly outline the benefits of your approach up front and get their explicit buy in. If you don’t have all dependent parts of the project using an agile method you’ll run into blockers (issues) which you just can’t shift, which will impact on your burndown (progress in completing tasks on the sprint backlog) and ultimately the velocity (amount completed from the product backlog in each sprint).
One of the drawbacks of the traditional waterfall method is the potential that you can spend far longer than anticipated developing software because the scope is unwieldy and it can be hard to estimate in terms of time and cost. Worse still you might end up with an unfinished product and can’t accommodate changing requirements.
Going agile can provide more certainty and flexibility, but requires the team to estimate user stories from the backlog using complexity points, and then to break them down into tasks and re-estimate. Estimating the backlog should give you an indication of whether you’ll get a working feature or application within the time / budget you have available. The last thing you want is a situation where your burndown chart resembles a flatline on a life support system, because the estimates were inaccurate. The only way a Scrum team can really improve estimation is to keep reviewing their velocity in previous sprints. Which leads to the next lesson learnt…
If you have a mature application or website, you’ll probably find using agile methods a fantastic way to manage changes on a budget. You have control over the time and cost, but you can prioritise your user stories to ensure that only the changes which bring the most value to your users and the business are implemented.
Using agile methods for the development of new products or services carries more risk. In this situation you are more likely to have unknowns, particularly if you don’t already have a prototype or proof of concept. In this situation there is a danger you could still end up with a half-finished product when using agile methods.
If you are going the agile route, make sure you have dedicated teams that can fulfill the necessary roles of product owner, scrum master and those managing the product delivery (e.g. developers, user experience designers, content specialists). Don’t expect your project teams to manage lots of other committments during the sprint as they probably won’t have time. Product owners should be able to attend daily stand ups (in person or virtually) and spend time collaborating with the rest of the project team in planning and review meetings.
I don’t believe that you can effectively use agile methods like Scrum for web development projects unless your project delivery team includes all those involved in creating the finished product. Which for web projects includes content specialists and user experience designers, not just developers. You need to consider how software features will be implemented within an existing website and how users will experience the complete product as part of a user journey.
Most importantly, remember the 12th agile principle!
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
So what about those barriers I identified? Well here’s a quick run down of which of my predictions became actual barriers.
I work in a team that manages local government web development projects. We work closely with applications developers in IT and we do most of our development in-house. A couple of years ago we realised noticed a pattern in the way we were working. Some projects had complex requirements and often involved working with new technologies. Bigger projects took 12-18 months to complete, which meant that work on the other web sites or applications had to be put on hold.
Early in the project the teams would have workshops and lots of meetings with colleagues in the relevant council services (i.e. business areas). The project managers would develop very detailed specifications to document the requirements. We would produce wireframes to show how we proposed the interface would look (and sometimes we tested the wireframes with the site users). We would send these lovingly crafted specifications to our development team who would spend a few days reading through our bloated documents, trying to interpret what we meant. The development team would then work up a detailed estimate for the work. Between us we would spend a considerable amount of time negotiating scope and estimates before agreeing to proceed with development.
At last the developers could roll up their sleeves and start writing some code. The developers would work tirelessly to develop functionality that met all the requirements in the specification. Sometimes the developers weren’t able to complete all the functionality because they encountered problems they weren’t expecting because the technologies were new to us all. When the services got to do acceptance testing, they would ask for additional or different functionality, but by this time we’d used up the budget and run out of time to do any further development. If you hadn’t already noticed, I’m talking about the waterfall development methodology which follows a sequential process as follows:
We needed to find a way we could work more efficiently, improve communication with the development team and services and meet business and user needs more quickly.
Having recently finished the taught part of a Masters degree in Human Computer Interaction at UCLIC, I am finally finding the time to formally pass on some of my knowledge and skills to colleagues at work.
Since I started in my current role in local government in 2006 we have used some user centred design (UCD) methods with varying degrees of success. But we we are now aiming to use a UCD approach for all web development projects. This is a significant step forward and represents a real commitment within the team to improving customer experience on our web channels. We are about to start a series of projects to improve the customer experience on our corporate website (long overdue!) so I am really pleased to be starting out on the right foot.
So what do I mean by a user centred design approach? I like the UPA definition:
User-centered design (UCD) is an approach to design that grounds the process in information about the people who will use the product. UCD processes focus on users through the planning, design and development of a product.
But in essence, in my interpretation, it is about the process of designing technology that is useful, easy to use and pleasant to use.