Coaching Like “Columbo”: Simple Questions to Start Tough Conversations
Track: Jazzin' It Up
Small compromises in Scrum practice can ultimately lead to major impacts on team health and their ability to deliver valuable solutions to users. Unfortunately, between getting lost down in the weeds of technology creation and the natural human tendency to postpone or avoid uncomfortable discussions, it’s easy to lose sight of how a shortcut today may kill a team (or even an entire company) down the road.
Working in teams, participants will explore the links between Scrum practices and tangible results using the approach of beloved American TV detective, “Columbo:” Ask a simple question, and then tease apart all the justifications and excuses when the answer is less than ideal. The author will first lead the entire room through a discussion of one seven basic questions about Scrum performance, with the goal of identifying healthy and unhealthy responses, and identifying what behaviors and dynamics would support each state. Working in groups, participants will tackle another question in the same manner on their own. The session will conclude with time-boxed presentation and discussion of each group’s findings.
Design your next Contract Coaching Gig: Know When to Hold 'Em, Know When to Fold 'Em
Steve Holyer, Nancy Van Schooenderwoert
We are Agile and Scrum Coaches-for-Hire (“have manifesto, will travel!”). We want each of our gigs to be successful for the organisation that employs us and also for ourselves as coaches, so that we can promote the spread of Scrum and Agile (and make an honest living). We learned from the words of an old riverboat gambler (as relayed in song by Kenny Rogers) that “every hand’s a winner, and every hand’s a loser.” The Gambler’s secret is knowing how to play the game.
Whether you are an independent contractor or working through an employment agency, this 90 minute workshop will help you uncover better ways to design your next Scrum Coaching gig to create that elusive winning hand. For you and the organisation.
As we focus on designing an effective relationship between a contract Scrum/Agile coach and the hiring organisation, we’ll explore “case study" scenarios from our own assignments that describe ways that Scrum and other Agile practices are introduced into organisations. We will explore Gerald Weinberg’s addiction model as one way to better understand organisations that hire independent Scrum coaches (and employment agencies if you are working through them) and also to understand the role you choose to play.
We will explore which jobs to take, and which jobs to turn down. We will explore guidelines for the “chartering” activities you can undertake to create a winning coaching framework and lay the groundwork to smoothly navigate coaching exit points during the life of the coaching mission.
This session is intended for practicing independent coaches, Scrum Coaches-for-Hire, whether contracting directly or working through an employment agency. We also welcome internal coaches and participants who want to begin independent Scrum coaching or learn more about it. Insight from managers of organisations that hire Scrum Coaches will also be a very welcome addition in the workshop.
Facilitation & Communication in Agile Teams
Track: Jazzin' It Up
While traditional projects expect most communication to take the forms of email and manager-led meetings, agile projects expect teams to self-organize, collaborate and participate in decision-making. But what is self-organization? How do we facilitate these Scrum meetings so they're productive rather than disruptive? This 90-minute tutorial will focus on what it means to self-organize, how it occurs and how to help it along, and the hurdles that must be cleared in the process. See how the proper use of facilitation in agile meetings can be a key driver in the development of high-performing self-organizing teams.
Process/Mechanics (how will I run my session):
Attendees receive a 6-page handout containing notes and reference material to reinforce the concepts covered in the exercises/discussion.
Times are based on a group of no more than 30. More than 30 attendees will stretch the setup and debrief times, so there’s 10 min of slack built in to handle uncertainty.
• Welcome! Introduce myself, review topic and what to expect in this session. (3 min)
• Self Organizing Exercise 1: organize yourselves in a line alphabetically by state-city-street name. (10 min including debrief; also serves as ice-breaker)
• Discussion on the definition of self-organization and its importance in agile. (7 min)
• Self Organizing Exercise 2: 60 steps – a boss-worker pairing with both micromanagement and then self-organization activities. (10 min including debrief)
• Discussion on communication and Jeff Biglar’s “Tact Filter.” (5 min)
• Listening exercise: Reflective listening. (7 min incl debrief)
• Discussion on facilitating meetings and the “discussion toolkit.” (10 min)
• Facilitation Exercise 1: Meeting simulation with pontificator. (15 min incl debrief)
• Facilitation Exercise 2 (if time): Meeting simulation with two attendees in conflict with each other. (15 min incl debrief)
Closing (5 min)
Get an Agile mindset with NLP
Room: Oak Alley
Because not everybody is an NLP practitioner, I’ll explain the basic principles of NLP and use techniques which are easy to understand and which everybody can use after some practice. With the help of these techniques you will get insight in the most common restrictive believes and thoughts of people which hamper them in the change to Agile and which I collected during the Agile transitions I did. By using language patterns and metaphors we can startup a search in our unconscious to options and alternatives which helps to change our mind. When we start think differently, our behavior will naturally start to change. Once you have started to master this change for yourself, then you can start to coach other people to become better at identifying and changing their thinking and subsequently their behavior in relation to Agile.
Step by step description
1. Introduction: Resistance during Agile transition.
You are in the middle of an Agile transition but you stuck because there is resistance to change. How do you recognize resistance? What can you do to solve this? How can you succeed? Why is it difficult to change behavior?
2. Exercise: Discuss in your group: What kind of resistance do you see in your environment? Give examples and write them down.
3. Resistance examples
o This doesn’t work here, our project/organization is very special, too complex, too big/small etc.
o Why should we do things differently? We are doing it for over 20 years now and it works fine
o We are already doing Agile (in name only), so don’t worry
o Our Business don’t want to do it differently
o This is something our management want, but doesn’t work for us
4. What is an Agile mindset?
What kind of mindset is needed when you work Agile? Why is another mindset needed than in a traditional way of working?
5. Exercise: Discuss in your group: What is an Agile mindset? Give examples and write them down.
6. Agile mindset examples
o Responding to change over following a plan - Behavior: flexible attitude, can easily change opinion, can improvise, can let go and adapt to new ideas
o Good is good enough to take the next step – behavior: no need for details, think in big picture, can deal with vague parts in the requirements, no perfectionism
o Inspect & adapt – Behavior: thinks about improvements all the time, not afraid to try out new things (brave), Let’s do it mentality
o Yes we can! – Behavior: positive mindset; think it is possible in stead of it is not possible, think in solutions in stead of problems. see failures as a change to learn, not afraid of making failures.
o Work as a self-organising team – behavior: prefers collaboration in stead of doing it alone, don’t blaim individuals, accept other people opinion, respect others, celebrates diversity, dare to make decisions, problem solving, I trust my team that they can do the job
7. Introduction to NLP
What is NLP? What are the basic principles? How can you use this in Agile transitions?
Our view of the world is filtered by our experience, beliefs, values, assumptions, and biological sensory systems. We act and feel based on our perception of the world rather than the real world. We can use NLP techniques to remodel our view of the world and become more open-minded. Open for another way of working. It starts with the believe that we are the only one responsible for our thoughts and that we can change them.
8. Explain NLP basics
o How our brain works: Filters, generalizations, how we react on situations, why we react different then other persons.
o Be convinced that you can choose how you will react on a situation
o The power of positive thinking (think in opportunities in stead of problems)
o Get insight in your values and believes, are they supportive or restrictive
9. Exercise values & believes: Think about the values and believes you have. Where do they come from? How strong are they and do you think they are still functional? Write down which ones can work restrictive for you. Think how you can rewrite them and make them very powerfull for you.
Examples of restrictive believes and thoughts regarding Agile
o I will finish a step totally before I start with the next step
o I check what my team members do because I’m not sure they will do it right. That’s how I keep control.
10. Explain Technique - Sleight if Mouth (SOM)
Sleight of Mouth is a persuasion skill, a vehicle for the reframing of beliefs. It is a system of 14 different patterns of response to a stated belief. A system that, once mastered, can allow you to always have a response that will effectively elucidate your position and help you to persuade rather than be persuaded. It helps people to get another view of the world.
11. Exercise Slight of mouth: Giving the following list of stated believes against Agile, give examples of all 14 patterns how you can react. Do this with your group.
Improv: Learning Lessons from Master Innovators
Paul Tevis, Jake Calabrese
This energizing and laughter filled workshop will be fun, but it’s no joke! Theatrical improvisers are among the most Agile people out there, particularly when it comes to responding to change over following a plan. What is the “secret sauce” that allows them to produce something innovative from nothing (in front of a live audience!) in a way that seems like they were following a plan all along? The way of improvisation is the way of continuous learning, and it has applications far beyond performance -- including in Agile teams. This experiential workshop will give you real tools and techniques to help teams learn and innovate!
This session is targeted at anyone who is on or works with agile teams (although anyone is welcome!). You will experience and learn improv activities you can use with your own teams to help spur learning and innovation including an opportunity to use these techniques to find solutions a challenge you bring to the workshop.
This session is built around 7 “rules” for improvisation, originally articulated by Dave Morris in a talk at TEDxVictoria (http://www.youtube.com/watch?v=MUO-pWJ0riQ)
Let yourself fail
Play the game
Relax and have fun
While these principles originate in theatrical performance, they have specific application in business as well -- particularly in an Agile context. This experiential workshop will incorporate activities that allow the participants to explore each of these “rules” and how they apply to their own situations. We will lead each of these activities, then debrief the participants on their experiences. Each section will take approximately 10 minutes. The specific activities we are planning to use are listed in parenthesis but are subject to change.
Get Present activity (The 8s): In order to learn, our brains needs to be in the same place as our bodies. How often do we get them together? To facilitate learning, we start by “getting present” and getting our brains in the room.
Let Yourself Fail activity (Switching Fingers): Success tells us we’re ready to learn; failure tells us that we’re learning something. But if we feel that failure isn’t safe, we won’t let our let ourselves learn. This activity focuses on failing safely so that we become willing to step to our “growing edge.”
Play/Relax and Have Fun activity (Rock-Paper-Scissors Champion of the World): Once we’ve gotten present and come to terms with the idea that failure isn’t the end of the world, we’ll start the transition from our inward-focused work to looking at how we can learn from others. This activity focuses on “getting into the groove,” letting go of our attachment to personal success, and supporting others to do great work.
Listen/Play the Game activity (Word-at-a-Time advertisment): The heart of collaboration is being open to learning from each other to create breakthroughs. If we always do what we always do, we’ll get what we always get. This activity focuses on the single most important collaboration skill: listening. It also opens up questions about what “rules” are for. Are your rules putting you at choice or forcing your hand?
Say, Yes/Say And (“Yes, And” storytelling): Working with a partner, we will explore what happens when we listen deeply to other people’s ideas, learn from them, and build something new out of them.
Integration (“What I Like About That Idea Is...” ): This is where we take the training wheels off and have participants work with each other on real problems they’ve brought, using all of the techniques we’ve just given them.
Jazzin the Duo – How to successfully introduce pair programming to your organization
Track: Jazzin' It Up
Pair programming is one of the key techniques in XP. It is also one of the hardest process adjustments for teams to make. Independent, intelligent and opinionated programmers are not accustomed to spending long periods of time in conversation and negotiation with their peers. Soft skills and aptitudes come into play that have never been needed before. The benefits of increased productivity are counterintuitive and difficult to buy into at first. As a result, the introduction of pair programming frequently is met with resistance from developers, or developers have a negative experience with it. In short, attempts to introduce pair programming often ultimately fail.
The focus of this session is to reveal the reasons for that failure, and to teach strategies for avoiding it. Please note, the nugget of knowledge here is not “how to pair program”. This session is intended for managers, agile coaches and developers who are interested in bringing pair programming into an organization and want to know the best strategies to make the transition successful.
There are approaches that have been shown to be more effective than others when introducing this practice to an organization. This talk will explore the transition to pair programming, provide 2 recommendations for how to orchestrate the adoption process and explain why they are recommended. It will include video interviews with a group of developers who were practicing pair programming, at various levels of experience with the practice. The videos provide several different developers’ insights into what the pair programming transition is like and how to cope with it.
In the instances where I have presented this talk in the past, the feedback I have gotten is overwhelmingly positive towards the video interviews. They aggregate the experience of a group of developers and their insights into what makes pair programming good, what makes it hard, and what to do about it. Though it may seem odd to include video in a conference session, I believe based on past feedback that I would do the attendees a disservice by not letting them benefit from the rich information in these videos. I can grant access to reviewers if you wish to preview the videos – please send me your email address.
Lean Startup + Story Mapping = Awesome Products Faster!
David Hawks, Brad Swanson
Track: "Throw Me Something Mister!"
Too many companies focus on maximizing output and often miss delivering the right features. Studies show over 60% of features built in our industry are rarely or never used. You might deliver a lot of features, but if they are rarely or never used, does it matter how fast you do it?
To deliver the right outcomes, you need to learn your customers needs and validate your assumptions as early as possible. This means getting an early version of your product completed to start testing, validating and improving. We will demonstrate how to combine Lean Startup and User Story Mapping techniques to determine where to start and how to learn early and often.
In this hands-on workshop, your team will start with a partially completed Lean Canvas to flesh out and then define a roadmap by building a User Story Map for your product. We will introduce the concepts of Lean Startup, Minimal Viable Product (MVP), Outcome over Output and Validated Learning. Upon completion, you will learn the following techniques: Lean Canvas and User Story Mapping.
- Presentation: Establish premise of why you should focus on outcome over output (10 mins)
- Exercise: Why it is important to accelerate learning in software product development (2 mins)
- Presentation: Introduce Lean Startup and Lean Canvas (10 mins)
- Hands-on Group Activity: Have a partially completed Lean Canvas and have them fill in the remaining sections (10 mins)
- Presentation: Introduce Story Mapping (10 mins)
- Hands-on Group Activity: Have them take one persona and one key benefit and create a map. (15 mins)
- Presentation: Talk more about features of Story Maps (10 mins)
- Hands-on Group Activity: Have the teams identify key risks/assumptions (5 mins)
- Hands-on Group Activity: Have the teams prioritize their maps into a walking skeleton to define MVP - with a focus on the priority being learning (5 mins)
Teaching Scrum to Management
Room: Belle Chasse
Track: Hop On a Streetcar
Executive Summary: During the 2nd half of last year I had the rare opportunity to design and deliver a learning experience to a large swath of the director and above population of a 50,000 employee company. In the course of teaching over 400 people in 30 workshops, I learned a lot about their learning needs and how to help them achieve their learning goals. My goal is to share this experience with the Scrum community to (1) provide a framework for others to use and (2) help others avoid the pitfalls I encountered.
1. Background (5 minutes) - The company's journey and the request to develop and deliver the course - the vision of a "Leadership Immersion Workshop" for directors and above to learn Scrum in the context of an Agile transformation.
2. The Workshop Design (20 minutes) - What I built, how I built it and why.
3. Delivering the Workshop (10 minutes) - What I learned from the initial sessions
4. Inspect and Adapt (10 minutes) - How I continued to inspect and adapt through 8 versions of the workshop and 3 more "custom designs."
5. Training More Trainers (10 minutes) - Turning the content and delivery over to groups of internal coaches.
6. Opportunities (10 minutes) - Other ideas that didn't fit for this company that may fit in other organizations (what I could have done differently).
7. Exercise (15 minutes) - I will share the highest rated part of the workshop, a self-correcting Scrum roles game that attendees can use immediately after the gathering.
8. Discussion and Questions (10 minutes)