Every Agile Learning Labs course, whether public or private,
is composed of training modules--think of them as "user stories"
if you like--items of work that can be listed on a backlog.
Our modular approach means that training can be delivered at any
scope or pace that suits you, the customer.
Many of our modules make excellent brown bag sessions,
and some are perfect for presentations at
conferences and special interest group meetings.
Abnormal Sprint Termination is a core module in Scrum certification workshops, and covers the ins and outs of how to handle those rare occasions when a Sprint must be cancelled. Reasons for an abnormal Sprint termination may include, but are not limited to:
- The company changes direction
- Market forces render the work obsolete
- A major technology change occurs
Misunderstanding and miscommunication are at the root of many, possibly most, of the problems that plague projects. Learn proven techniques to improve communication and understanding.
A person who listens well…
- will be told more
- will be confided in
- will understand people better
- will resolve conflicts easier
- will be listened to
When people are talking to you, are you really listening, or are you starting to think about what you are going to say next? Even if you hear their words, are you sure that you understand their meaning? Language lends itself to misunderstanding as easily as understanding. This makes for great comedy, unless the joke is at the expense of you and your team.
In this workshop we take a good look at listening. Effective techniques will be presented and modeled. Then the real fun begins, as each participant will get to practice active listening skills by role-playing scenarios taken from the real world.
This is an overview of Agile values, principles, practices and methods. It is the view from 50,000 feet up.
- What Agile is, and how it differs from traditional approaches
- The relationship between Agile and Scrum
- How agile teams deal with changing requirements
- How not doing big design up-front can lead to better system architecture
- How agile can deliver more value and reduce risk
Traditional estimation always seems to lead to cost and time overruns on complex projects. Agile practices, such as scrum, have greatly improved how the work gets done. But the contracts we use and how we initially scope the work haven’t kept pace.
Participants will learn how to bootstrap the agile estimation process so that initial plans and contracts can be created. We’ll explore a variety of contracts that better support agile work. Fear not! This won’t be hours of lecture and slides. The entire workshop will run using scrum. Participants will work together on projects, learning by doing.
This workshop module is better known to our students as “The Great Requirements Showdown!”
Agile evangelists claim that extensive written requirements can be dispensed with in favor of lighter-weight ’stories’. It sounds easier, certainly, but can it really be as good? Won’t all of the important details get lost? We stage a showdown between traditional and Agile requirements. Participants will form teams, create requirements documents, do development (no technical skill or computers needed), and then evaluate the results. May the best requirements win!
This presentation explains the benefits of adopting agile development methods, in terms that a businessperson will understand and value: the bottom line and cash flow. This overview is perfect for business leaders who want to know what agile is about. It is also ideal for those who need to convey the benefits of Agile methods to the business leaders of their organizations.
Does your team have an estimate for the business value of each story? Business value estimates enable a more rational ordering of the product backlog, which results in the team delivering more value. Participants will gain an understanding of the essence of business value; it’s more complex than just revenue. They will also learn a surprisingly simple technique to estimate business value. This is a hands-on learn-by-doing session.
Want to build your coaching skills? Need answers to a tough problem that you or your team is facing? The coaching dojo is for you! We will form small groups where one ‘seeker’ will get five minutes of coaching from multiple coaches. Then the tables turn and the coaches get feedback.
Read the full description.
Coaching is the process of providing feedback, insight, encouragement and guidance in order to enhance performance. Leaders who use coaching techniques:
- Engender greater involvement
- Create an environment conducive to high achievement and growth
- Need to give explicit direction less often
- Better tap the talents of their team
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 in a mode where they are more open and receptive to the information. This workshop combines interactive exercises and group discussion to lead participants to understand coaching questions, what they are, as well as how and when to use them.
Become a product discovery detective and uncover the truth about what your customers really need. Building a product based on our assumptions about customer needs is expensive and risky. A better way is to connect with stakeholders and test assumptions before building the product. In this hands-on session, you will learn techniques for testing assumptions quickly. These product discovery tools will accelerate your progress towards a product that is more useful, usable, and valuable.
“Hey, Fred, did ya get around to implementing the advanced search functionality?”
“I sure did, Ginger, it’s done.”
But do we really know what Fred means by “done”? And more importantly, does Ginger?
They may be operating under entirely different assumptions. Does Fred’s Definition of Done (DoD) mean he’s finished coding and the feature has gone to test, but may bounce back to him? Does it mean he’s demoed the new feature for the product owner, and met all acceptance tests for the new feature? Or something in-between?
It is vital that the team agree up front on a common definition of what it means for a feature to be “done.” Agile and Scrum set great store by the concept of the team producing shippable product in every sprint. In practice, most Agile teams define a feature as Done when it is “potentially shippable.” Since it isn’t always practical to actually ship features as they are completed, it makes sense to establish a set of doneness criteria that demonstrate a feature’s readiness to ship all other things being equal.
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:
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.
“How long will that take?”
It seems like such a simple question, yet it is one of the hardest for software developers to accurately answer. Inconveniently, it is also one of the most important. This session combines an interactive exercise, the Team Estimation Game, with a bit of agile theory to teach participants how to quickly create estimates for their user stories.
The Team Estimation Game
The Team Estimation Game, created by Steve Bockman, helps teams that are new to estimating quickly grasp the concept of relative sizing. Here’s how Alan Shalloway et al described the game when they included it in their book, Lean Agile Software Development:Achieving Enterprise Agility:
“It works because people find it easier to compare the complexity of one feature or story with another even if they do not yet know all aspects of that story. This game is fast, easy, and fun. It helps people avoid getting bogged down in too many details, which is always a risk during estimation exercises.”
Agile is a holistic approach to software development that grew out of the experience and insight of people working in the field. It follows then, that the best way to learn about agile is to experience it. Over the course of this short workshop, which is popular as a stand-alone presentation to user groups and at conferences, we will engage the power of simulations and learning games to evoke and explore various aspects of the Agile experience. Warning! This will be a participatory learning experience, without a PowerPoint safety net!
Areas we will explore will include:
- The power of iterative development and delivery
- Team self-organization
- Directive vs. Participatory project management approaches
- Agile techniques for continuous improvement
- Communication on an agile team
Part of being a scrum master is being a masterful facilitator. A facilitator helps others deal with a process, reach an agreement, or find a solution without getting directly involved in the content of the process or discussion. Facilitation means to make an action or process easier.
You will walk away from this session having learned and practiced a number of facilitation techniques. These techniques will help your team have effective and valuable meetings, quickly make important decisions, and have more fun.
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.
All too often organizations focus on how many stories are getting done, or worse yet, on velocity. Completing a lot of stories shouldn’t be a scrum team’s goal; instead the goal should be to create value. The former is output, the later is outcome. In this workshop we’ll explore metrics for both, and identify ways to increase focus on value creation.
It is difficult to grok pair programming until you’ve actually experienced it. This is a live theatrical “performance” demo of this key extreme programming practice in action. Watch two developers actually build components of an application, illustrating the benefits and challenges of this high-productivity method of coding along the way. Seeing is believing.
Prototypes are a fast, low-cost way to design products that are more useful, usable, and valuable. The faster and cheaper, the better. While fancy high tech tools look impressive, they add cost and complexity; not everyone can use them. But everyone who has graduated from kindergarten knows what to do with a stack of paper, pencils and a glue stick. By making your prototype accessible, disposable, and non-precious, you encourage participation and faster iteration. The result is faster learning and better products. In this session, you will use paper prototyping to iteratively design, test, and evolve a product that will delight your users.
This experiential workshop will equip your team with tools to tackle the formidable but rewarding activity of product backlog refinement. You’ll gain real practice in class through hands-on exercises, first with ‘training stories’ and then with the real stories from your product backlog. You team will leave the workshop with a deeper understanding of the concepts and a much improved product backlog.
A scrum team’s backlog contains all of the user stories for the current product or project. The stories that will be implemented soon must be small and well defined. Those that are further out on the schedule can be bigger and fuzzier. So how do we evolve those big fuzzy stories into the well-defined ones we will need when it comes time to implement them? Product backlog refinement! This experiential session will give you techniques to evolve and refine the stories in your product backlog.
From Order Taker to Product Visionary!
Product owners do not simply take orders from customers and deliver them to developers. Great product owners synthesize customer needs with the company’s goals and the team’s capabilities. The result is a compelling product vision and a strategy to fulfill that vision. In this session you will practice the skills needed to make the leap from order-taker to product visionary!
In this module, we create a lightweight document that can define, align, and get a project started.
A micro-charter, sometimes called a one-pager, is a brief document that identifies key aspects of a project. A project is born as an idea; the micro-charter is a way to capture that idea efficiently. Once captured, the idea becomes easier to share, discuss, and refine. The likelihood that a business document will be read goes down as the length of the document goes up. For this reason, the micro-charter is kept brief.
You will receive requirements from your customer, create your project plan, and go! You’ll execute the project and deliver an amazing product on time and within budget! Just like in real life! Or maybe, just like in real life, you won’t succeed. We’ll harvest the learning, relate it to your real world experiences, and then try again. Perhaps this time we’ll focus more on the product, and less on the project. Or perhaps we’ll try another variation. With each iteration taking five minutes, we can afford to experiment.
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.
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!
Through experience, reflection, and adaptation, participants will learn new, and better, ways to address the myriad of challenges that a product owner faces guiding a product through its development. This simulation also helps executives and other stakeholders understand what product owners do, and how to better work with them to achieve strategic goals.
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.
Retrospectives are the Agile team’s most powerful tool for facilitating continuous improvement. We’ve all encountered teams that make the same mistakes and suffer the same pain over and over again. The good news is that it’s possible for just about any team to break this cycle by investing as little as an hour a week in learning to use retrospectives to systematically and incrementally improve performance.
In this workshop module, you will learn the basics of how to facilitate a retrospective; how to attend one; and how to use retrospectives to put your team on a path of continuous improvement. When this module is included in a full day or longer workshop, we cover the material by holding a retrospective for the class itself.
A chalk talk about the state-of-the-art with regards to applying Scrum in large organizations. In our Certified ScrumMaster and Certified Scrum Product Owner trainings, this module is delivered by Jeff McKenna, one of Scrum’s co-founders and a member of the very first Scrum team.
The Scrum Roles Game Show
Whose job is it anyway? It’s a question asked in organizations using scrum. Some things only the product owner should do. Other areas are in the scrum master’s wheelhouse. The development team owns much more responsibility than in a traditional project. There are things everyone should be accountable for, and things nobody should ever do.
In this game show inspired activity, you will learn the roles and responsibilities of each person on a scrum team. You will also learn what scrum doesn’t cover, and how things go wrong when a role isn’t properly fulfilled. It will be fun, fast-paced, and you might win a fabulous prize!
This is an experiential simulation of a full agile project from team-formation through final delivery.
The best way to understand agile development is to actually do it. This is a fast-paced, half-day session in which participants get to play product owner, scrum master and developer as their team plans, builds and releases product. The development environment includes: balloons, construction paper, playing cards and dice; no coding skills are required.It’s a lot of fun to play, but the learning that occurs is quite serious, and takes place on both the conceptual and kinetic levels.
Scrum sim is based on the XP Game, which was first developed as an open-source learning tool by Vera Peeters and Pascal Van Cauwenberghe and is used to teach agile concepts to teams all around the world.
Self-organizing teams are 10,000% more effective, make people happy, and will save the world! At least that’s what some Agile and Lean advocates seem to suggest. Have you ever had the experience of being on such a team? In this experiential workshop you will.
Teams will form, solve problems, optimize systems, and learn-by-doing:
- Form a team.
- Create your own process.
The lessons in this fast-paced, unscripted learning lab will come out of your experience, not off of a PowerPoint slide. Worry not! We promise there will be no “trust falls”, ropes course, or singing.
A product backlog indicates what to build, but not why we should build those things, or how they are interrelated. Story mapping builds a deeper understanding of our stakeholders’ needs and how we can best meet those needs. It is also a great tool for uncovering dependencies and bad assumptions. In this hands-on session you will practice creating a story map and exploring its uses.
Product owners often struggle to translate their big ideas into small user stories that the team can deliver in a sprint. When a user story is too big, it is harder to understand, estimate, and implement successfully. Some teams break the ‘business story’ into ‘technical stories’ but this doesn’t solve the problem because most or all of the technical stories need to be completed before there is anything meaningful for the stakeholders. This experiential session will give you hands-on experience with 4 simple, yet powerful techniques to break big stories into smaller stories that are meaningful to stakeholders and deliver business value. Participants write and split stories in small groups throughout this session. In his years of agile coaching, Chris has never found a story that could not be split using at least one of these techniques.
SWOT analysis is a tool commonly taught in business school to examine internal strengths and weaknesses as well as external opportunities and threats. It was originally conceived to help corporations formulate high-level business strategy, but it has proven useful in a broad range of situations. SWOT is an excellent tool for evaluating business opportunities such as starting a new business, entering a new market, pursuing a new development project, or allocating resources in areas such as recruiting or training.
This workshop will teach you how to do a basic SWOT analysis, using your career or your company’s business as a practical application. You will learn a valuable analytic tool and gain insight into your own career or company.
… Without Groupthink!
A group may have vast experience, a variety of viewpoints, and impressive intellectual horsepower. It may also have politics, personality clashes, and other more subtle dynamics that get in the way of optimal group problem solving, idea generation, and decision-making. This workshop teaches a technique for harnessing the wisdom of the group, while avoiding many of the pitfalls that plague standard brainstorming-based approaches.
The Group Wisdom Without Groupthink process begins with the Nominal Group Technique (NGT), which allows a group to quickly build a comprehensive list of ideas, issues, options or solutions. NGT works faster than traditional brainstorming, yet generates more complete and higher quality results.
The list of possibilities generated by NGT is then narrowed down to identify the best or most important ideas using DOTS, a form of dot voting. DOTS engages the collective wisdom of the group, while avoiding groupthink and politics. When faced with a choice between a variety of options, this technique facilitates a group decision that will have the broadest support.
This workshop will teach you how to use the Group Wisdom Without Groupthink process by applying it to an issue such as “What makes agile projects succeed (or fail)?”, or some other question of interest to your group.
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.
Have your teams ever wasted time and effort building the wrong thing? The culprit is often incorrect assumptions about what users really need or what the market really values. In this hands-on session you will practice lean product development techniques to test assumptions before investing in building the wrong thing. This allows you to focus the valuable development effort on building products that will delight users and deliver greater value.
Understanding and communicating stakeholder needs is hard! In a traditional approach, we create and share extensive documentation in the hopes that this will lead to the right product being built by the development team. Historically, the results have been less than satisfying. In this simulation, we explore the challenges of effectively sharing a product vision, and we discover better ways to guide the development team toward building the right product.
“Theory of Constraints: Flying Through Bottlenecks” is a simulation that explores applying the Theory of Constraints and other Lean concepts to process optimization.
In this experiential workshop we launch a fictitious aerospace company, build and ship product, and track our financials to see how we are doing. We’ll apply the “Five Focusing Steps” from the Theory of Constraints, and other Lean/Agile practices to improve our operation and ultimately our profitability.
Learning Outcomes include:
- Profitability can be a better metric for productivity than resource utilization.
- Boosting performance of a bottleneck may not be the best first step.
- Optimizing all individual operations is not the same as optimizing the whole.
- Slowing down some operations can result in improved and predictable delivery times.
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.
Successful products address needs that exist for a market segment. For many, a market segment is a fairly abstract concept. User personas put a human face on a market segment. They help us understand and empathize with the people for whom we build our products. They build alignment and shared understanding between business people and technical people. In this session, you will create user personas to create and refine a shared understanding of the people who are your product’s market segments.
Agile teams like to build based on a set of requests, some say requirements, called user stories. This approach focuses on users and value. In this session you will practice refining a product concept into a set of stories that will drive shared understanding of: the value to be created, the people we’ll create the value for, and what we will build to create that value. Along the way, we’ll see how to handle annoying details like dependencies, deadlines, and important technical aspects.
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