Have you heard people talking about Test Driven Development (TDD) but never tried it? Now is the time to try! This session will lead its participants through a programming challenge. Don't worry, it's safe. We're going to do a technical version of "follow the leader," where you will do the programming by following along with the session's facilitator. We'll debrief the exercise at the end. Please do bring a laptop or be willing to pair up with someone who does.

We will use the Python programming language, and PythonAnywhere web-based environment to avoid setup and configuration activities. You do NOT need to know Python (or any programming) to participate.

It seems like "Agile" goes with everything these days; government projects, not-for-profit initiatives, scaled agile, startups, etc., etc.. This session will explore agility, management, and product lessons using excerpts from the hit Netflix series Orange is the New Black to illustrate these concepts. This light-hearted, yet valuable, session will take you inside the confines of Litchfield Penitentiary and expose you to the lives of the women who are incarcerated there. We'll use a series of vignettes from the show to highlight lessons in agility. No prior knowledge of the series Orange is the New Black is required for you to enjoy and benefit from this session.

Participants will leave with a handout that contains reminders and tips based on the scenarios we cover in the session.

Speed.

It's been a driver in our industry before it was even an industry. The more Agile becomes more mainstream, the more we think it's part of the package. Books are out promising that certain frameworks can deliver twice as much in half the time. And yet, teams still struggle delivering what's expected of them.

Once I started asking people of all levels of leadership what they thought speed would give them, it allowed me to develop some experiments around those expectations.

Please join me for a case study where we discuss the need for speed, the origins of that desire, and the ways it manifests itself into deliverables. My desire is for the audience to take away some powerful learning into their places of work. Only by understanding the expectations around speed can we reset them into an environment built around trust and support for motivated individuals.

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

The best architectures, requirements, and designs emerge from self-organizing teams.

You know these principles from the Agile Manifesto, but are you taking them as far as you can? In his book “Reinventing Organizations”, Frederic Laloux writes about organizations who have successfully pushed past conventional boundaries in three broad areas. One of those areas is self-management. Scattered around the world, and in a great variety of industries, the companies Laloux profiles have explored radical self-management, achieving incredible things despite removing all positional authority. Or, in English: rocking it with no bosses. This is challenging enough when you build a company with this approach from the ground up; but how do you make the shift in an established company? In this talk, I will focus on my company’s adventures to date in breaking through boundaries of self-management.

For those of you familiar with Laloux' book, here's a little more detail.  We were particularly inspired by the stories of FAVI, a French car parts foundry, and Buurtzorg, a Dutch home nursing organization.  We were impressed by the simplicity of their structure, and it appealed to us because they, too, work in small teams.  But we saw one major problem: the length of feedback loops.  In their businesses, the value chain--time from idea to delivery--is quite short.  But in education, the difficulty of finding time with users, the length of the procurement cycle, and the need to go through one-year or longer studies to verify the validity of our methods means that the value chain is extremely long.  We were wary of some of the heavier processes we had heard about in the Teal world, and wondered if we might forge some new ground: very lightweight process allowing true self-management, wholeness, and evolutionary purpose in a team-based organization with long value chains. One piece of the puzzle was offered by the presentation given by Amber King and Jesse Huth at AgileDC 2016.  They talked about a process for teams to self-select across a larger organization.  I remembered their point that people made their choices first based on what was good for the organization at large.  But that left us with the question: how would people know what was good for the organization at large, especially with extremely long feedback loops?  We had seen people inadvertently go many miles down a bad road before; why would it be any different here? So, we launched a pilot aimed at exploring a few other key elements, which we hoped might fit together to build the lightweight solution we dreamed of.  In addition to offering some background for folks new to Teal, this talk is about the design, running, and results of that pilot, and some of the things we learned about ourselves along the way.

Diversity. It's the topic of the hour. Organisations are all putting 'diversity' and 'equal opportunities' on every job ad. But, for some organisations it still seems to be a struggle.

What's the goal? Do we want diverse teams because it's the "right thing to do" or is it "good for our teams and organisations"? Are we hiring minorities to keep up with quotas or our competition?

This talk will engage the audience in a frank discussion on what diversity is, why we need it and how we might achieve it. Guiding attendees through the latest research with practical exercises to demonstrate the issues and open discussion to find answers to the following questions:

• What does diversity mean? How does it relate to me? 
• Why does diversity matter in effective teams? 
• How can teams where everyone is different be effective? 
• How can we increase diversity in our organisations? 
• Is positive discrimination a feasible and ethical way to achieve diversity in our organisations? 
• How can I employ a diverse group, when they are not applying?

Diversity is no longer just a moral imperative, it's critical to effective organisations.

Eric Ries’ “The Lean Startup” has made a huge impact. But many people shy away from its tenets because they don’t work in a startup. Although Ries mentions some of the ways that his thinking applies even in established companies, his primary focus understandably rests on the true startup. Through working with teams in my company on a portfolio ranging from greenfield development to 15-year-old legacy products, I have uncovered some practical techniques for applying Ries' core ideas on teams at any phase of the product life cycle.

Earlier this year, I led a half-dozen eight-week-long study groups in close readings of Ries' book.  Despite rich conversations and lots of light bulbs going off, I was worried: in a year, would anyone remember more about the book than that its cover was blue?  While people liked the ideas in the abstract and even saw how they applied in concrete examples in the book, they felt lost trying to apply the thinking to our work, especially since we were not working in a prototypical start-up.  I began looking for ways to apply these ideas practically, in every sprint, even on teams working on legacy products.  I focused on the generic idea of validating hypotheses.  While this was somewhat familiar to teams working in an Agile context, people struggled to find hypotheses to test in the first place, and then to design lean experiments aimed at testing them. They kept coming to the same place: "The only way to test this is to build the whole thing and see what happens."  Surely, this couldn't be a simple fact we had to accept because we worked with big complicated, non-consumer products beyond the start-up stage.  I began building exercises and techniques for tackling these problems.  By testing these with teams and observing the traps we continued to fall into, I tweaked these to be more effective.  In this talk, I'll discuss the underlying ideas, the two practices I have come to believe are crucial (first finding hypotheses and then testing them leanly), and run activities that give people a chance to try applying them.

Do you have a person hanging around your agile team who is responsible for training clients or end-users on a product or service you are developing?  (Or, maybe you are a learning professional (a trainer, instructional designer, e-learning developer, or curriculum designer) embedded with an agile team?) Who are they? What do they want? What can they do for your agile team? Leveraging insights from learning professionals working with agile projects, this session will explain the role of a learning professional; offer some potential benefits of having a learning professional embedded on an agile team; and offer some practical tips for a successful relationship between agile teams and learning professionals.