Monday, October 24th, 2011 – Tutorials
Registersoon before the conference is sold out.
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.
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.
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.
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.
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.
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
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.
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.
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
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.
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.
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.