Monday, October 24th, 2011 – Tutorials

Registersoon before the conference is sold out.

Test Automation Strategy for the less Technical

09:00 – 12:00 Room 1 Gerard Meszaros

Test automation is a key enabling practice for rapid delivery of high quality software. But not all test automation is created equal. What makes a test automation tool appropriate for use on agile projects? How do the different styles of tools compare and when should each be used? How does your team structure influence the choice of test automation strategy and tools (and vice versa?) Avoid test automation disappointment by getting the answers to all these questions and others in terminology most non-technical project participants can understand.

Extreme Lego Scrum Game: go beyond where you've ever been before with lego bricks

09:00 – 12:00 Room 2 Dave Sharrock

Scrum is the foremost agile framework used worldwide. The core principles of Scrum are simple to understand, and we might think easy to apply in practice. But there are some subtle counter-intuitive aspects to Scrum that make it difficult to put into practice well. It is too common to find yourself in a monochromatic implementation of Scrum, rather than the techni-colour version we read about in the oft-quoted success stories.

The Extreme Lego Scrum Game is a full day of hands-on Scrum practitioning. Not slides. Not words and artifacts. But an experience in which attendees uncover the principles of Scrum from real need, learning why the artifacts are there and how they naturally fit together to improve flow, and come away with a knowledge based on experience and application, while having a lot of fun and building a Lego masterpiece along the way.

From Big Boss to Supportive Leader: a Guide for Managers of Self-Organizing Agile Teams

09:00 – 12:00 Room 3 Esther Derby

Self-organizing teams don’t need managers? Wrong! Self-organizing teams need managers of a special type. So, what does a manager of self-organized team do? How does she support and protect her team? How does she nurture and help the team excel? How does she provide the team with the best chance to succeed? During this workshop we will discuss all this and explore tools to help you make the transition from a Big Boss to a Supportive Leader.

You will learn:

• The critical conditions for teams to self-organize.
• How to establish decision boundaries with a self-organized team.
• How to guide without dictating.
• Dynamics that prevent teams from self-organizing.

Agile Test Automation

13:00 – 16:00 Room 1 Janet Gregory

Agile teams must deliver production-ready software at the end of every one to four week iteration—or even possibly every day. This goal can't be achieved without automated tests, and many teams struggle with test automation. The challenge of automating all regression tests frightens many testers, who feel their skills aren’t up to the job. How do we deliver good quality when we have to release so often?

By combining a collaborative team approach with appropriate tools and design approaches, over time you can automate regression tests and use automation to enhance exploratory testing. In this interactive tutorial, Janet Gregory describes what tests should be automated, some common barriers to test automation, and ways to overcome those barriers. You’ll learn how to design automated tests for maximum effectiveness and ease of maintenance. You’ll find out different approaches for evaluating and implementing automated test tools, shortening feedback cycles, creating realistic test data, and evaluating your automation efforts. You’ll understand how to fit automation activities within each iteration so testing “keeps up” with coding. Group exercises and discussions will help you understand new skills and practices, as well as learn from other participants’ experiences.

Influence and Authority: Using Your Personal Power to Get Things Done

13:00 – 16:00 Room 2 Johanna Rothman

Have you ever felt as if you had the responsibility but not the authority? Or, that you needed something from someone, but you had to beg, borrow, or steal it? Maybe you’ve felt the joy of accomplishing something that you were responsible for, but had to work through someone else to accomplish.

Almost no one has enough authority to finish the work we have responsibility for. And, we almost always have the ability to influence others, to use our personal power in the organization to become effective or make a difference.

Some of us are are facile with our personal power. Others of us have concerns: am I manipulating people? am I manipulating the situation? am I being fair to others? Others of us are unsure where to start with using our influence.

In this session, you will feel your personal power and experiment with how to use your influence.

Seeing and Steering Systems: Three Pragmatic Tools for Managers

13:00 – 16:00 Room 3 Esther Derby

Effective managers focus on leading and improving the organization rather than on the day to day work. But how do you move beyond assigning and monitoring work and start influencing patterns of behaviour; how do you understand causes and effects and generate options for action? What tools do you need to succeed in this strategic activity? Although these tools help leaders at all levels, you can rarely find them in management training programs. You will find them right here in Vancouver.

You will learn:

• Eoyang CDE, a method to understand the underlying structures that drive behaviour in an organization
• Expand the Problem Horizon, a technique to understand the organization-wide implications of seemingly local or individual problems
• Finding Factors, a method to identify factors that contribute to intractable organizational patterns--and where you can intervene to change those patterns.

Thursday, October 27th, 2011 – Tutorials

Assessing and Managing Technical Debt in Large and Long-Lived Software Development Projects

09:00 – 12:00 Room 1 Philippe Kruchten

The nice metaphor of technical debt introduced some 18 years ago by Ward Cunningham has slowly taken roots in our collective conceptual toolbox, as a nice way to express some of the pains that software projects suffer from. Most software developers who have had some experience with significant, long-lived projects can feel it, sometimes point to it, but more than often can’t do much about it. In most cases, technical debt is seen as something very negative, burdening projects forever under increasing amount of interests. But there is a flip side--and at the same time a limit to the financial analogy--as some technical debt can be deliberate, more akin to borrowing to make an strategic investment, and this is especially the case for architectural-level debt. When does this architectural debt actually make sense? Should it always be repaid? How can we constructively reason about technical debt, before and after incurring it? The question often boils down to another question we are familiar with: what is the value of software architecture, this invisible ingredient of many challenging systems?

Today the phrase “technical debt” remains more a useful rhetorical construct to speak about the intrinsic quality of a software system than a crisp, well-delimited scientific notion. A small research project, initiated in 2010 under the auspices of the Software Engineering Institute has undertaken some investigation and consolidated information from various sources, through a couple of workshops.

In this tutorial we will look at different facets of technical debt and the various means that have been proposed to assess, mitigate, evaluate or reduce technical debt, and we will look also at it as some form of a tactical investment, when technical debt is not just a “bad thing” as long as incurred in full knowledge on the consequences.

Value Stream Mapping

09:00 – 12:00 Room 2 Mary Poppendieck

Value Stream Mapping is a Lean tool that has a long history of uncovering waste in manufacturing and operational settings; it is also a great tool for software development. In this session, participants will learn simple rules for creating value stream maps, and teams will create maps of real situations. The resulting value stream maps will be presented and critiqued, so participants can envision for themselves how they might use this practical tool.

Participants will discover, through hands-on experience and discussion, how to create and use value stream maps in a software development environment. As the maps are constructed and analyzed, participants will discover how value stream maps create a new perspective on the software development process, one that they can use to evaluate their workflow and pinpoint the biggest opportunities for improvement.

Patterns for Improved Customer Interaction

09:00 – 12:00 Room 3 Linda Rising

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

Need to speed up? Then slow down! : A practical introduction to Kanban

13:00 – 16:00 Room 1 Mike Edwards“Slowing down to speed up” is totally counter intuitive to what we learn in school, the business world, and life in general. Many managers believe the best way to get more work from their people is to speed up, or push more work into the system. Unfortunately this is the worst thing you can do, as much like cars merging at a bottleneck of the highway during rush hour the high volume actually causes significant back-ups. During this workshop we will start with a simulation game where a development team will be creating a product according to customer specs! Through a refinement of the exercise we will demonstrate the impact of too much work in the system, identifying the bottlenecks, and strategies for improving the flow of work. In the second part of this workshop we will examine the mechanics of Kanban. Using live examples from participants, we will go through the steps required to develop a Kanban board. With this developed we will discuss the mechanics and challenges of running a Kanban board. This includes prioritizing the backlog, daily meetings, dealing with adversity, optimizing the flow, and many other aspects.

Relentless Improvement: Creating a Culture of Problem Solving

13:00 – 16:00 Room 2 Mary PoppendieckDeveloping software is done through a system of increasingly complex interactions. Just as complex software will eventually become brittle, so too will complex work systems eventually become fragile and break. So how do you keep work systems as flexible as the software you are developing? You develop workers who accept the challenge to continuously improve their work system so that it delivers increasingly better customer outcomes. Nothing is going to get you very far if you do not grow the people who understand customers, decide what tests to run, write the code, keep up the cadence, deploy the software, provide support, and constantly improve the system so it delivers more value to customers. What does this mean in practice? That is what Mary and Tom Poppendieck will lead small groups as they work through a real problem during this workshop, which will cover class process improvement tools and the lean thinking that is critical for making these tools successful.

Problem Solving and Decision Making in Software Development

13:00 – 16:00 Room 3 Linda RisingSoftware developers struggle with complex problems for a living. Unfortunately, we don't have time to keep up with the enormous amount of research in cognitive science that would help us be better thinkers. Linda Rising will share what she has been able to uncover. Some of it is surprising, even counterintuitive. Linda will report on the research and provide practical tips for better thinking.

-- Platinum Level Sponsors --
-- Gold Level Sponsors --
-- Bronze Level Sponsors --
-- Media Sponsors --

Wednesday, October 26th, 2011 – Sessions

Registersoon before the conference is sold out.

Keynote: The Power of an Agile Mindset

09:00 – 10:30 Linda RisingLinda has 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 Linda likes 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. Linda will relate what's known about this mindset and share some practical suggestions that can help all of us become even more agile.

Applying Agile to Legacy System Transformations

11:00 – 12:30 Process Track – Room 1 Michelle D'Souza, Amit UttamEvery technology organization eventually comes face-to-face with the decision to replace or make significant business changes to their current legacy system or codebase. Using well-known, core Agile principles, we have found that this transition to software that adapts to rapid business change does not have to be painful, nor expensive, nor technically dissatisfying. We will also describe how newer technologies can still be introduced into a ‘legacy’ enterprise, while still keeping key business data and core business processes unaffected, yet open to future change.

Cultivating a Devops Culture

11:00 – 12:30 Technology Track – Room 2 Owen RogersDevops represents a different approach to IT operations -- an approach based on the principles of collaboration, visibility and automation. For developers it means a better understanding and greater visibility into the environment that the production system is running; for operations it means closer collaboration with development and a greater focus on frequent deployment, monitoring tools and automated system provisioning. The result is more supportable, scalable systems with a streamlined deployment process and a lower cost to operate. This presentation covers the principles, practices and tools that we have found help nurture and sustain a devops culture.

The Geek Factor: Why They Aren’t Buying Your Agile And How To Make Them Love It

11:00 – 11:45 Team Track – Room 3 Robert ReppelIf Agile works, why isn’t everyone doing it? Or, as Agile has become fashionable of late, why all the lip service without the expected amount of real change? This presentation makes the argument that it comes down to trust and presents tools and examples of how to build trust among the various stakeholders involved.

Feature, Component or Mixed Teams – What works in scaled Agile?

11:45 – 12:30 Team Track – Room 3 Chad HoldorfOne of the first steps in an Agile adoption is the formation and organization of agile teams. Leadership often struggles to figure out how many people should be on each team, what skill sets should included, and whether the team should be focused on solution components, feature delivery, or a mix. In this tutorial, you’ll hear how the 98th largest company in the Fortune 500 is optimizing their software development process by forming feature and component teams that deliver value continuously, while minimizing interdependencies.

Agile Adoption – Failing Slow and Other Redemptive Stories

13:30 – 15:00 Process Track – Room 1 Steve RogalskyThis presentation aims to address the elephant of agile adoption – specifically in context of the following two that were identified by the group at the 10 year reunion: a) Commercial interests censoring failures and b) Elitism as a defence against failure. One of the hallmarks of the agile community in Winnipeg over the past years has been to hold agile Q&A fishbowls at conferences and user group meetings – an open community discussion on any agile topic. The most consistent topic over the last few years has been the question of agile adoption – just how do we implement these practices so that we can help our companies improve? As a result of this, we have shared our stories of failure and success. In this session you will hear four agile adoption stories from the ‘peg, including the long slow failure of the local ‘elite’ and the success of the agile newcomers. We’ll examine and compare the contexts for these stories and discuss how honesty and openness has helped shaped agile in Winnipeg. To end the session, we’ll have an open discussion to compare your agile adoption stories and questions with those of the Winnipeg community.

The Inflection Point - How Long You Can Safely Avoid Automated Testing, and Why You Might

13:30 – 15:00 Technology Track – Room 2 Scott BellwareWe've lived with a Test-Driven Development orthodoxy for ten years. It suggests that all code should be written test-first. In practice, it literally means that all code should be written with a coded, automated test first. While TDD adherents would say that this approach should always be used, doing so turns a blind eye to circumstances where automated testing can be deferred without loosing any productivity, and in some cases, increasing productivity. This presentation examines the inflection point where automated testing becomes necessary and beneficial, and challenges many TDD assertions that we've maintained over the years. It also provides the context for why these assertions and have been so important and asks whether current conditions still justify TDD orthodoxy. In this talk, a long-time TDD practitioner and teacher talks about lessons-learned on recent agile projects and how Lean Development principles can change perspectives on TDD practice when they are considered solely on the basis of "productivity".

The Straight Jacket of Agile Iteration

13:30 – 15:00 Team Track – Room 3 Michael VaxThe Agile movement started out of frustration from long running, slow, and inefficient projects. As Agile defined itself as an opposite of Waterfall, it is not surprising that most of early Agile efforts were focused on switching our thinking from big to small - from months to weeks, from upfront design to evolving architecture, from meters long MS Project schedules to SCRUM boards, and from long requirement documents to cards and stories. And it worked! Switching from the Waterfall to the Agile process felt like getting a grasp of fresh air after leaving a stuffed room where you were locked for a long time. Because Agile proponents saw their main objective to prove that small works, little effort has been spent on discovering limitations of the "think small" approach. This presentation will explore limitations and pitfalls of a purely iteration focused approach and discuss different ways to address them while still retaining the speed and flexibility of the Agile approach. We will discuss:

• What needs to be done before the iteration to ensure its success
• How to balance resources between delivering the current iteration and nurturing the future stories in the backlog
• How to see and understand the big picture while delivering in small batches
• How to organize activities that happen after the iterations, for example, performance and regression testing
• How to incorporate customer deadlines, release planning, and external dependencies into the iteration flow
• How to find a balance between minimum necessary design and making all design decisions upfront. It is not always feasible to refactor yourself from an early mess.
• How to fit a big feature into multiple iterations
• Overhead of iteration in continuous delivery

There is nothing wrong with the long term planning. The waterfall process gets in trouble by trying to define every little detail in it.

Agile Isn't Enough

15:30 – 17:00 Process Track – Room 1 Jeremy LightsmithAgile isn't the destination, it isn't even everything you need to get there, at best it's a set of ideas that will help you find what you need along the way. At this session, we'll explore other sources for some of the things you'll need. We'll look at a sampling of techniques, tools, and ideas from outside of agile that are extremely useful to agile teams:

• What's the next action? - from Getting Things Done (GTD)
• A/B Testing - from Lean Startup
• Paper Prototyping - from Interaction Design (IxD)
• Current Reality Tree - from Theory of Constraints

Pitfalls and Perils of Agile Testing

With an introduction on Agile Testing Quadrants

15:30 – 17:00 Technology Track – Room 2 Janet GregoryMany teams have tried to implement agile software development practices and failed. When you read about transitioning to agile development, it sounds so easy. Why don’t all of them succeed and why do so many agile adoptions go so badly? In particular, testing seems to get off track. Iterations turn into mini-waterfalls, stories are never quite “done”, and testers worry that they’re losing control or being set up to fail. Customers keep changing their minds and complaining that their requirements weren’t met. Obviously, some teams succeed with testing on agile projects, and others don’t. What do they do differently? Janet Gregory will share some of the lessons she has learned when working with teams that help agile teams be successful. She will introduce the agile testing quadrants which is a model for testing that involves the whole team. She will talk about what to avoid, what practices are critical, and some basic steps that can make the difference between success and failure. One example of a critical practice is using the whole team approach, and what happens when your team keeps your test team separate from the project team.

I Need To Vent… Just a Little Bit!

15:30 – 17:00 Team Track – Room 3 Fish Bowl Panel DiscussionFacilitated by Eugene Nizker Join us for one of our infamous fish bowl discussions, where you get to be part of the panel. We will start with some of the speakers and Junta members, and then anyone who wants to join in the discussion gets to trade places with one of the people on the panel. It’s a fun and lively way to debage issues, so drop by and join in.

-- Platinum Level Sponsors --
-- Gold Level Sponsors --
-- Bronze Level Sponsors --
-- Media Sponsors --

Tuesday, October 25th, 2011 – Sessions

Registersoon before the conference is sold out.

Keynote: Where Is Agile Going?

9:00 – 10:30
Johanna Rothman

It's an interesting question. Are we in the post-agile era? Is agile giving way to kanban? Will agile evolve to something else? The question assumes that agile has crossed the chasm. But that's the wrong question. It doesn't matter where agile is going. What matter is this: It matters where you are going. It matters where your organization is going. It matters how well you deliver your product to your customers. And it really matters how your organization treats you, the people of your organization. That's what this keynote is going to be about. Forget the canned assessments that allow you get a number, as if you are at a deli counter. You will learn how to assess your progress according to your external customers and your internal customers. I have one question: Are you ready?

Discovering Startling Things from Your Version Control System

11:00 – 12:30
Process Track – Room 1
Michael Feathers

The industry is awash in an epidemic of bad code. We all know what bad code looks like – it's opaque and impenetrable. But, we spend little time trying to figure out how it got that way. We assume it's tight schedules or lack of discipline, but perhaps there's more. In this talk, Michael Feathers will relate several things that he's learned by taking a longitudinal view of a system – by issuing queries of a code base and relating the results back to events on a team. The more we know about how we behave as teams in our code, the more likely we are to be able to control our development well enough to hold bad code at bay.

Keeping Software Soft

11:00 – 12:30
Technology Track – Room 2
Gerard Meszaros

The term "software" is somewhat ironic. If is is so "soft", why is it so hard to change once built? And the longer a software system exists and the more frequently we change it the harder it becomes to change. Scrum /Agile involves changing the software very frequently. How can we avoid our very agility making our software "brittle"? The solution lies in picking software development practices that reduce the cost and risk of making changes to the software. These practices include automated unit testing, automated functional testing and refactoring. At first, these practices may appear to increase the cost but they quickly pay for themselves by flattening the "cost of change curve".

If You Were in a Room with an Elephant Would You See It?

11:00 – 12:30
Team Track – Room 3
Mike Edwards

In this highly interactive session we will use games to examine people in different ways, illustrating the impact of influences such as multitasking, fatigue and others. I've become fascinated by what actually happens inside us as humans. We will go further and focus on a number physiological impacts, and how it can result in the brightest people becoming blind (Inattentional and change blindness)! I will actually prove to you how this can happen to you too no matter how good you think you are! It's an amazing field when you look at it further! Finally we will bring this knowledge together and share potential strategies you can employ to ensure a better outcome for your organization.

For teams looking for that all too elusive zero-defect goal, or higher customer value they need to take steps to start seeing their own elephants which are actually standing right in front of them! Failure to do so will limit their ability to succeed.

Agile Failure: Don't Look for Silver Bullets!

13:30 – 15:00
Process Track – Room 1
Esther Derby

In 10 years since the signing of the Agile Manifesto we've seen some notable successes, half-way efforts, fragile, scrum-but and just plain #FAIL. We tried to adopt agile methods to solve all types of problems, and many of those problems persist. What are the most common failure modes? How can organizations avoid falling into those failing patterns?

This is a variation/update on the keynote that Esther gave at XP2011.

Service Oriented Architecture – A Recipe for the Agile Enterprise

13:30 – 15:00
Technology Track – Room 2
Hans Schoebach

SOA is all about loosely coupling of application functions that can act as autonomous units without dependency to other functional components. This is achieved by defining a concise business interface layer that is independent of the applications interfaces and it's implementations which, in turn, enables test driven developments as interfaces can be tested before the actual implementation is finished. The interaction of the atomic business interface units is controlled by an orchestration service that controls the sequence and interaction of services that don't know of each others existence.

Because of this functional decoupling of granular business functions the business solutions can be build incrementally by independent development teams. Each service is autonomous and functionally distinct without dependencies on other functions, which is effectively a loosely functional coupling.

The agility is a function of this decoupling. New services can be added to the business solution without disturbing and changing the existing ones. In addition, as contemporary SOA is based on web services it does not have to consider the differences in implementation platforms and technologies, and it is inherently scalable.

Combined with a Cloud Computing infrastructure a SOA gains additional agility, scalability and elasticity, while reducing the overall TCO.

Leading Agile Change: Walking the Walk

13:30 – 15:00
Team Track – Room 3
Dave Sharrock

An often overlooked aspect of large agile transformations is how we lead that transformation. The elephant in the room, if you like, is that many coaches and transition consultants focus on helping teams become more agile, while not walking the walk themselves. It is extremely difficult to rely on many frameworks like Scrum or Kanban for managing the work of the transition team or leadership team in a large organization. We talk the talk with our teams, but don't walk the walk.

A starting point in many transformations is the transition team, a proven approach to leading agile change. Like the management team of an organization, and unlike members of a Scrum team, transition team members are often unable to commit to daily stand-ups or sprint commitments. This makes traditional agile frameworks hard to follow. However, there are ways to apply agile principles to make the organizational (or transition) goals transparent, and manage the work required to achieve these goals effectively. We can model better ways of working to the management team while managing a large scale transition.

Dave considers situational circumstances that prevent management teams transition teams adopting common agile approaches, and describe a framework for high intensity situations, developed over the past year, that helps transition teams balance uncertain commitment with value-based decision-making.

You will learn why and how a transition team leads agile change, how to create a self-directing action plan based on the goals of an agile transition, and how a transition team can use this plan to work confidently towards that goal.

Risky Business: An Outside-In Look at Agility and Risk Management

15:30 – 17:00
Process Track – Room 1
Todd Little

This presentation looks at the business of software development from an overall risk management perspective.

Two industries that extensively deal with risk are Investment Banking and Oil Exploration. As a seasoned veteran involved in developing software in these industries, Todd will introduce a number of theories, tools and practices surrounding risk and risk management. He will share practical experience using these techniques and approaches, explaining what works and what does not based on his experience and that of his colleagues.

Cloud Computing Rockets Your Organization Towards True Agility

15:30 – 17:00
Technology Track – Room 2
Kris Read

Cloud Computing is more than just another tool in your toolbox. You'll hear how the cloud is changing entire organizations, shifting perceptions and thought processes toward a more responsive, agile mindset. Infrastructure is transforming from a capital investment into a utility (like water or power); this freedom is changing the way teams develop software.

As you adopt cloud computing, you'll begin to see cultural benefits as you change the structure and processes of your teams. No longer will your product team be throwing releases over the wall, or complaining that the server guys just can't keep up with their agile pace. Cloud computing lets you align goals and build mixed teams, where sysadmins work hand in hand with developers to build a cloud-based solution. And at the same time, you're empowering people in a way you never could before, giving developers the power and responsibility to deliver excellence not just in their IDE, but in production too.

Appraisals and Compensation: The Elephant in the Room

15:30 – 17:00
Team Track – Room 3
Mary Poppendieck

Appraisals, bonuses, and compensation in general have a dramatic impact on individual and team performance, and yet these subjects tend to be avoided as if they were taboo. This talk will take a look the underlying conflict between individual rewards, teamwork, and evaluation systems. It will examine the history and literature of reward systems, particularly those in environments which require collaboration. Two case studies will be discussed, including one concerning team bonuses.

-- Platinum Level Sponsors --
-- Gold Level Sponsors --
-- Bronze Level Sponsors --
-- Media Sponsors --