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!

Any team attempting to become agile has two fundamental problems to deal with. They have to figure out how they are going to work differently, and they have to figure out how they will interface with their surrounding organization. Much has been written about the former, but not much has been written about the latter.

In this workshop, we will attempt to discover and classify the different organizational contexts that that agile can exist within. We’ll look at culture, competitive conditions, business type, and any other variable that we can discern. At the end of the workshop, we’ll present our findings and offer them up to the community as a basis for future exploration.

It isn’t hard to find information about TDD these days. There are several books on the subject, and plenty of web resources; however, almost all of them are written with the assumption that you’ll be using Java, C#, or a dynamically typed language in your work. Hardly any of them are written with C++ in mind.

Using Scrum in single development teams had become second nature to the central BBC new media department, creating software for the entire organisation. We had been working more efficiently and with more transparency than ever. However following a reprioritisation of projects and the initiation of the flagship project, the BBC iPlayer, these teams were having to work together on a shared project for the first time.

The world is full of ideas. Millions of ideas are given birth every day and millions are killed just as quickly, usually before they have had a chance to make a lasting effect on our world. But some ideas do “stick” as they say. What makes those ideas successful and how can I make my idea stick? That’s a question I believe many proponents of Agile methods have asked and would like an answer. I’ve created this workshop to help the participants find an answer.

Agile is a term often (but not always) associated with the term ‘project chemistry,’ or the positive team climate that can contribute to high performance. A qualitative study of personal experiences in development teams was therefore conducted to gain a better understanding how agile methods contribute to team motivation and cohesion. Presented research findings draw from social-identity theory, self-regulating team literature, and socio-psychological literature, and explain not only how, but WHY agile methodologies support teamwork and collective progress.

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.

How is your project doing ? How long does it take to find out what’s going on? Where is the essential information? Is it hidden, squirreled away inside thousand-line code files, spreadsheets and Word documents ? Or is it “in your face”, shown where you can’t help but see it every day ? A successful project isn’t successful because the team makes no mistakes, or suffers no setbacks. Whether your project sinks or swims is determined not by circumstance but by the speed and quality of your team’s response. This tutorial presents simple techniques to make project status visible early and continuously, so a team can respond effectively. The techniques can be implemented with simple office tools: flipcharts, markers and yellow stickies.

Abstract
A good domain model defines terms and concepts that make sense to both the business and developer, allowing them to communicate. Eric Evans claims that "with a conscious effort by the team, the domain model can provide the backbone for [a ubiquitous] language". Meanwhile the open source Naked Objects framework automatically renders the domain model objects directly in a generic UI (rich client, web and others). In this session we’ll explore how Naked Objects’ ability to animate the domain model allows the ubiquitous language to be developed rapidly, and without any particularly conscious effort on behalf of the team members.

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.

An initial 40 minute presentation will highlight the principal drivers behind the need for businesses to reconfigure ever faster to meet changing market demand. On the supply side this will include a brief survey of:
- how increased competition accelerates commoditisation and places increasing emphasis on the customer experience
- how customers’ switching costs and are reducing
- how this impacts the product lifecycle and producer margins

On the demand side it will review the causes of ever increasing market clock rate and rapidly changing customer expectation, including:

This session provides an introduction to creating a release plan with user stories. We start with a short presentation to introduce the basic approach. Participants then get to try the techniques for themselves through a series of exercises working in groups. The exercises have been used in training courses where we find students quickly get into the role play.

The yellow brick road is the difficult path Dorothy takes towards the Emerald City to find the mysterious Wizard of Oz to help her get home. In this session, we will help you to tap into the resources you’ve always had but never realised to complete your quest for a more Agile organisation. Here’s a chance to swap your bit part for a major role in the Agile re-telling of ‘The Wizard of Oz’ for your organisation.

Starring:

• You as Dorothy
• Agile as the Emerald City
• Agile adoption path as the Yellow Brick Road

In “Mr Smith Goes to Washington” we follow the journey of an idealistic politician as he learns to deal with the political side of Washington. Likewise, agilists undertake a journey where we learn that it takes more than working software that meets business needs for software projects to truly succeed. As with polite after-dinner conversation we do not always discuss the taboo topics of “politics” and “religion” in the agile community. If we pretend that the political dimension does not exist on agile projects then we cannot develop and share practices that help us handle these situations. This panel brings industry professionals to share their perspectives and experiences, the audience should come prepared to both ask and answer questions.

What happens when you put together a crack development team and get them to decide which tools, frameworks and libraries they'll need to do the job? Will we get (a) a happy consensus reached by rational argument, (b) a never-ending irrational argument about which automated testing frameworks to use? We're not sure what to expect, but we're looking forward to finding out what YOU think is important!

The majority of coding dojos are run using reasonably well known langauges such as Java. While this allows relatively complex problems to be solved, it also allows participants to take relatively large steps and get away with it. This dojo uses the same format as that created by Laurent Bossavit and Emmanuel Gaillot, but is aimed at reinforcing the idea of taking baby steps. This is achieved by using a language we hope is not known to the participants.

Agile projects fail. All the semantic manouvering around the definition of “failure” still can’t hide the fact that some Agile projects do “crash & burn”. Why does this happen, how can we recognize it, and what can we do to prevent this from happening? The more popular Agile methods become, the more we as a community will have to address, and find answers for, these problems.

This talk will present a taxonomy of Agile project failure modes and causes, and will present a forum for attendees to share their experiences, be they failure, or success.

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.

If you want to see software teams and organisations differently, from a people/culture/behaviour perspective, come to this session! You can reinvent the wheel, but you don't have to - therefore we based this on session on Gerald Weinberg's cultural patterns.

There are many models and frameworks that focus on 'processes', they're about maturity, about what one ought to be doing in order to be effective. In this session, we'll present a fresh perspective on software organisations, a people oriented instead of process oriented view. The model focuses on subculture and people's behaviour.

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

Four members of a 50-strong distributed agile team will present and discuss some of the free tools currently used to support and facilitate agile development work. Three aspects of the agile software craftsmanship are examined: project status visibility, immediate feedback, complete automation. The presenters will speak about their experience on configuring and using some of the most popular free tools to effectively achieve results on these three aspects.

Like many international organisations, Yahoo! has a Process Group, who’s role it is to help manage the huge portfolio of projects. This generally involves prescribing a standard process, which can be challenging for Agile methods that emphasise self-organisation. This presentation describes how Yahoo! have approached that challenge, and what solutions they have come up with.

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.

While working on the next generation web portal for one of the leading UK online betting systems, we had to fight the attitudes and technology to bring database development into an agile form. The solution for the problem turned out to be a mix of practices and tools, including a new database testing framework, written for this project but now published under GPL. In this session, we’ll share our experiences and present tools which we used to effectively fight the monster.

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.

Have you ever felt like you’re surrounding by a group of crazy people making insane decisions?

Sometimes we put this down to office politics, but that doesn’t actually help us deal with it.

In this session you’ll get a chance to learn about biases that affect the way people think. We’ll use this knowledge to develop an understanding of these difficult situations. Why did they occur? What can we do to prevent them happening again? And, given that we too are people, what can we do to improve our own decisions?

Should we use build & deployment teams on large projects? Build & deployment work often emerges as a specialisation on project teams. This specialisation becomes important on medium to large projects as the complexity of deploying code and configuring enterprise environments increases. But how do we coordinate the work of this team with the work of the development teams and how do we ensure this team helps the development team that it serves rather than hinders it?

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.

For years the norm for object developers was to work in an evolutionary (iterative and incremental) manner but for database developers to work in a more serial manner. The predominance of evolutionary development methodologies such as Extreme Programming (XP), Feature Driven Development (FDD) it is clear that the two groups need to work in the same manner to be productive as a team.

Nick will present material from the book “Refactoring Databases : Evolutionary Database Design” on how to go about doing evolutionary database development and will talk about the following techniques:

Following on from demonstration and exploration and of the idea that TDD and non-TDD codebases seem to have different statistical properties (XPDay 06, Spa 07, Agile 07) , this session explores how to make use of that as a guide to refactoring in practice.

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.

What do you do that adds value? What doesn’t? What would your customer choose to pay for?

This workshop is an introduction to Lean Software Development, including a discussion of Waste and a practical introduction to Value Stream Mapping. Waste is anything that does not create value for your customer. A value stream map is a simplified drawing of the activities your company does to produce software. It distinguishes between ‘value’ activities and ‘waste’ activities.

The software development industry is a paradox: on the one hand software is becoming increasingly pervasive and adds huge value to society, but on the other hand, our industry remains plagued by failure. Clarke will describe how a simple misunderstanding of quality principles during the 1970’s resulted in the widespread adoption of development methods - the waterfall model and it’s modern equivalent the “V” model - which are simply unsuitable for product and software development work.

I spent a good part of my career thinking that Project Managers are either well meaning idiots or bad intentioned manipulators. All that went away, of course, when I started managing projects and I discovered that most Project Managers are - just like most developers - good people trying to do a hard job. This session will explore the causes of common conflicts between the “workers” and the “managers” on software projects. We will discover a generic pattern hidden behind these these conflicts and ways around them.

During the last two years the presenter lived in Bangalore and worked for ThoughtWorks India. He run a product development project that had a duration of one year, a fixed-price contract, customers in the UK, a 3 person team in the UK and a 45 person team in India that was run in an Agile way. This experience report tells about which Agile practices still hold in this situation and which Agile practices needs to be adjusted.

Teams improve their chances of success when they demonstrate agility - the ability to deliver value to customers repeatedly, maximising ROI for the business while dealing with change in a rational and empirical way.

Many organisations, despite trying to be agile, still see their projects fail. Is it because ‘Corporate Agile’ is a compromise too far? Adaptations undermining the values and principles are often made to agile methods so they fit into the corporate culture, are more acceptable to management or to make them easier for people to perform. Do these compromises degrade a team’s agility and lead to an accepted mediocrity that increases the chances of failure?

Are we “crossing the chasm” or being driven out of our own movement by parvenues – or are they the same thing? Are the pioneers of the movement burning out from having to repeat themselves so often, or is it just time for new blood? Is there anything we can, or should, do to address Cargo Cult Agile? What is Agile anyway?

This tutorial is about how to use the stresses of writing unit tests to improve your code. If I’m having trouble writing tests, it’s often because the design of my target code can be improved. The trick is to listen to the tests and let them drive my development — that’s why it’s called Test-Driven Development. You too can learn how to find the rough edges in your tests and use them for rapid feedback about the quality of your code.

Bring some examples on a USB stick and we can work through them.

Summary

This hands-on tutorial teaches Test-Driven Development and Mock Objects using the JUnit and jMock 2 libraries. We will cover: What is Test-Driven Development? Why is it so widely used in Agile projects? What are Mock Objects and where do they fit into the TDD process? How are tests and Mock Objects used to drive good object-oriented design.

Although developer testing has reached the mainstream, when looked at closer, we often find that these tests are in fact not helpful. Low quality tests prevent refactoring, create a false sense of security, and confuse the developer. This interactive presentation addresses the assessment of developer test quality.

Description:

The primary purpose of this interactive workshop is to help developers improve their ability to read and understand code. Along the way, through a series of hands-on exercises working on raw-and-uncut code, workshop participants are also likely to develop their refactoring skills and perhaps even learn some testing trickery.

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