11:30 - 12:30 - 60 Minute Sessions

Applying Cowboy Wisdom in Scrum
Tom Mellor
Room: Elmwood
Track: Lagniappe

Type: Workshop
Level: 1

While growing up in Montana, I worked on various ranches with cowboys who imparted their wisdom about work and life. This wisdom was gathered into a collection of sayings that apply often to what we do and encounter in Scrum.  Here is a sampling of some of the 25: 
 
1. Never approach a bull from the front, a horse from the rear, or a fool from any direction 
2. Good judgment comes from experience, and a whole bunch of that comes from bad judgment 
3. When you give a lesson in nastiness to a critter or person, don't be surprised if they learn it 
4. Never miss a good chance to shut up; silence is usually the better option
5. Talk slowly…and think quickly
6. If you're leadin' the herd, look back now and then to make sure it's still behind ya
7. Generally, you ain't learnin' if you’re talkin'
8. Your biggest troublemaker looks at you in the mirror 
9. If you think you're a person of influence, try orderin' around another person's dog
10. Don't worry about bitin' off more'n you can chew; your mouth’s a whole lot bigger'n you think 
11. When you lose, don't lose the lesson, too


Applying Organizational Change and Leadership to Agile Transformations
Joe Vallone
Room: Magnolia
Track: Rolling Down the River

Type: Lecture
Level: 2

It is no secret that when an organization chooses to transition to Agile methodologies, it requires an enormous commitment to leadership and change management. Even in prescriptive methods of Agile transitions, such as SAFe, I have found this subject matter deficient, especially in the area of practical application. This presentation is based on a training class I developed and conducted with executive leadership at American Airlines. It focuses on how to apply Dr. John Kotter’s  8-step model  of change management  and leadership to help transition an organization to support an Agile transformation. I have been involved in large scale Agile Transformations at Nokia, AT&T, American Airlines, Telogical Systems and VCE. I have successfully applied the principles of this process at several companies, most recently at American Airlines IT division to train executives in Agile Change Management.
 
Dr. John Kotter is arguably the foremost authority on the subjects of Leadership and Change Management.  He is a graduate of MIT and a professor emeritus at Harvard. Dr. Kotter’s vast experience and knowledge on successful change and leadership have been proven time and again. The presentation was developed to apply the principles of Dr. Kotter’s book: Our Iceberg is Melting, to Agile Organizational Change Management.

Build What You Need, Not What You Asked For
David Bulkin
Room: Rosedown
Track: Jazzin' It Up

Type: Workshop
Level: 2

User stories and acceptance criteria alone do not provide enough clarity, so TDD (Test Driven Development) became a popular way for a developer to build what he / she thought the business said. 
When it became clear that TDD was not enough, ATDD (Acceptance Test Driven Development) / BDD (Behaviour Test Driven Development) became popular, as they provide a common language for business and development so that development can build what the business really wanted. 
But building what the business wanted is not enough! With HDD (Hypothesis Driven Development), we can test our business case, just like we test our code.
When we find that results don’t match our expectation, we adjust our business case to get better business results. In this hands on workshop, we will create several examples in ATDD/BDD and then extend out to the business case level with HDD.
 
This workshop is heavily interactive and hands on.  The agenda is:
- Introduction (5 minutes)
- Hands on Exercises One & Discussion (20 minutes)
- Hands on Exercises Two & Discussion (20 minutes)
- Recap (5 minutes)
- Question and Closing (10 minutes)
 
After a brief introduction via PowerPoint slides, we will go over two exercises.
 
For each exercise, we will start with a business goal, create a testable example for it, then adjust the business rules and testable examples to create a thinner slice of functionality that we can go live with to meet the business goal and get validated learning.  I will tell the class the results of their release (e.g. simulate the usage of our software) so that they can test their hypothesis and pivot.
 
Our first example will be for selling large blocks of tickets to our sporting events, to increase revenue.  Our second example will build on the classic Dan North ATM BDD scenario, but with twists including overdraft fees, and unhappy customers who close out their accounts.  Depending on time available, the second example will be adjusted up or down in complexity so that ample time is saved at the end for questions and closing.

Creole cottage – Constructive Pattern for building a Scrum Master community and continuous improvement of a new agile organization
Ni Sun
Room: Oak Alley
Track: Rolling Down the River

Type: Workshop
Level: 2

When walking through the French Quarter in New Orleans, you must be impressed by the historic housing styles Creole cottages. The typical Creole cottage is composed of one Chimney, two gabled windows, two doors and two windows. Comparing with these structural elements of Creole cottage, building a Scrum Master community, also needs to take consideration comprehensively about the key elements, such as business goal, purpose, methodology, tools and alignment. 
 
The “Creole Cottage” pattern is abstracted from a real-life experience. It’s a practical and hands on pattern to help building a Scrum Master community while solving company-wide problems to achieve business goal. It can be said to kill three birds with one stone.
 
The whole session covers the contents below:
1. Background (5 min)
2. “Creole Cottage” pattern introduction (10 min)
3. Real case experience sharing (25 min)
4. Exercise: Create your instance using the Creole Cottage pattern (10 min)
5. Lessons learned and summary (5 min)
6. Q&A (5 min)
 
Principles:
Scrum, system thinking, cause-effect diagram, root cause analysis, Deming improvement cycle PDCA (Plan-Do-Check-Act), organization alignment, inspect and adapt.
 
Outline:
1. Background (5 min)
 
The new agile organization is like a newborn baby, weak, fragile, unsustainable, threatened by growing crises. There are big barriers between scrum teams which belong to different business units, resulting in cross-team product delivery being delayed again and again; because of lack of visibility of defect data and standardized processes, complaints happen between the customer service team and development teams, such that the average lead time of live defects is even longer than the release cycle.
 
On the other hand, the first wave of Scrum Masters is brand new, and there is a need to build a community to grow Scrum Masters from both a knowledge and a practice point of view.
 
As an Agile Coach, also a newcomer in a new agile-transformed company, I was given a mission to create a Scrum Master community as well as solving company-wide problems.
 
 
2. “Creole Cottage” Pattern Introduction (10 min)
 
A Creole cottage is a type of vernacular architecture in Gulf Coast of the United States. You can see a lot of Creole cottages in New Orleans. 
 
Comparing the structure of a Creole cottage to building a Scrum Master community, we should take consideration of all the structural elements. The two gabled windows on the roof serve two purposes: one is to grow the Scrum Master’s agile competence, and another is to solve the company-wide problems. The chimney is the organization’s goal, giving us the business direction. The foundation of the cottage is the company’s foundation: people, organization gene, processes, the ways of working, etc. Just like how building the cottage’s foundation is important, the most essential thing to building a Scrum Master community is to create fundamental alignment. That means abstracting common interests from different departments and different roles. That’s where we start.
 
After we have the business goal and understanding the existing situation, the next thing to do is to close the gap – build the cottage walls. Just like the two doors of the Creole cottage, here we use two fantastic tools: Scrum and Deming Improvement Cycle PDCA (Plan-Do-Check-Act). We use Scrum methodology to develop two continuous improvement projects: one is cross-team collaboration enhancement, and the other is defect flow improvement. They are the Creole Cottage’s two windows.
 
Key Elements of the “Creole Cottage” pattern
    1) Chimney: Business Goal
    2)Left gabled window: Grow Scrum Master agile competence
    3) Right gabled window: Solve company-wide problems
    4) Foundation: Alignment among Product Owner, Customer Relations, Development Team, Management Team and Core Technology Team
    5) Left door: Scrum methodology
    6) Right door: Deming improvement cycle (PDCA)
    7) Left window: cross-team collaboration enhancement
    8) Right window: defect flow improvement 
 
3. Real case experience sharing and analysis (25 min)
    3.1 Background
    After I joined EF Labs as an Agile Coach, my manager Eric Azumi, Vice President of EF Labs, told me his vision is to create continuous improvement culture within the organization. He gave me a mission: Create a Scrum Master community while solving our top company-wide problems. In the company’s yearly offsite meeting, our CEO, Bill Fisher, emphasized two business goals: to reduce product defects and to break down team barriers. 
 
    After getting the goal and the business direction (the cottage chimney), I started to build the cottage foundation: to understand the existing situation by discussing with all counterparts (Technical Development Managers, Scrum Masters, Product Owners, QA Manager, Organization Designer, Developers, QAs, etc).  After the kickoff meeting, we started to build the cottage’s two windows – the two continuous improvement projects: Product Defect Flow Improvement and Cross-Team Collaboration Enhancement. 
 
    3.2 How – Build cottage windows by using two tools: Scrum and PDCA cycle (two cottage doors) 
        I acted as the Product Owner for the two projects. All ten Scrum Masters acted as developers, dividing into two teams. Each team focused on one project. The whole procedure was organized according to the steps below:
        a. Deep understanding of the current situation
        b. Root Cause Analysis for current problems by using cause-effect diagram
        c. Project setup: Start PDCA cycle
        d. Generate prioritized project backlog: every action is one backlog item 
        e. Use three sprints to implement the backlog items
        f. Weekly meet-up, inspect and adapt every sprint
        g. Product demo to the whole company
 
    3.3 Output 
         Project 1: Product Defect Flow Improvement
         a. Standardized live defect process, definition of roles and responsibilities
         b. Defcon system (defect severity calculation system)
         c. Live defect reports in JIRA defect management system
 
         Project 2: Cross-Team Collaboration Enhancement
         a. Cross-team project workflow
         b. Team Portal (electronic seat map, each scrum team’s workflow and structure)
         c. Agile Salon and Agile games
         d. Badminton rallies
 
    3. 4 Results:
    After making product defect data transparent, we solved many long-open defects. Average defect lead-time has been reduced. There is more effective communication between customer relation teams and scrum teams. The defect fix flow is more efficient. The feature defects report provides the management team with quality feedback, and is now in the measurement matrix of business OKR (Objectives and Key Results). 
 
    Each scrum team’s structure and profile are now very clear. A cross-team collaboration culture now exists, and teams are more integrated and likely to support each other. Cross-team project workflow now is working smoothly. Project delays due to dependencies on another team’s tasks or due to poor collaboration happen less often. Employees from all disciplines – developers, testers, customer service engineers, content developers, product owners, and super-geeks from the technology team all took part and enjoyed the agile games.
     
    On the other hand, from the kickoff meeting to the final demo, over six months, Scrum Masters talked with their counterparts and key stakeholders, and led changes organization-wide. Their competence and influence developed and became more established during the process. 
 
4. Exercise: Create your instance by using Creole cottage pattern (10 min)
    4.1 Each member of the audience will get a blueprint of a Creole cottage. 
    4.2 The audience will be split into teams of four. One person from each team introduces his/her company’s context, and then the group will work together to design how to build their own Scrum Master community in their own organization by using “Creole cottage” pattern. 
    4.3 Blueprint demo: one representative will present the output. 
 
5. Lessons learned and Summary (5 min)
    5.1 Similar to creating the key elements of a Creole cottage, this pattern provides a practical way for finding the key elements of building a Scrum Master community according to the real life situation of one company. 
    
    5.2 Just like building the cottage foundation, the most essential thing to building a Scrum Master community is to create alignment between all counterparts, to abstract the common interests, and to build a sturdy foundation. 
 
    5.3 Solving company-wide problems is the same as building a Creole cottage: they are all about systematic projects. Whoever is leading for change should take into consideration all aspects as comprehensively as possible, and understand the situation as deeply as possible. The organization is a system with multiple inputs and multiple outputs. One simple action might solve the problem temporarily, however the problem will come out in another place in another guise.
 
    5.4 Scrum, besides being used for software development, can also be used for continuous improvement in an agile organization.

Enabling Distributed Agile Teams
Timothy Wise
Room: Fountain
Track: Lagniappe

Type: Workshop
Level: 2

Distributed anything is hard. 
 
Participants will be led in a negation technique to collectively form working agreements based on common complications of distributed teams.  The presenter will be neither for nor against distributed teams.
 
Outline:
Talk about distributed teams (5 minutes)
Facilitate discussions about complications of distributed teams (10 minutes)
Negation session for distributed teams (20 minutes)
Debrief and form a set of working agreements (15 minutes)
Deliver quick wins that participants can take home
(10 mins)
 
The attendees will pretend to be six forms of distributed/dispersed teams:
1. Team augmented with two offshore staff
2. Two offshore (US) people with rest of team onshore (Russia)
3. A home team in the corporate office that has a independent, mirrored foreign team
4. You are the foreign team that has a separate, mirrored team in the corporate office
5. Fully distributed team
6. Each team member has an offshore mirror of themselves
 
The negation technique will be used to facilitate the creation of a list of issues that will hurt the situation, not solve the problem.
One the list is done, participants will prioritize the list.
Then, participants will negate each of the top three hurtful issues.
When the issues are negated, the result will be a set of working agreements.
 
The audience members will be put in each situation for the distributed staff.  It helps them understand the plight of everyone, not just the mainland team.  A review each situation will be performed.
 
At the end, the participants will take home some immediate quick wins through a final section including a sample communication kata and useful tools and tricks for distributed teams.

Scrum in Context: Exploring the end-to-end SDLC Value Stream
Leslie Morse
Room: Belle Chasse
Track: Hop On a Streetcar

Type: Lecture
Level: 1

Far too often I see organizations approach Scrum practices in such a way that they come up with an idea for a project, hand it over to  a Scrum team, and essentially “assign-and-wish” with an expectation that the team has everything they need to make it happen. This approach is naive and at best will result in a successful project if the complexity of the product and the dynamics of the organization are pretty straightforward. At worst, this approach will garner a sour taste for Scrum practices and potentially jeopardize an entire Agile transformation. 
 
In an organization of any scale what-so-ever, the five phases of the SDLC (Plan, Design, Build, Test, Implement) are not self contained within any single Scrum team. Life would be way too easy, and we wouldn’t need Scrum conferences if it were that simple. 
 
Experience has shown us that Scrum is very well suited for containing the Build & Test phases of the SDLC, but as soon as multiple teams need to work together on something the phases of Design & Implement take overhead to coordinate. Sophisticated engineering practices can mitigate much of the overhead for Implementation, and collaborative cross-team backlog grooming can handle Design consideration. What about Planning though; how do you even know what Scrum teams to engage and how to line up all the necessary dependencies for a project?
 
I’ve seen it fail, and attendees of Scrum in Context will get to hear that story. I’ve over-engineered it myself, and attendees will get hear that story too. Most importantly, I’ve settled in on a handful of considerations that make putting Scrum in perspective something even newbies can get their arms around.
 
During the presentation 4 key topics will be explored
1. Vetting Ideas & Initiating Projects
2. Forming & Organizing Scrum Teams
3. Getting a Scrum team ready for Day 1 of Sprint 1
4. Balancing the Definition of Done with Release Overhead
 
Each topic will be explored through 3 components
1. Philosophy - What is the intent behind this topic and how does it align with the SDLC, Agile Manifesto & Scrum Framework?
2. Practices - Examples of practical activities and techniques that can be used to to set Scrum teams up for success.
3. Ponder Points - Topics that should be explored in order to tailor practices for your organization.
 
The discussion will be framed up in context of a typical organization’s value stream for completing and releasing products into production. Attendees will leave with an understanding of how to assess their organization’s SDLC, best form Scrum teams in support of that value stream, initiate projects successfully, and manage expectations for release products into production. 
 
Scrum in Context is best suited for ScrumMasters, Managers, and those leading Agile transformations within their organization.

Smart Scaling: Finding the right approach for Enterprise Agile
Richard Dolman, Steve Spearman
Room: Melrose
Track: Hop On a Streetcar

Type: Lecture
Level: 2

Based on recent workshop experiences from 2013 Scrum Alliance Scrum Coach Retreat.   
A group of Coaches collaborated on the topic of: “How can we, as coaches, best guide or facilitate the selection and implementation of a scaling approach for an organization?”
 
Since the topic of scaling and scaling frameworks has become more prevalent of late, we believe this topic would have broad interest for its relevance and timeliness.   
 
What is the right scaling approach for your organization?  
In exploring this question, we will stay away from any framework-specific cheerleading or bashing.   We will instead elicit questions and insights that help drive decision-making and/or improvement.  
We don’t want to line up behind one scaling approach over another.  We want to help our organizations understand their needs and then assess the approach that best serves those needs. Inputs into this topic include direct feedback from "scaling" thought leaders, such as Dean Leffingwell, Craig Larman, Scott Ambler and others. 
 
We will present the concept of the Scaling Agile Differentiator, which will be a tool for evaluating and selecting the right approach for an organization.
Participants will be encouraged to share their experiences, perspectives and questions on the topic.

You be the Coach! (Agile for Non-IT at our organization)
Burton White, Richard Cheng
Room: Jasperwood
Track: Lagniappe

Type: Workshop
Level: 2

At our company, Excella Consulting (a 100+ person consulting company), we used Agile concepts to help us complete our corporate initiatives and manage our Marketing and Communications efforts.  Along the way we had some success, lessons learned, and needed to inspect and adapt.  
 
In this session, we will share our experiences, but the primary focus is less about what we have learned in our experiences.  The primary focus is the attendees to use the Excella situation and experiences as a background for creating their thoughts on solutions.
 
The session begins with an Introduction and a background on the organization needs. From there, we launch into simulations and exercises to have attendees work in groups to identify:
- What kind of Agile solutions should be in place to achieve the key goals.
- How to get started implementing the Agile solutions
- How to deal with the issues and impediments that arose
- Next steps based on the lessons learned to date
After each simulation/exercise, there is a debrief and lessons learned.  From there, that information is used to setup the next exercise.
 
This session will be facilitated by Burton White, a Partner at Excella and the Product Owner, and Richard Cheng, a Principal at Excella and the Scrum Master.