To enable the Agile Value “Courage”, we have to empower internal coaches, project managers, team leaders, and team members to change the organizations culture. Only a coach (or a manager / executive in his/her role as coach) is in the position to initiate and keep this process alive. Thus a coach has to be able to:

• make human systems transparent
• reduce or adjust complexity
• enforce dialogues and solutions
• set and enact clear goals
• build trust in the team and in the customer collaboration
• focus on sustainable decisions
• clarify conflicts

A participatory workshop where coaches can share their experiences in coaching agile teams in hostile environments, what they did to avoid the pain, and how they turned toxic organizational inertia and attack against itself or circumvented the same to realize more agility. The session will be facilitated and will be oriented around capturing tricks, tips, and techniques, but will also allow for some sobbing and frustration and ranting. Epic fails are definitely welcome. The most sought after stories and ideas will be those which use the opposition’s own strength to advance the effort.

Three basic tools - pen, paper and a kitchen timer - will give you Agile values like…

• Constant feedback about your working habits
• Dedicated decision points to respond to change
• Opportunities on a day to day basis to improve your personal process
• A sustainable pace even when the deadlines are getting closer
• Improved quantitative and qualitative estimates
• Strategy for coping with interruptions and task switching
• Ability to regulate complexity

Many facets of Agile apply to simple principles of human nature. Because Agile is so effective in the workplace, I began applying Agile principles (after pleading with my wife) to managing the chaos of our family. For over 2 years now, my wife, 4 children, and I have been using Agile practices to manage our own home life.

The evolved methodology in our home has been discovered over two years of modification using Lean principles while working on weekly iterations.

This is a fun topic with actual learning points for managers learning to accommodate unique personalities in the workplace.

Most agile methodologies tend to assume that the team is co-located in a single team room. They give little guidance as to how to address team distribution although proven practices are starting to emerge within the community. The Microsoft patterns & practices team has been experimenting with distributed teams for several years, mining proven practices from the community and experimenting them out on numerous agile projects. This talk summarizes those learnings and proven practices and gives examples of their application - both good and bad - within our teams.

When it is achieved together, the combined benefits of both Agile and Offshore software development, can be multiples greater than either approach alone. During this interactive session, we will simulate a distributed project with some participants being onsite and the others offshore. With 4 teams of upto 8 people each, this game will draw out learning around the challenges of Distributed Agile and different methods to communicate successfully on such projects. The rules of the game help illustrate how to deal with travel, different timezones, delayed communication and other such hurdles.

I propose that the larger issue with Agile Contracts is not that we don’t know how to write them. After all we know how to deliver Agile projects, so a contract can simply describe that process. The problem is with making Agile Contract commercially competitive; against suppliers who are offering the promise of delivering the perfectly predicted dream - offering the certainty that people crave. This is a prisoners dilemma, with organisations driving themselves towards a sub optimal solution. Through game theory we will explore ways in which to improve the appeal of the agile offering.

Engaged as a software consultant at a financial services company, we brought up the topic of Agile early on and were told, “No!” A Vice President at the company said that Agile had been tried there and failed, so the management decided that Agile was a waste of time and money and would be prohibited. Despite this edict, our team cleverly succeeded at covertly injecting “The approach that shall not be named” into a couple key projects. Our success caused management to reverse its firm anti-Agile stance, and the whole organization is now moving in that direction.

This talk will look at the product owner role on an Agile team from a Pragmatic product management perspective. Many software development companies rely on their product management organizations to represent the needs of customers and the market. Concentration on problems, the people who have them, and the circumstances under which they experience those problems is what makes the marriage of Pragmatic product management and Agile so valuable. This presentation will describe how the Pragmatic approach to the MRD gives the Agile product owner a headstart and the entire Agile team an edge.