Can A Definition of Ready Make Scrum "The Big Easy"
Natalie Warnert, Leslie Morse
All Scrum practitioners know about the “Definition of Done.” But as active ScrumMasters & Scrum Coaches we’ve experienced teams struggling to get “done” during a timebox. We facilitate retrospectives to uncover the underlying issues: over-commitment, technical impediments, and unrealistic definitions of done. We always find ourselves leading the teams to an important question: Were you really “ready” to commit to the items you discussed during Sprint Planning?
Just as teams have a shared understanding of what “done” means, we have seen our teams improve by discussing and collaborating on a “Definition of Ready.” “Definition of Ready” details a set of characteristics and qualities an item in the backlog must have before a team should commence work. Of course, many high-performing Scrum teams won’t need this. They are already collaborating and grooming their backlog well. This technique is especially useful for 4 types of teams.
Teams struggling to find an even-paced velocity
Teams with lots of external and/or intra-backlog dependencies
Teams where team members have variable levels of dedication/allocation
During this interactive workshop participants will get hands-on experience crafting a sample “Definition of Ready.” Activities will draw on the perspectives of different team member personas (e.g. ScrumMaster, Business Analyst, Testers, and Developers, Product Owners) and what it means to be “ready” from each perspective.
In addition to providing an opportunity for cross-functional collaboration, attendees of this session, will be led through discussion that explores the following topics:
Avoiding a Failure to Launch - Why the presence of a “Definition of Ready” increases the quality of each sprint’s commitment
Ready versus Done - How “Definition of Ready” and “Definition of Done” are different
Fears of Over-Readfication - Things that make a “Definition of Ready” a burden, and not a technique for success
Adhering to a consistent standard of “ready” helps teams improve performance and ultimately avoid a situation where Scrum practices feel like “the Big Bumpy.” So we hope to leave you thinking a Definition of Ready can indeed help Scrum become “the Big Easy.”
Collaborating with Comedy
Track: Jazzin' It Up
This fun session was inspired by techniques learned from the British Improv Troupe called “The Comedy Store Players” who perform weekly shows in London with no script and only audience suggestion to help them. I have tailored some of their games and exercises as tools for Scrum teams to learn and understand the benefits of basic collaboration, on which all improv games thrive. All of the games I describe below have been proved (I use them as a coach) to lighten the mood in a given scenario by using a little humor and fun, and the aim of the session is to show how these games, and a little humour can increase collaboration within teams.
My session separates itself from other “improv” themed sessions as all of the games played can be used as practices for the audience to apply in Scrum meetings, I don’t just the provide improv principles alone.
The session firstly gives a little bit of context around the history of improv from the works of Viola Spolin and Keith Johnstone particularly since the mid 20th Century. I then spend the remainder of the session running short improv games, firstly with one/many volunteers at the front of the group to demonstrate the games to the rest of the group, then I allow the audience to have a go themselves in the relative safety of small groups. We debrief each game in small groups, before a larger debrief as an entire group.
Session Outline (all timings given below include debrief)
History and context of Improv (5 mins)
Game 1 – Gift Box (5 mins) – a simple warm-up game to ease people into improv.
Game 2 - Blind Offers (10 mins) – a mime game that demonstrates the principle of an “offer” which is the basic building block of collaboration.
Game 3 – Delight (10 mins) – a story telling game that demonstrates the principles of a “block” which opposes an offer and kills collaboration in team. Context is given here in the debrief around how this can be seen in Sprint Reviews or with some Product Owners.
Game 4 –One Word Storytelling (15 mins) – a basic story-telling game where a group have to form an interesting story but only speaking in turn, one word at a time. Context is given here in the debrief around variations of this we can use in a Daily Scrum or Sprint Retrospective.
Game 5 –The Interpreter (15 mins) – a mime game using “gibberish” where the actor (me in this case) describes a story/lecture using mime and “gibberish” which one of the audience has to translate so the audience can understand. Context is given here in the debrief around variations of this we can use to give Daily Scrum updates in pairs, or describing the sprint timeline in a retrospective.
Game 6 – Questions Only (15 mins) – a conversation game where two teams compete by staging a conversation where only questions are allowed to be spoken. Context is given here in the debrief on coaching ScrumMasters to ask questions back to teams rather than always (and sometimes more naturally) giving solutions.
Game 7 – The Three Headed Expert (15 mins) – a one word panel where three audience members have to collaborate to answer questions to an interviewer on a subject defined by the audience. Context is given here in the debrief around the emergent nature of conversations and the art of powerful listening.
Culture a ‘Silent language’ – Learn it to make Scrum successful
Judith Mills, Priyanka Sharma, Debra Feltoe
Track: Rolling Down the River
Scrum is elegantly simple, yet deceptively complex. Introducing Scrum without a proper understanding of intercultural differences lead to numerous areas of difficulty, frustration and reduced productivity.
In this session we will discuss that the success of distributed software development team is influenced by cultural intelligence, a recent concept that relates to a person’s capacity to recognize, understand, and utilize culture.
The importance of differences in national and organizational cultures in offshore IT development initiatives is often underestimated. Many companies have ventured into other countries without recognizing the criticality of these differences for creating unified and effective cross-cultural teams of its IT professionals.
Dive into India/US and China/US business models in detail with real life scenarios wherein Scrum adoption was a challenge, and how we made it successful. This survival guide will provide you insights of different culture that are often not discussed when signing the business agreements. What is effective in one culture may be ineffective, or even inappropriate, in other cultures.
Let’s face it: Multicultural diversity at home is now the rule, rather than the exception.
1) 10 mins. Introduce CQ (Cultural Intelligence)
2) 10 mins. Cultural Values, Ethnocentrism & Empathy.
3) 5 mins. Small group discussion on cultural values.
4) 5 mins. Communication & Scrum Ceremonies across Cultures
5) 10 mins. Departmental Cultures
6) 5 mins. Small group discussions of experiences and challenges.
7) 15 mins. Co-location, Communication & Time Zones
8) 10 mins. Building Trust & Rapport
9) 10 mins. Planning
10) 5 mins Small Group discussion - What would you do differently?
11) 5 mins. Technical Considerations, plus References
Facilitation Techniques for Effective ScrumMasters
Marcos Oliveira, Rafael Sabbagh
Room: Oak Alley
Track: Rolling Down the River
One of the most important characteristics of the ScrumMaster is to be strong in soft skills. However, these are skills frequently neglected. Besides facilitating the daily work of the Scrum Team, the ScrumMaster also has the important role of acting as a facilitator in the Scrum events. The ScrumMaster encourages those involved to actively participate in the discussions. The ScrumMaster helps them keep focus on the event goals and reach their own conclusions.
Through this very interactive workshop, we will teach facilitation techniques necessary for effective ScrumMasters, but unknown by many. Attendants will learn the role of a ScrumMaster as a facilitator and its responsibilities. They will practice and learn how to help teams be more effective in carrying out their work through the use of techniques such as facilitating meetings (e.g.: setting the envirnoment, starting the meeting, using a paring lot, using timeboxes, using team agreements), dealing with communication problems, asking questions (e.g. questions with context vs. questions without context, reactive questions etc.), dealing with disfunctional behavior (such as lack of intetest, aggressiveness, paralell talking, lack of focus etc.), consensus building, using drawings as a communication tool and others. Attendants are set into real life simulations, usually receiving a role to play where a point is proven or a technique is demonstrated.
Although knowing facilitation techniques is a primary role of the ScrumMaster, all members of the development team can benefit from facilitation techniques and practices.
The references used for building this workshop (among others) are mainly the works of Roger Schwarz and Michael Wilkinson, well-know researchers on the facilitation field, besides our own practice and knowledge on the subject.
We run some exercises in this session, and we are detailing two of them below:
1st - Dysfunctional Behavior: we ask one of the group members to facilitate the session (it's a retrospective based on a previously defined scenario). Then we give each participant a role. Some of them are asked to behave in a dysfunctional way, such as lack of participation and side talks. It's the introduction to the Dysfunctional Behavior segment of our session where we work on the use of facilitation techniques to address the most commom problems we usually face in meetings.
2nd - Consensus Building: We let them choose a new facilitator and we introduce a new scenario: a decision must be taken and they have few options. Once again we give each participant a role. Some of them must support option A, some of them must support option B. The facilitator will have hard time to achieve consensus. It's the introducion to the Consensus Building segment.
Game theory and techniques applied to an Agile Product Vision creation
Challes Pinon, Luciana Silva
Room: Belle Chasse
Track: Jazzin' It Up
This workshop is featured for who aims to create new products from zero and has the challenge to discover how to move from a foggy scenario into a clear and effective product vision. That work does not only involve Product Owners, but customers, business staff, development team and Scrum Masters too. Commonly, at this initial stage of a project, people can only count with vague requirements or disconnected ideas as existing assets.
Based on the authors work experience with Scrum teams and insights contained on the book “Game Storming – a Playbook for Innovators, Rulerbreakers and Changemakers” by Dave Gray, Sunni Brown and James Macanufo, this workshop brings some of the knowledge inside the universe of games and agility to help creating a vision through collaboration.
The main goal is to give the attendee tools and a guide of relevant techniques to facilitate sessions that will conceive an effective product vision. The person will have the opportunity to experience theoretical explanation and hands-on exercises.
Part 1 (30 minutes) – theoretical concepts
1. What is a game and how it is linked with agile principles;
2. Essential knowledge of game design;
3. Get essential knowledge of LeanUX for vision validation.
Part 2 (60 minutes) – hands-on exercises
1. Go along three different game stages (opening, exploring and closing) experiencing one game technique at each step.
Hop Onto the Release Orientation Trolley
Brian Barr, Naeem Hussain
Track: Hop On a Streetcar
This session will cover the WHAT, WHY, and HOW of release orientation:
1) What does it mean to be a release-oriented organization? (WHAT)
2) Why should you move to release orientation? (WHY)
3) How do you make the shift to become a release-oriented organization? (HOW)
WHAT (25 minutes): Project oriented organizations focus entirely on getting a related set of intent packaged into a container called a project and seeing that entire container move through from requirements generation to software release. Release-orientated organizations are singularly focused on continuously getting releases out the door that maximize business value delivery without being constrained to only releasing related business intent in the portfolio. To achieve the continuous release of software systems, organizations must apply lean thinking and principles to every aspect of their delivery frameworks and minimize the overhead associated with making releases with high quality. In this portion of the session, we will cover:
- Agile organizational design and resource allocation to ensure maximum flow of shippable product to the release
- Agile portfolio management, funding, and approval approach geared towards agile organizational design, smaller, incremental business intent approval and prioritization. Moving towards a mindset of customer value delivery in shorter iterations vs. delivering full projects. Moving away from large project funding towards capacity funding.
- Lean configuration management and branching strategies focused on continuous releases
- Automation strategies for a continuous integration, deployment, and testing model to allow scaling of a Release-Oriented organization
- Fixed release schedules that provide a known cadence to delivery within groupings of business value streams
- Lean, real-time architectural governance for new and significantly enhanced systems
- The importance of holding and prioritizing retrospectives at both the team and release levels.
- Creation of key Release-Oriented teams to provide the “glue” for the release and provide agile change management, software packaging and release
WHY (10 minutes): Release-orientation gets the entire organization to focus on the most important reason we exist as software developers – maximizing business value delivery through frequent, quality software releases. Moving the organization towards release-orienting thinking provides an invaluable lens for wise organizational decision making. In this portion of the session, we will cover:
- Examples of decisions made when release-oriented vs. project-oriented
- Key benefits realized when you have moved towards release-orientation
- Enablement for scaling of agile frameworks when release-oriented
- Release-orientation budgeting reduces organizational churn for resource allocation
PROS/CONS Game (35 minutes): Now that the room has a base understanding of the WHAT and WHY of Release Orientation, we will break into groups at each table to play the Pros/Cons Game (see http://tastycupcakes.org/2011/07/proscons-game/). During the first 15 minutes of the game, each table will work collectively to brainstorm the Pros and the Cons of Release Orientation. In the next 5 minutes, each group will vote on their one top Pro and one top Con idea. During the last 15 minutes of the exercise, we will ask a designee from each table to report back to the whole room on their top Pro and Con idea to foster sharing of the best reasons to move to Release Orientation (Pros) and the potential obstacles for this transition (Cons).
HOW (15 minutes): The move from project-orientation to release-orientation is both a mindset shift as well as a framework practice change. For too many years, we as software developers, IT shops, and businesses have been successful delivering projects. In this portion of the session, we will cover:
- How to sell the organization on the benefits of release-orientation
- How to transform your company from its current organizational design to a structure that supports release-orientation
- How to make release-orientation a long-lived, self-sustaining aspect of your software delivery framework.
Q&A (5 minutes): The session will finish with a brief questions and answers section.
Impact Mapping: Delivering What Matters
Inger Dickson, Jeffrey Davidson
Track: "Throw Me Something Mister!"
Because of Agile Scrum and better engineering techniques we have pretty much solved the problem of “delivering” software. Unfortunately, it’s not enough. Now we need to turn our focus to delivering “the right” software – software that makes an impact to the customer.
The answer to building the right software begins with a better understanding of the business opportunity and goals. Best of all, we can do this using a collection of familiar concepts, combined in a powerful new way, bringing a shared and measurable vision to your scrum project. This approach is called “Impact Mapping.”
This workshop introduces “Impact Mapping” by demonstrating a collaborative approach to solving the challenge of building the right thing. Breaking into small teams, we will build a sample Impact Map, learn to identify and verify the assumptions you've made, and find new approaches to solving the business problem. We will also discuss using this to measure the output of our effort. Attending participants will receive a handout with a worked example and sample questions and techniques that help lead to a successful mapping session.
Don’t miss this opportunity to learn about and practice the techniques to uncover assumptions and motivations about your current project – and ensure your next project makes the right impact on customers and bottom line. Let's help our customers better refine and communicate their goals. Impact Mapping is at the heart of the customer voice because it literally gives voice to their needs. We will see you at IMPACT MAPPING!
Net-Map: A tool to enable visibility of your complex organizational networks
Rajeswari Kailasam, Amitaksha Nag
What Agile is to ‘Change’, Adoption is to ‘Complexity’(of social connections). This is the reason why change metrics are incorporating complexities embedded in social networks in organizations. These frameworks look deeper into the formal and informal connections, stakeholder goals, motivations, influences that drive or resist adoption.
But how do you identify and deal with the politics of change? How do you nurture change agents to create an ecosystem of collaboration for buy-in of your initiative.
How about a subtle, participatory and spontaneous approach to get the diverse stakeholders into one platform?
'Net- Map' will help you discover the unusual suspects of change, the mission critical connections, the potential risks – elements in your network that are key to adoption of your project.
It is an interview-based mapping tool that helps people understand, visualize, discuss, and improve situations in which many different actors influence outcomes. By creating Influence Network Maps, individuals and groups can clarify their own view of a situation, foster discussion, and develop a strategic approach to their networking activities. More specifically, Net-Map helps players to determine
• what actors are involved in a given network,
• how they are linked,
• how influential they are, and
• what their goals are.
(Net-Map was invented by Eva Schiffer- more information can be found at: http://netmap.wordpress.com/