David Allen’s GTD, Getting Things Done, is a set of simple things you can implement in your daily life to greatly reduce stress and become more efficient in your personal and work life.
A lot of GTD can easily be mapped to how people behave when Lean and Agile is successful. We explore the basic set of GTD tools and how they can help us to be both Lean and Agile. We will cover: Natural Planning (maps to XP Planning Game), GTD Workflow for transforming wishful (stressful thinking) to actions, Ready For Anything – how to prepare for the unexpected.

System Metaphor was and is an elusive practice of the original XP. It has largely been forgotten over time.

Yet in the past few years, my colleagues and I have discovered the stunning power of a genuine System Metaphor on our own shipping product. This makes us wonder why System Metaphor ever went out of vogue.

This session will explore why Metaphor matters. We’ll examine how our own Music Metaphor reshaped our flagship product, even our company, and how the right metaphor can supply the driving beat that can turn your product into a hit.

The introduction of the agile practices is not so easy and immediate and each organization and it’s important to consider which impact agile may have keeping in mind the technology used by the organization that is usually the mirror of the background developers have.This session will drive you in the difficulties (and the solution put in place) experienced during the adoption of agile practices with Flash Platform developers, focusing on this points: -Tasks definition -Conversations’ output recording -Pair programming -Dependencies injection -CRC cards -Sustainable software

You understand “steady state” Agile practices, but how to begin? Embedded systems development holds challenges such as: • Software tightly coupled to inflexible hardware • Team enmeshed with other departments • End customer can’t interact with you

Agile principles need not be watered down when you are faced with the challenges of embedded systems development. On the contrary, they truly shine in complex situations with too much uncertainty for sequential processes to work well. Practical proven techniques for navigating the early “transient state” will be explored.

How long did it take before your last project was able to put a first version into production? How long was the release cycle after that? The basic premise of this tutorial is that any project that is unable to release to production every three months has a problem. The product owner should actively work towards reducing the length of releases. The idea of releasing often is not new. Most agile approaches recommend frequent releases. This tutorial is based on our study of concrete strategies projects use to actually reduce the length of releases and find a Minimal Releaseable Product.

A lot of people still believe that agile software development is for small and collocated teams only. However, the agile value system and the principles as stated in the manifesto don’t argue about project size and distribution. In this course attendees will learn about key success factors for distributed (and maybe even large-scale) agile software development. The focus will be on how to apply agile processes in a distributed setting and how to establish and preserve a common development culture.

As an agile coach I am often faced with a “business value” dilemma when asked to help a new team adopt agile. They want the benefits of agile but have little understanding of what is required to be successful.

Before I commit to getting involved I run a facilitated workshop based on a set of experiential questions and multi choice answers to stimulate discussion amongst the group and highlight the agile roadblocks they face on their specific project.

Articulating their roadblocks helps decide whether the agile journey is worth starting and how an agile coach might add “business value”.

It’s hard to imagine how the Empire State Building could be built in a year. But it was. How did they do it? The builders framed the problem differently than we would today. Their mental model – which dictated what was important and what was not – would not be recognized in today’s commercial world, except perhaps by those who understand lean thinking. Lean thinkers look at the world through a different set of glasses. Join Mary and Tom Poppendieck for a Lean in a Nutshell – a fast-paced tutorial aimed at senior developers, team leads, and development managers.

Flow-based software development (FSD, aka “lean”, pull-based, or kanban) put focus on improving flow of work items (normally software features) through a software development work process. But what does it mean in practice? We show the nitty-gritty of how to set up a project to run flow-based instead of timebox-based, and when it makes sense to do so. We show a simple KPI model to better capture the state of a project using FSD, and how it can be used as a basis for conducting experiments aimed at process improvements.

Exploratory Testing is a vital item of any release. Exploratory Testing can be taught and trained in a collaborative manner using Testing Dojos.

While Coding Dojos are in use among programmers for a while now, equally trainings for testers are exceptional. Testing Dojos provide a way to teach other team members about the dynamics of Exploratory Testing by practicing it and sharing the knowledge among the audience.

The session gives a brief introduction followed by a hands-on Testing Dojo experience for the audience.