Demonstration Stream

Completing the circle

Facilitated by John Ferguson Smart

Automated web tests, ATDD and Acceptance Tests as a team communication tool

Acceptance Test Driven Development, or ATDD, has proven to be a very effective technique, both for driving and guiding development, and for enhancing communication between developers and other project stakeholders. But why stop there? Well designed Acceptance Tests can also act as a formidable documentation source and communication tool. Indeed, when written in a narrative, BDD-type style, Acceptance Tests have the potential to document in detail how the user interacts with the application.

In this talk we will look at the role of automated Acceptance Tests not only for testing, but also as part of the whole development lifecycle, from writing the user stories right through to deploying the application. We will also look at ways to make your automated acceptance tests more expressive and how to use them more effectively as a communication, reporting and documentation tool.

Finally, we will present and demonstrate a new open source library that helps developers and testers write automated acceptance tests for web applications using WebDriver/Selenium 2. This library also produces clean, narrative-style reports illustrated with screenshots that effectively describe the application's functionality and behaviour, as well as any regressions or pending features.

Collaboration Games

An Over the Edge Experiment in Group Process

Most all games have a winner and a loser. The basic version of The Collaboration Game is one where the only way to win is for everyone to win. But there are also variations which simulate the different roles and conflicting objectives found in real life groups working together. Consider it an over-the-edge experiment in group process.

Evolution of Agile

Facilitated by Juan Barberis

Heritable characteristics of experiences giving rise to diversity of a System organisation.

Software Development was initially based on coding and fixing. That worked well for smaller software, but as the size and complexities of software grew a need for a proper process was felt because the debugging and testing of such software became extremely difficult. This gave birth to the Engineering Methodologies.

Many of the individual principles and practices that are promoted by agile development have been around for years, even decades. As opposed to implementing these best practices piecemeal, agile methodologies have "packaged" various customer, management, and in some cases, engineering practices and principles together in a way that helps guide teams through the process of rapidly planning and delivering working, tested software. Each of the agile methodologies combines both old and new ideas into refinements that are certainly greater than the sums of their parts.

While it is true that many of the practices associated with agile development have been around for quite some time, the average software development team has yet to embrace many of the principles and practices. Even today, the average software team does not iterate, does not deliver software incrementally, and does not practice continuous planning nor automate testing. Now that these practices have been combined in a manner that can more easily be understood and adopted, the trend appears to be rapidly changing for the better, especially during the last several years.

As with any new way of doing business though, Agile methods have generated quite a bit of controversy within the software community. Yet since their emergence, in project after project, they have continued to deliver higher quality software systems in less time than traditional processes. If you are a software development professional, you definitely owe it to yourself to become familiar with the theory and practice of agile development. Hopefully the information presented on this site can assist.

Business Value Modelling

We talk a lot about "maximizing business value". We ask business people and product managers to prioritise by estimating the business value of user stories. But what exactly do we mean by business value?

Over the past few years we've worked with many teams to define their "Business Value Model", a clear definition of the value a project will bring to the organisation. The exercise hasn't always been easy but it has always brought significant benefits:

• Measurable business value in units that impact the organisation
• Everybody involved was more motivated because there was a clear reason for the project and they finally understood what it was
• The whole team was aligned around one vision because we had clear criteria to define success
• We came up with more innovative solutions because everybody on the team, not only the "business" or "product" managers/owners could take product-related decisions based on the model
• We could deliver a lot faster than anybody expected because the Business Value Model allowed us to easily distinguish between value-adding and non-value-adding features
• We spent a lot less time writing and prioritising user stories because we were able to derive the user stories from the value definitions
• The Business Value Model guided us to explore new product ideas: the business value model was a hypothesis that we could test and refine each time we released or performed user testing.

In this interactive tutorial you'll apply some Systems Thinking techniques, such as the Diagram of Effects and Intermediate Objectives Map, to define the business value model of an example project. We'll show you the techniques we used and discuss how you can apply those techniques in your context so that you'll be ready to start building a business value model with your team.

Agile Approach to Fixed Cost

Fixed Priced contracts don’t make a great deal of sense in a Scrum world. This is really because traditional software development and Agile software development are two different paradigms … and solutions that work in one paradigm often doesn’t make sense in another.

In an environment where clients are only given one shot at getting the product they want, it makes sense to define your requirements upfront, and to then manage any risk by putting a dollar limit on the cost.

Agile teams are collaborative. And, they work the Product Backlog in the order specified by the Product Owner. If it makes sense to deliver high value functionality earlier they will do that. And, a good team will continue to incrementally deliver high value functionality on an ongoing basis.

The risk profile to the client is now substantially different because they’re getting regular increments of what they want in the order that they’ve specified. So, it’s reasonable to argue that a new type of contract would be more sensible for the new paradigm. And indeed there are different types of contract that work better than others [in an Agile environment].