Estimating Business Value
Track: "Throw Me Something Mister!"
This workshop provides participants with hands-on experience with techniques to create meaningful business value estimates for their user stories. By using these techniques, a product owner will create numeric estimates for the business value of their user stories, while increasing engagement with the their stakeholders.
Exploit Core Scrum Practices at the Program Level
Jeff Lopez-Stuit, Chris Waggoner, Wylie Burt
Track: Hop On a Streetcar
Core Scrum practices establish visibility, remove impediments, and promote collaboration at the team level. Standup meetings, physical task boards, and a Scrum Master’s mission clear impediments are well known practices to keep a team focused on the work, and establish a sense of flow towards frequent, tangible, and sustainable results.
What about an entire program, when a large number of teams are involved? How can a large organization exploit the same core practices when there is highly interdependent work, and when there may be hundreds of people involved? How can Scrum be used to improve delivery times, increase quality, and promote sustainable development at a program level? How the can practices provide executive leadership the visibility they need into program progress?
This workshop will introduce valuable, proven Scrum practices for large programs. Among the topics that will be discussed are:
* What program management challenges are ripe for improvement through Scrum practices?
* The Program Impediment Board: Visible impediments, dependencies and milestones at a program level
* The Program Stand-up: Lightweight activities to promote visibility, clear impediments and collaboration across the program
* Program Flow (kanban): Establish the value chain, WIP limits, and flow across an entire program, and apply it to multiple feature and defect work streams.
* What does it look like when it’s working?: Improve delivery time, increase quality, and establish collaboration across the organization.
The workshop will include both lecture and exercise sections:
* Introduction (10 minutes) – What are the program management challenges ripe for improvement through Scrum practices?
* History (10 minutes) – what have been the traditional approaches to scaling scrum practices to a large number of teams? (e.g. Scrum of Scrums, Release burn-up/burn-downs, program dashboards, etc. ) How have they been successful or insufficient in supporting program delivery objectives?
* Core Scrum practices for large agile programs (25 minutes): Significant Scrum practices that can be exploited at the program level, with real world examples from a number of client organizations:
* The Program Impediment Board
* The Program Standup
* Program Flow (kanban)
* Program Retrospectives
*Program Scrum Exercise (30 minutes): A simulation involving up to 20 workshop attendees, who will utilize Program Scrum practices in an exercise to clear impediments and promote collaboration right at the Gathering in New Orleans! (Note: if this is a large enough session, we'll split into two groups and run two simulations, and compare results as an entire group afterwards)
*Summary and Q & A (15 minutes): What will it look like when Scrum program practices are working well? How can you start using these practices in your own organization?
Exploring Scrum of Scrums as a Scaling Vehicle
Track: Hop On a Streetcar
Today there are several frameworks emerging to support agile at scale including SAFe and DAD. And many ALM tool vendors have implemented 3-tiered systems that support work from the Portfolio to Team levels. All of that being said, these are complex approaches and we seem to have forgotten a relatively simple approach to scaling: which is the Scrum of Scrums (Sos).
In this session we’ll explore the dynamics of Scrum of Scrums. It’s not been incredibly well defined, which has made adoption a challenge. So we’ll share Scrum of Scrums models and approaches that we’ve seen work at a variety of clients. We’ll also “mine” stories of Scrum of Scrum models from attendees to create a shared understanding of the strengths, applicability, and implementation details for this simple alternative for scaling.
Fun Games for Serious Scrum Masters
Games per see are fun but not necessary oriented, actually as children play there is no utter goal than just hang around with friends and have fun.
From a leaning perspective games are great because they create the right environment for people to interact without being afraid of making mistakes or looking bad in front of his/her pairs.
From a creative perspective games has no parallel in terms of providing a safe environment where even the craziest idea can be presented and heard with respect and consideration.
Research on serious games has provided the scientific background to prove that human interactions, whereas fun and informal, can lead to very productive and creative results as long as they remain focused and contained within boundaries.
Scrum as a highly human-based-team-oriented framework provides the right environment for people to interact and communicate effectively. While all this communication is clearly defined in activities there are few guidelines about how to get the best of each. Even more importantly, there is little indication about what to do when the team has been performing together for months now and the routine is little by little replacing creativity.
Ally disciplines like Game Storming come to help providing a comprehensive list of what games are out there being successfully used by consultants, training organizations, and meeting facilitators.
This sessions aims to demonstrate, and actually make participants play some games that the presenter has been using with his teams. Knowing how to play these games and when to encourage people to play is an important tool that Scrum Masters will definitely like to add to their repertoire.
This would be the outline for this session:
-Serious games vs just playing (10 min)
-Categorizing games (10 min)
-Playing games for starting a creative process (20 min)
-Playing games for exploring out-of-the-box solutions (20 min)
-Playing games for reaching agreement (20 min)
-Discussion about the practicality of using games (10 min)
Incremental Delivery and Emergent Design in action. An exercise in delivering working software from sprint one through sprint X.
Room: Belle Chasse
Track: "Throw Me Something Mister!"
This is a workshop that requires audience participation. No two times I have done this runs the same way but the message is always consistent.
The main principles are; what incremental delivery is, why it is vital to any agile process and give the attendees a practical example of what it looks like. With this under their belt you will know how to deliver working software from the first sprint and incrementally thereafter.
There are supporting tools/concepts or “bonus topics” that emerge during the discovery of how to deliver incrementally.
• how to build quality in and what happens if you don’t
• why you need to build slack into your sprints
• what refactoring is and when and how it happens
• how to build a sustainable process that will not create technical debt
• how velocity applies to the process and common pitfalls to avoid
• how and when to split large epics
• how and when to build underlying architecture while delivering functionality
• how to wow and include the customer
• how to maintain a backlog using a story map
• how to use the delivery team to help you discover creative solutions to the customer’s requirements
• looking for early release opportunities
• just in time vs. big design up front
• how refactoring and agile testing are all handled “under the cover” and how to manage these
• how to managing risk in scrum
• how, when and why to run research and spikes stories
• “The Simplest Thing That Can Possibly Work”
Session Outline - Three parts
1) Intro, create backlog and start first sprint (30 mins)
In this exercise I play the stakeholder/customer and the room play the PO and delivery team. We start out by getting a vision and a roadmap. Then we begin building a backlog (in the form of a story map). But rather than completing the backlog, once we have enough to start work, we run the first sprint and produce a working demo for the customer (played by me). The challenge is trying to decide what to put in that first sprint to produce something of value to wow the customer. How do we deliver demonstrable working software in only two weeks when we know that we can’t complete the underlying infrastructure in that time? The product is a web application and no code is actually written – rather we are describing what the product will look like by the sprint review demonstration and actually hold a sprint review.
2) Two or three more sprints and demonstrations with discussion and Q&A interspersed as I reinforce how to spread architecture work while delivering front end work to demo. I introduce more of the “bonus” topics and how they fit into the development cycle whilst we continue to build the product incrementally (50 mins)
3) Closing and Final Questions and Answers (10 mins)
Metric-Driven Enterprise Coaching
Track: Hop On a Streetcar
Key performance indicators (KPIs) or metrics are used by some large enterprises to alert executives to opportunities and dangers. Executives seek “leading indicators” to help them make decisions early enough to improve success. But when KPIs don’t correlate well with desired outcomes, or when they inspire gaming or outright lying, they are worse than useless, they can drive the company to failure.
Unfortunately, in enterprises adopting agile practices, managers sometimes use behavioral compliance metrics (“how long is your Sprint?” “Are your Daily Scrums held daily?”, etc.) as KPIs to help teams self-assess or to gauge how practices are performed. These often cause dysfunctions, especially when coupled with incentives to meet uniformly applied metric-based targets.
When Skype adopted a metric-driven approach to company management, the agile coach team decided to experiment with it to manage its own activities. We sought organizational outcome metrics that articulate the “Why?” of agile practice. Among our valued outcomes were improved Product Owner communication, shorter time from concept-to-cash, better employee alignment with a shared mission, more accurate forecasting, fewer escaped bugs, more thoughtful process experimentation and reduced “specialist risk”. We identified well-correlated metrics for many of these.
We wanted to give teams freedom to explore their own behavioral approaches. Rather than imposing a uniform set of metrics on all teams, agile coaches collaborated with their teams to choose mutually agreed metric targets. Every team-coach engagement had a metric and target, but each engagement was different. When the metric was achieved, the engagement was over. A new metric target could be chosen, or the coach could move to a different team and with that team create another metric-driven engagement.
With this approach, coaches could directly point to the measured impact they had on the company. We have found that this is rare in other companies. Most coaches are suspicious of metrics, and even more suspicious of metrics applied to themselves, but metrics done well improve transparency, an important value of agile. Here, each coach gains an engagement resume that shows results and can be used for retrospection.
We found we could deploy coaching more thoughtfully, using metrics to find teams and groups “most in need”. We had a handful of agile coaches to serve over a hundred teams. By constructing a formulaic approach to ranking teams, we could find the teams where our help would provide the greatest impact and seek engagements with those teams.
Executives were happy with the outcome, and started asking the agile coach team to target specific areas of the company for improvement. They started understanding agile’s organizational goals better, and started advocating for those ideals.
In some ways, this is a systematization of the A3 Process over many teams.
* Agile organizational goals
* Bad metrics (behavioral)
* “Maturity model” style Scrum and agile metrics
* How these interfere with organizational goals
* Good metrics (leading indicators, correlated with business goals)
* Forecast Horizon
* Key Person Vulnerability
* High-antecedent dependency count
* Dependency Graph Lead Time
* Escaped Bug Count, etc.
* Exercise: Creating metric targets for engagements
* At your table, identify a team problem and find a metric showing the problem (from this list or create your own). What is the current state? What should be changed? If you change it, what is the hypothesized state? What impedes you from getting agreement to try it?
* Exercise: Metric driven coaching
* At your table, pick an organization. How might you combine these metrics to provide a ranking system for teams?
* How we did metric-driven coaching and what are the results so far?
The Listening ScrumMaster
Track: Rolling Down the River
Listening is one of the best ways to support and direct a good ScrumMaster. Good listening can make the difference between good or bad coaching and support of a team.
By showing respect for team members, product owners and others in conversations, spending less time speaking, and challenging assumptions
often made in conversations, ScrumMasters can improve their own listening skills and those of the Scrum team.
In the session we will identify traps a listener may fall into and also investigate six of the more common archetypes of bad listeners:
• the opinionator,
• the grouch,
• the preambler,
• the perseverator,
• the answer man,
• the pretender.
The session will follow the principles of the 4 Cs. Connection, Context, Concrete Practice and Conclusion.
1. Connection (10 minutes)
Participants will be grouped in pairs, triads or groups (depending on the number of participants in the session. My aim is to have groups of max 5 persons).
Participants will be asked to create and write two lists. One list of good listening skills and one list of bad listening skills.
Together all participants will do a quick debrief of the lists created.
2. Context (10 minutes)
A presentation of what to have in mind when listening (to keep quite, to ask clarifying questions, the risk of assumptions, the ladder of inference) and the common archetypes of bad listeners (the opinionator, the grouch, the preambler, the perseverator, the answer man, the pretender).
3. Concrete Practice (60 minutes)
Exercises where participants will get the opportunity to practice listening skills and dig deeper into the lists created during the connection at the start of the session.
Exercises will include some, but not necessary all of the following.
3a. Avoiding traps (20 minutes)
Participants will be asked to form pairs. Each pair will be asked to pick three example of bad listening skills (traps) and discuss how to avoid each of these
Debriefing by asking each pair to present their findings to another pair.
Each group of four will be asked to present one bad listening skill and how to avoid it.
3b. Practicing bad listening (10 minutes)
After forming new pairs I will ask one in each pair to talk and one to listen. The talker should talk for one minute about something s/he is passionate about. The listener should try to appear not interested in the subject and practice ways of making that obvious.
After one minute the listener and talker are asked to switch.
Debreif by asking what happened during the exercise and how it felt to be a listener and a talker respectfully. Finally all participants are asked about good ways to become active listeners.
3c. Handling the archetypes (15 minutes)
In groups of five, the participants will be asked to pick one of the archetypes and come up with good advice on:
a) how to avoid becoming such a type
b) how to deal with others who fall into that type
Debrief by asking each group what they came up with and having a short discussion about the findings.
3d. Listening to what is being said as well as to what is not being said (10 minutes)
New pairs, one is listener and one is talker. Talkers describe what they want from a holiday without mentioning a destination. Listeners practice active listening skills – listening attentively to what is being said and what is not quite being said, and demonstrating their listening to the talker by their behaviour. After 3-4 mins the listener has to summarise the 3 or 4 main issues or criteria that they have heard the talker express and then make a tentative sale of a suitable destination. Then 1 min to review how close the listener was to what the talker said and needed. Plus 1 min to review how well they demonstrated active listening behaviours. Then swap roles and repeat.
Debrief by asking all participants about learning points.
3e. Action plan (5 minutes)
In pairs, participants will be asked to put togehter an action plan for themselves to become a better listener and then asked to present the action plan to the other person.
Debrief by sampling items from action plans.
4. Conclusion (10 minutes)
All participants form a circle.
Each participant is asked to present what they will try out when they get back home in order to become a better listener.
A volunteer participant will start. S/he will receive a ball and be asked to state one thing to do to become a better listener and is then asked to throw the ball to someone else who is asked the same things. If a participant does not have anything more to say they just pass the ball. This goes on until no one has any more to say.
Using Kano AND Scrum to Learn more about Scrum!
Room: Oak Alley
Kano Analysis is a powerful and enlightening tool for Product Owners to identify which features enhance and which subtract from that most crucial of factors - Customer Satisfaction. It is my favourite prioritisation method by far.
But have you ever thought of applying Kano TO Scrum? Which parts of Scrum are exciting? Which are mandatory? What about Kanban? What about XP? In this workshop we will go all "meta" and apply the Kano technique to the famous Agile methods, and see what results come out!
Then see the results of an industry wide survey of Agilistas of all shape and sizes and how they responded to these questions. Discover NEW and EXCITING information about Scrum!