Self-organization of human beings is a tricky thing. Agile coaches are constantly challenged with how to motivate/persuade/trick their teams into doing things, without telling them what to do, but there is very little information or training on this topic. Allowing a team to self-organize along the lines of “oh well, they’re all adults, they’ll figure it out” is just as irresponsible as reverting to the command-and control school of management. This tutorial presents an approach utilizing leading-edge research and techniques from social complexity science and team dynamics.

Human relationships are at the center of the Agile manifesto. Anything we do as coaches to allow humanity expression in our teams directly affects the individuals’ ability to live the manifesto more fully. This immediately translates into better, more astonishing, creation-ability in teams, and a greater sense of accomplishment and fulfillment for the team members. In this session, experienced coaches/trainers Lyssa Adkins and Tobias Mayer will introduce ‘Powerful Questions’ and share their personal experiences of coaching teams and individuals towards a more human-centric way of working.

I think Pair Programming is vital to the success of a programming team, but every time I join a new team I seem to find I’m in a minority of people who feel that way, let alone have any experience of actually doing it.

Join Esther and Diana, the authors of Agile Retrospectives: Making Good Teams Great!, on an interactive journey of Adventure. Follow the trail of a flexible framework for Retrospectives, a map for designing and leading Retrospectives. Retrospectives offer the greatest lever for project or process improvement—based on the solid data of a team’s immediate past experience of success and failure. The Adventure lies in holding Retrospectives throughout the project—capturing, managing, and disseminating technical knowledge and process wisdom to improve current and future projects.

Agile fails without executive leadership. Although pockets of Agile can flourish for a while, only executives have the power to make an entire organization change.

The agile community has tried to sell executives on Agile rather than involve them. This workshop involves participants in discovering and documenting patterns for Agile executives to use. It builds on our previously-presented CTO research.

This session is appropriate for executives with Agile experience and for gurus who commonly work with executives. Others should wait for the results.

The Agile Alliance states that “The Gordon Pask Award recognizes two people whose recent contributions to Agile Practice make them, in the opinion of the Award Committee, people others in the field should emulate.” This panel brings together some of the previous winners so that they may share their contributions and help encourage others to participate in building the body of Agile knowledge. For the intermediate practitioner, it should reinforce the notion that as we practice Agile and learn how to adapt for the best outcome, sharing what we learn helps the whole community.

This report describes how scrum was adopted by more than half of the software developers at Amazon.com (and counting). The adoption was due largely to the efforts, both accidental and purposeful, of an internal employee. Amazon’s corporate and development cultures played important roles, both positive and negative. With no executive sponsorship, adoption occurred primarily a team at a time. The wide range of success across teams and organizations leads to a number of important lessons learned with regard to enterprise scrum adoption. The lesson: you can cause this to happen.

One of the most common questions asked of practicing Agile teams is:

How can we increase velocity?

Many teams have had to answer this question, but is it the right question? Velocity is an excellent measurement for determining project timelines and progress towards them but doesn’t give us any indication about the overall value of the features being delivered. All too often poor prioritization and solutioning are ignored because velocity is the KPI for the team. This session shows how to use value as a tool to ensure that you get more of the right things done.