This experiential simulation takes participants through an entire release from the point of view of the product owner. You’ll have a team. You’ll have a product. You’ll have stakeholders who demand more and more! The team wants to focus on technical debt. The executives want to focus on the latest initiative. Then the market shifts! Stakeholders want to know when they are going to get their stuff. But the team’s output isn’t reliable. There are risks and dependencies to manage. Lions! And tigers! And bears! Oh my!
Read the full description.
Retrospective Games
Retrospectives are an agile team’s most powerful tool for facilitating continuous improvement, unless they get stale and boring. “Let’s make a list of what went well and what didn’t go well…” Shoot me now! Don’t have the same old retrospective over and over again. Learn how to use games to keep your retrospectives fresh and engaging. Yes, there will be game play during this session. No, there won’t be any PowerPoint.
Coaching Dojo
Photo by Gabin Vallet
Tasking
Users stories describe units of valuable software that a team can deliver in a sprint. In order to implement a user story, the team needs to break it into tasks. Tasks are units of work that individuals and/or pairs complete. The act of breaking a user story into tasks is actually a team-based design activity, which leads to a shared understanding of how the story will be implemented and how it will fit into the rest of the system.
In this hands-on session we will break a user story into implementable tasks. Along the way, we will explore a variety of techniques for better team tasking.
Us vs. Them
The problem isn’t us, it’s them!
How often have you heard this? How often have you said it? How often has ‘them’ been some other group within your own organization? Call it silos, rivalry, or politics; the dynamic of ‘Us vs Them’ is wasteful and potentially destructive. In this experiential session we will explore how these dynamics arise, and how we can move towards more productive ways of interacting.
XP Technical Practices
This is a high-level overview of some of the technical practices that came out of Extreme Programming. We will look at the following practices from the point of view of increased productivity, cost-savings and increased accuracy (yes, that’s fewer bugs):
- Pair Programming
- Test Driven (Test First) Development
- Behavior Driven Development
- Research Spikes
- Coding Standards
- Continuous Integration
Coaching With Questions
The right question, asked at the right time, is one of the most powerful tools in a coach’s toolbox. It can help the person being coached discover new information, options, and insights. This workshop combines interactive exercises and group discussion to lead participants to understand the power of coaching questions as well as how and when to use them.
Multitasking
Job advertisements often state “must be good at multitasking!” This session begins with a brief simulation exploring two approaches to delivering multiple products: parallel work vs. serial work. The exercise is short, but the learning is profound. People respond strongly to the experience and its unexpected outcomes. Participants come away with new approaches to improving productivity when multiple products or projects must get done.
Release Planning and Buffering
Release Planning is the process of choosing which features, or stories, will be included in a given release. Usually, either the feature set or the release date is fixed, and the other is variable. Either way, this is a business decision. On a large software project, it would be imprudent not to build in a time “buffer” for contingencies (Swine Flu, anyone?). You do this at the release planning level. You can buffer for time or features, or both.
Tools that are useful in release planning include user personas, Kano analysis, paper prototyping and story mapping.
Empirical Processes
People looking at Agile from the outside sometimes jump to the mistaken conclusion that it is a chaotic, seat-of-the-pants approach to development. Far from it; Agile methods of software development employ what is called an empirical process model, in contrast to the defined process model that underlies the waterfall method.
The traditional waterfall approach treats software development as a defined process. It assumes that everything can be known upfront, and that the team simply needs to execute to plan. Scrum references an iterative, four-step approach to process improvement sometimes referred to as the Deming Cycle, after William Edwards Deming, the statistician and business visionary widely credited with seeding the exponential improvements in Japanese manufacturing after WWII.
The four steps of the Deming Cycle are:
- Plan
- Do
- Check
- Adapt
Each sprint cycle includes all four steps, and the iterative repetition of these steps, commonly referred to by the mantra of “Inspect and adapt,” is what leads to continuous improvement.