Archive for December, 2007

Where does the "designer" fit into my agile team?

Sunday, December 30th, 2007 by admin

When embarking on a IT project the word “design” almost always conjures up visions of a solutions architect or systems designer. However, in the web world these people are visual designers, interaction designers or experience architects. Throw in usability specialists as well and you have a whole host of other very important professionals on your team who also have their own methodology: User-centred Design.

The agile community has been slow to pick up on the existence of these individuals and even slower to work out where they fit in agile project teams. I first did my research on the interaction of UCD and Agile back in 2004 and the main questions have still not been answered!

The first question is “what kind of beasts are these designer types? Are they customers, users or part of the team?” Personally, I find it very difficult to put my finger on exactly what they are in Agile terms but in Scrum teams I prefer to look at them first and foremost as part of the team. They are contributing to the sprint goal just the same as the development team are. They introduce requirements but these are largely in order to guide the customer on what is required - is this so different to what the development team do? I ask myself.

(more…)

User Centred Design - what is it?

Saturday, December 29th, 2007 by admin

UCD is a philosophy whereby the user is the focus of all design decisions. The extent to which real users should be involved in the design process tends to differ from practitioner to practitioner but that is not to say that the user’s best interests are not central to the design process in each UCD faction.

A significant part of UCD is establishing the needs of the user, this often includes focus groups, interviews and surveys.

Another technique is user testing on existing products in order to perform an evaluation of how well a product meets the needs of users. A number of users are recruited and then talked through processes by the “tester” in an environment closely matching the one in which the product will be used (such as a living room or workplace). This is not a test of the user but of how well the product works for the user in a real-life scenario. This technique can also be used in the earliest stages of development when the design of the system is still at prototype stage. Even paper prototypes can be useful in gaining an insight into how a product might be used or perceived by perspective users. The extent to which user testing is relied upon will differ from practitioner to practitioner.

Increasingly, the design community has relied on techniques under the umbrella of “contextual evaluation”, (Holtzblatt and Beyer 1993) which is a way of probing the activities of users while they carry out typical tasks in their usual environment. Techniques range from “Contextual Inquiry”, where the user is questioned and observed in context, to other more immersive techniques such as ethnography which involves much less interaction with the subject.

In addition to these methods, “card sorting” is a technique used (most notably) by information architects to find out how users categorise and group elements of the product’s architecture. For instance, in a card sort for a recruitment website the user may group “pay scales” and “tax” under “money”, indicating that in the navigation structure these two categories should be found under an umbrella heading of “money”. User’s needs as well as preferences are investigated with these exploratory techniques so that accessibility requirements can also be factored into the design.

UCD is not a methodology or a design lifecycle. There is no agreed definitive model of how a UCD design process should work (although many have been put forward). What is integral to UCD across the board is the focus on iterative design.

The UCD approach continues to gain prominence, particularly in the area of digital applications.

UCAD

Saturday, December 29th, 2007 by admin

User Centred Agile Design

Click on the link above to read my paper on how to manage agile projects whilst ensuring that the user has a say too!

What is Scrum?

Saturday, December 29th, 2007 by admin

What is Scrum?

Scrum is just one of a collection of software and software delivery methods known as “Agile Methods” and has evolved from the need to develop software in an increasingly competitive environment.

In a nutshell…

Scrum defines a time-scale of 30 days for each iteration of a software product. These iterations are known as “sprints”.

Throughout the sprint the team is managed by a Scrum Master who acts as a facilitator, organising the short daily scrum meetings used to monitor progress.

There are very few artefacts involved in the Scrum process. The Product Backlog is used to store the required functionality that a product might have. The “product owner” owns this log and prioritises each item and others such as users, customers, sales and engineering give input into its contents.

At the beginning of a Sprint, a Spring Planning Meeting is held. The outcome of this meeting is the “Sprint Backlog” which details the product features to be included in the current Sprint. The development team estimate how long the tasks will take and whilst applying the prioritisation, the Product Owner determines what can and can’t go into the sprint based on time and resources available.

At the end of the Sprint a Post-Sprint meeting is held to review progress and to demonstrate the new features of the product.

The goal of each sprint is to deliver “executable functionality” and the goal of the last sprint is the delivery of a shippable product.

Scrum is characterised by the Agile principle of Simplicity ensuring that the product created is always fit for purpose but never over-engineered.

To find out more about Scrum please read

Schwaber. K. and M.Beedle (2002) Agile Software development with Scrum New Jersey, Prentice Hall.

 

Introduction - The Agile Revolution

Saturday, December 29th, 2007 by admin

This blog is primarily about project management and will give readers an excellent insight into the daily problems facing Agile project managers. If you don’t know what agile is, well read on as that will be coming up next…