Agile development means self-management, collaboration, and working towards shared goals. Agile practices support much of this, but we can still learn more, both to better understand current practices and to develop new ones. This session is an introduction to cultural-historical activity theory, a psychological framework for understand collaborative behaviour. The framework has shown the role of tools in cognition and collaboration, and understanding structural tension between different activity systems: it can also be used to understand and improve agile software development.

Aren’t code, backlog-items, tests, designs & documents all just different forms of system knowledge at different levels of detail? Why can’t the same tools help refactor, browse, search, and provide build/test automation for non-code forms of knowledge without requiring a separate tool/repository for each format?

Tim and Tim discuss tools and techniques and observations for remotely pair-programming. Various remote desktop-sharing applications and services are discussed, dissed, and recommended along with pointers and practices for logistics. Learn the downside of distant partners. How do you have a flash architecture meeting? How do you collaborate with the team? When do you take breaks? Is it really just like being there, without the smells?

One of the core values of the Agile Manifesto is favoring “Customer collaboration over contract negotiation”. Unfortuntely, product companies with thousands (to millions!) of customers can find collaborating with their customers nearly impossible, as few tools exist to explicitly support meaningful customer collaboration. This workshop explores the advantages of including your customers as part of your distributed team and some of the tools that are emerging to enable agilists to better collaborate with their customers. Bring your laptop, as we may be trying out some of these tools.

Using Google Docs you can create your own lightweight project management tools and through simple and powerful visual management provide the people involved with shared information that will give transparency into progress and problems

Compared to most commercial project management tools using Google Docs is very flexible. That way the tools can be adapted to how the processes of the project continuously improve. And not the other way around.

The demonstration is based on more than 2 years of experience using Google Docs for Agile processes in a distributed development context.

In 2005, Microsoft’s DevDiv (with 2000 participants and 40 million lines of code) overhauled its engineering practices to improve agility, quality, and customer satisfaction. Four years into the journey, customer satisfaction has increased dramatically. Product quality improved 10x. Velocity improved 2x, with schedule time for major releases was cut by eighteen months and quarterly releases of “power tools” allowed incremental delivery to external customers. Practices that change include planning, org, quality gates, branching, testing, tooling, reporting, backlogs, transparency.

As the world becomes increasingly “flat”, organizations are seeking out operational and cost efficiencies by leveraging distributed teams. These distributed teams are a common constraint on most technology projects today. To continue wide-spread adoption, Agile projects must find ways to thrive in distributed environments. The Ambassador Model is a proven, effective approach to building highly productive distributed and off-shore agile teams. Complementing this model are “carrier pigeons,” a metaphor for tools (technology and practice) used to overcome the challenges of distance.

The “pomodoro technique” is a simple tracking and feedback process where the unit of work is the “pomodoro”, a time slot of 25 mins. In this tutorial I’ll give you advanced practical advices on how to implement the daily pomodoro practice, common pitfalls, tools you may find useful and how to read and use pomodoro metrics and answer questions like: what did I do the last week, on which tasks I spent most of the time, how frequent is the context switching. Hopefully after this talk you’ll be able to go back to your team and give pomodoros a try with all the practical information needed.