More than XP. More than one day.

Synopsis

The principles of test-driven design/development (TDD) also apply at higher levels - the processes of requirements capture, system specification, high-level design, system integration and user acceptance. But to get the maximum benefit from this approach requires a change of emphasis from “test cases” to “examples” (which are virtually the same as “user stories”) in order to gain the co-operation of the business. And without a suitable automation framework, the required effort would outweigh the benefits. Luckily there are several to choose from!

As projects continue, a secret backlog is growing. The items in this backlog never seem to be as cool or interesting as the shiny new features described in the user stories of the product backlog. Where user stories tell us what we want the system to do, this secret backlog tells us all the things the system does, that we don’t want it to do… This secret backlog is our bug-list. This experience report highlights how a bug-list can be a symptom of one or more problems in a team’s approach and how solving those problems didn’t make bugs go away but did make the bug-list redundant.

When an agile team works with their customer, how do we ensure we speak the same language? How do we incorporate the business domain concepts into our code? How do we know we’ve got it right?

In this workshop we will explore how people approach these problems, what you’ve tried and how it worked out. We hope to reflect on our collective experiences and learn how we can improve.

BT, as part of its Agile transformation, has widened its Agile footprint into the demand-side of its business. This is being achieved by using Agile techniques in a forum called an Agile Round Table (ART), which is run as early as possible in the decision making process for new concepts. In this context, we present an overview of this forum as created and used in BT. Using an early example, this experience report illustrates the preparation and running of this forum and how, by working closer to “the light bulb moment”, we have derived further successes by using Agile techniques.

Are agile methods defence mechanisms for developers? Do interaction designers spend far to long interviewing users when coding would eventually give more solid results? How can usability feedback get quickly integrated into builds?

In this session, Stephanie Chamberlain and Helen Sharp will explore the knotty problem of integrating the User-Centred design methodology with Scrum and XP. The presentation centres on a study of 3 project teams within a large media organisation and then focus on some practical solutions.

Across the Agile community there has been a lot of discussion regarding the use of technical stories. While the community seems split into two camps of for and against, the majority of extreme programmers favour to define the system using only the traditional customer focused user stories. In some cases the technical story arguments are academic, but our experience report demonstrates clearly why sticking to user stories has its benefits. Our experience using Scrum and XP has been that allowing technical stories into the process

Agile methodologies focus strongly on functional requirements. The methods we use (the planning game, an on-site customer etc) give clear guidance on how to derive them, define them and track them on our agile projects. Non-functional requirements are the ‘ilities’ of the system. Things like ‘compatibility’, ‘availability and response times’, ‘scalability’, ‘reliability’. These are a bit more slippery and are causing us to scratch our heads in lots of ways.

This Goldfish Bowl is proposed as an exploration of non-functional design in Agile. In particular, it provides a space for practitioners to discuss what has worked, or equally what hasn’t.

Synopsis:
How we developed a suite of acceptance tests that draws together the components built by five agile development teams into a cohesive product. Not only does it constantly test the individual components and the system integration, it also provides a living document of system behaviour.

This is our experience with various tools and methods that lead to an approach that provides our developers with tests to drive development, our customers with live documentation, our managers with reports and our organization with high quality software.

The session will cover how a BA has learned what works well and what is not so useful in the environment she works in. The aim is to show how the agile approach can be adapted for different sizes and types of projects and how team dynamics change based on the team size and what the team are trying to deliver.

Product owners and other customer representatives play a crucial role in agile methods such as Scrum and Extreme Programming: Product owners are responsible for creating the product vision, writing user stories and stocking the product backlog, reviewing work results at the end of the iteration, and creating the release plan. This is where theory stops for most projects. In reality, product owners are overworked and difficult to get hold of. They are often poorly trained in agile and are sometimes uncomfortable to work closely with a bunch of techies. Often product owners are not properly empowered by their managers. At the same time, there is a strong correlation between effective product owners, successful products, and healthy projects. Not having an effective product owner tends to result in suboptimal outcomes. The objective of this clinic is to gain a common understanding of wide-spread reoccurring product owner issues and their causes. We will identify ways to overcome the causes and to develop effective product owners that drive healthy agile projects.

Description

SCRUM and related agile methodologies advocate the use of iterative and incremental practices in order to control the complex process of building software. The idea is that new functionality is delivered fast and that a product that satisfies all its stakeholders is built in an incremental way. This creates a challenge of “choosing” the right functionalities for each release (= release definition). Unfortunately, as studies have shown, the right features are not always chosen. Standish has observed that as much as 45% of product features are never used.

The Agile community has traditionally focused on delivering “Working Software” over “Extensive Documentation”.