Topics

You've been there. You are tasked with implementing a product that someone else cooked up. What do do next? Follow the spec you say?

Wrong!

Developing a product without this Vision is not just waste, it is bad business for you and for your customer. Before we start implementing any product we must explore it's reason to exist, what customers it benefits and ultimately how it can help your customers (not you!) make money.

In this workshop we will take an example and go through a simple process that helps us explore a product idea to the point that a spec is just a reference, but the product comes alive in the minds of the team members.

Organisational change fails more often than it succeeds – so say some – but why? When promoting change in an organisation, have you considered the conditions that allow change to take place in the first place and to be sustainable afterwards? This interactive workshop start from the Six Conditions for Change from the work of Clare Graves and expands with some related models, all with the target of mentoring the participants on using the learning in practice.

Software development is not a production process but a collective creative process. Analogies would be improvisation theatre, team sports or the behaviour of socially living animals. The “collective” aspect of software development is not only about arranging duties and solving integration problems. The key part is distributing and sharing information and making individual knowledge available to all team members.

Traditional approaches are asynchronous, rendering the team a set of individuals rather than a whole complete in itself as it is demanded by the agile philosophy. The step beyond is real-time collaboration: common synchronous crafting on the same artefacts by several individuals. Changes are distributed instantly; the artefact itself becomes an additional communication channel.

This workshop is designed to give people a real feel for the different style of work without need for knowledge of specific software technologies or development approaches. We will give teams a task to accomplish together using Google Docs. You only need to bring a laptop that can run Google Docs.

Creating awesome web apps for human end users is challenging. Understanding requirements early and turning them into a working solution is crucial to get the right thing done and minimize wasted effort. Additionally, in case of complicated apps with a longer development lifecycle, the codebase can gradually lose its flexibility and be in danger of regressing into unmaintainable legacy spaghetti.

There exist various different approaches for both of these problems, but Acceptance Test Driven Development (ATDD) provides a method for tackling both while providing some additional benefits. In this session we are first going to discuss the why and what, and then try the tools and techniques of ATDD in an example case to learn how to enable building great web apps.

Note that terminology around the theme abounds. Similar or related topics include at least Test Driven Requirements, Functional Test Driven Development, Behavior Driven Developmen, Story Test Driven Development, Executable Requirements, End-to-End Test Driven Development, Customer Test Driven Development, Business-Facing Test Driven Development, and Specification by Example.

Liftoff – it's the unexplored, often ignored, Agile project practice. Liftoff gives impetus to your projects in a way that starts the project team, and the business, on the trajectory to success. As the first act of the flight, a rocket launch requires an entire set of systems to successfully lift the vehicle into orbit – not just the vehicle itself, but all the systems needed for smoothly moving off the ground into space. Likewise, your project needs its entire set of supporting systems in place to begin a successful journey to delivery.

In this workshop based on her new book, Diana Larsen will lead you on an interactive mission to explore effective Liftoff meetings, including the newly introduced Agile Chartering model.

With the emphasis on in-depth customer interaction during development, agile team members are being asked to take an active role in working with customers. This evolving role poses a big challenge for many who, in the past, rarely met “real” customers. Linda Rising presents patterns she has used successfully to help software professionals in their direct, face-to-face interactions with customers. These patterns describe solutions to common problems that occur again and again when dealing with customers and users.

The patterns Linda discusses have memorable names such as It’s A Relationship—Not A Sale, Be Responsive, Show Personal Integrity, Build Trust, and Take Your Licks. Pattern names build a vocabulary that allows you and your development team to have meaningful conversations about—and to ultimately improve—customer relationships and the software you deliver.

Benefits from this tutorial:

• A vocabulary based on patterns to improve communication with customers
• Simple and powerful ways to improve your own personal interactions
• How to focus on what is best for both you and your customers

Outside-in development doesn't mean starting at the user interface, it means starting at the outside of whatever you want to discover.

On a brand new application, the first thing you need to discover is your domain model. Those fancy ajax gizmos can wait. This session will be a kata-style tutorial. Working from a single Cucumber scenario, we will drive out a domain model, then like BDD magicians, we'll slip in a user interface around the domain model without touching the tests.

Attend this workshop to learn how to write Cucumber scenarios that last, by expressing them in the language of the domain. You'll learn how to engineer high-quality Cucumber step definition and support code, and see the benefits as your application evolves. A masterclass in BDD as it's meant to be done.

This is intended to be a hands-on tutorial, so to take an active part, please ensure you have installed Ruby and the Cucumber, Capybara and Sinatra rubygems. If you just want to come along and watch, that's fine too.

Git is a versatile tool that can be adapted to multiple different workflows. Possibility to have feature branches, code reviews and rebase provide a solid toolset to maintain your code cleaner and let people collaborate without a big overhead of managing version control system.

Distributed version control systems have also added new and different ways to organize the work. No longer people have tied to a centralized server or internet connection, there's a new kind of freedom to do things.

This workshop will go through practices that will help your everyday development using git. The idea is not to present One True Model(tm) that works everyday, but to offer you a set of tools that you can ground your own agile development workflow on. Aim is also to cover some more advanced topics of git, like rewriting history, hooks and recovering from disasters.

For the workshop a laptop and basic knowledge of git are preferred, though not mandatory :)

When a cross-functional team commits to delivering a software product with the highest possible quality, that commitment needs to be meaningful. Lisa Crispin's team recently discovered ways to enhance the usability of their web app, and significantly reduce user mistakes, but their GUI test tool doesn't accommodate the new technology. Come hear how Lisa's team has pulled together - though it was difficult - and conducted several experiments to look for a good solution. It's not the path of least resistance, but it's a path to success that any team can follow.

Everyone has a story on how it all begun. Often it is to replace an old, perhaps poorly working process to something that promises, well, more agility. Other times you're looking for more bang for the buck. Sometimes you simply want things to change. At Lindorff the introduction of agile has been a developer-driven iniatiative, where the primary driver was to do things better.

This is a talk about how it is to go from no process to scrum and beyond. We'll look into what kind of challenges a truly bottom-up transition in an enterprise setting might run into and how you can smooth things over.

Realtime monitoring provides everyone on a team, as well as interested stakeholders, with a shared and deepened understanding of how a system performs. Visualize it and you get direct feedback form the heart of your system. In this session we want to share our experiences with introducing monitoring and how the feedback it provided influenced both system design and team collaboration.

We will use Graphite, a monitoring tool that makes data gathering no harder than printing “Hello world” and realtime visualization even easier. We will show how a monitoring tool like this; simple, instantly available and used continuously; was instrumental in implementing change in behaviour and collaboration.

The FedEx Day is a twenty-four hour time-boxed innovation happening of hacking, prototyping, and presenting that involves everybody in a software team. The idea was invented by Atlassian but it has gone viral. Ambientia has done seven FedEx Days (http://blog.ambientia.fi/tags/fedex-day/) and is enlightened by the results. Please check out how may reinvigorate your team and get amazing results just in 24 hours.

Why o why do I always fall into those Avalanche method (some call it waterfall) acceptance testing projects.. Well like the challenge, and there are always possibilities and methods for avoiding stiffness and becoming more agile, regardless of what it is you are told to do. I’ll talk about some of the ones I’ve sometimes found useful and which I would like people hiring, working with, or working as testers to think about.

To create an awesome product two things are important from the start: common understanding of the vision, and validation of the idea behind it. The best we know to reach these goals is to create a prototype. We would like to tell you how we do it.

• Why do we separate development from maintenance and operations?
• Why do system architects chose frameworks and write UML diagrams but do not write any code?
• Why do we measure how many lines of code a developer writes?

The theories of Frederick Taylor and those that followed them still today sets the norm for how organizations are managed. What we see as normal and common ways to organize work have their historical roots in early 1900's steel mills. These practices make agile adoption difficult, hinders empirical processes and self organizing teams.

The talk provides an explanation to why IT-organizations are managed like factories, why these fail, and how to start the change into a succesful agile organization.

Keeping your options open is often desired, especially under circumstances where you don’t know what’s around the corner. How do you do it then? How do you make sure the last responsible moment doesn’t turn into an irresponsible approach where you let the circumstances decide for you?

In this talk Ola tells stories and gives examples from software projects, business and everyday events how real options can be applied. Furthermore he describes how you can systematize option creation and exploration in almost any context. This talk is intended for people who makes decisions on software projects or would like to help others through option creation and exploration.

As the author of The Cucumber Book, surely we'd expect Matt to be selling us on tools? Quite the opposite: This entertaining talk describes how so many teams get distracted by tools like Cucumber, and forget about what really matters. You'll leave with a clear vision of how BDD really works.

Increasing productivity faces significant challenges when you have almost 50 Scrum teams, and over 200,000 lines of code changed during each sprint. Every misunderstood requirement, every hasty change in the code and every bug introduced will result in massive costs without fast, reliable and automatic feedback mechanism.

This is a true story of a Heimlich maneuver performed on software architecture and development of a product the size of eight Linux kernels. We promise you that after listening to our story you won't think "We can't do it because we're so special".

According to Standish group, 67% of software projects fail - bullshit!

We challenge traditional meters of success and present practical tools for better software projects.

Includes case study of a project which was late by a whole year - and customer was satisfied!

Agile is all about empirical processes, controlled by feedback loops. But what does it mean?

Most agile practices and principles are rooted in control theory. Truth be told, most ways of doing things well are. Knowing these root concepts will improve the outcome of any undertaking, software development or other. In this “popular science”-session, software development will be described as a (simplified) mathematical process. The session will teach how feedback, sensors, noise and delays affect outcome, error, robustness and other properties of a development process.

I've wondered for some time whether much of Agile's success was the result of the placebo effect, that is, good things happened because we believed they would. The placebo effect is a startling reminder of the power our minds have over our perceived reality. Now cognitive scientists tell us that this is only a small part of what our minds can do.

Research has identified what I like to call "an agile mindset," an attitude that equates failure and problems with opportunities for learning, a belief that we can all improve over time, that our abilities are not fixed but evolve with effort. What's surprising about this research is the impact of an agile mindset on creativity and innovation, estimation, and collaboration in and out of the workplace.

I'll relate what's known about this mindset and share some practical suggestions that can help all of us become even more agile.