Agile2017

Abstract:
Give Control, Create Leaders... teaching “bosses” to be leaders.
Some schools of Lean talk about “Leader Standard Work” but this term is often misunderstood to mean “Leader Standard Practices”. In order to effectively lead people we must know how to serve them. Agile has used the term “servant leader” for some time now, but if you understand real leadership you know that term is redundant.
Strategic leaders understand what the purpose of not only their own position is but the purpose of their organization. They understand what gets their employees out of bed and through the front door of the office every morning and works hard to support those people.
In this session we’re going to learn how to be an effective leader using “leader standard work” unlike any you’ve ever seen before. We’ll learn exactly what managers, directors and VPs in effective agile organizations do to help their reports, and how to adapt the work of David Marquet to software organizations.

Learning Outcomes:

• During this session we'll learn how to effectively define standard work for leaders from managers all the way up the chain through appropriate abstraction to values.
• Attendees will learn where to create effective boundaries to allow for emergence necessary within teams to be truly agile.

Attachments:

• GiveControlCreateLeadersAgile2017.pdf

Abstract:
Facilitating Success Without Unicorns
The feeling of individual success is a crucial part of meaningful work and gives purpose. The feeling of purpose is crucial in retaining employee happiness. In software, purpose is fleeting. One task is finished and the next one starts. Yet a lot of what we do in Agile minimizes that feeling. Working collaboratively means focusing on the team’s successes and can bury individual contributions. Iterative cycles can lead to a constant feeling of never being done. The answer to this is to allow individuals to find meaningful goals and strive to complete them.
What if each person was given a facilitator that they trusted to guide them in finding personal goals?
It would take a particularly skilled facilitator to pull this together such that the employee felt helped and not put upon. That facilitator might as well be a unicorn because they are rare and hard to find.
I have experienced an employee-driven process of encouraged self-improvement. We got rid of the unicorn facilitator by allowing employees to choose facilitators from their peers. This allowed employees to directly control the process and find people they feel comfortable with that have no authority over them.
This talk is the story of how we discovered the employee-driven process to facilitate and help achieve individual successes. My current company enables employees to look inward to find what is meaningful to them while focusing on psychological safety, peer facilitation and real support.
Beyond explaining the process, I will examine the thoughts that helped develop it. I will explain why we do each of the things we do. My story is a practical account that gives attendees the knowledge they need to implement a system mimicking what we have, but with their own constraints. I hope attendees will leave with the framework to create a psychologically safe system that encourages individuals to set and strive toward their own, personal meaning of purpose.

Learning Outcomes:

• What it means to have a process of enablement vs judgement.
• Each person should leave with ideas about how to approach the people who work with them to create a process that encourages improvement.
• Each person should have concrete examples of approaching review goals in a way that humanizes the process.
• Each person should have an idea on how to facilitate a personal retrospective

Attachments:

• Facilitation Without Unicorns.pdf

Abstract:
Sometimes stumbling in the right direction pays off. The trick is knowing the right direction. Hint: We can't "know".
During this talk I will share a number of experiences and observations. Hopefully we'll also do a few activities along the way.
This is a next step in a series of talks I've given over the last few years:
First was NoEstimates, which questions the pervasive notion that the only sort of decisions worth making require estimates, and suggests that the reality of software development doesn't support that notion. That is, sometimes there are better questions than "how much do we think this will cost?", "when do we think this be done?", and "should we do project A or project B?".
Next was Continuous Discovery which introduces the idea that the nature of software development is not well served by a "here is what we want, here is how we are going to get it" approach. In it I propose that following a process of discovery better matches the endeavour at hand. Whatever we thought we wanted when we started this "project" changes as we expose reality by actually doing something, and any plan we made before we actually did something is counter to what we now need to do.
In this episode, I'm sharing parts of my own path - the things that seem important to the "Drunkards Walk" that I've been on. To be clear: I'll share my experiences in support of the idea that opening oneself to chance and serendipity might be worthwhile, or at least not completely stupid. Is this a leadership technique? Perhaps. Clearly, the more people stumbling behind you in the same general direction the more it looks like you are a leader. But I'm not suggesting you do the things I did, as you can likely guess, and I'm certain that when we copy the things a successful "leader" has done we are are likely doing the exact opposite from what that leader did.
NOTE: This is a bit related to the ideas in the book "The Drunkard's Walk: How Randomness Rules our Lives" by Leonard Mlodinow, but not very much after all I suppose.

Learning Outcomes:

• I can't imagine what you might learn, or take away from this presentation
• I can't presume that anything I have to say or share will be of use to you, but I hope it will be
• "The value of another’s experience is to give us hope, not to tell us how or whether to proceed" - Peter Block

Attachments:

• ZeroToSixtySlidesHandout.pdf

Abstract:
The modern organization is at war with complexity. The code for a typical webpage is the size of a typical video game from the 1990s. "Standards are great, there's so many to choose from." Projects have multiple stakeholders and ever-changing, conflicting Priority One features. Despite gains from Agile methods, the multi-person development arena is typified by volatility, uncertainty, ambiguity, and complexity — what the U.S. military calls "the fog of war."
Derek W. Wade’s background in Cognitive Science has shown him that humans have innate skills at managing this complexity. But too often, he sees leaders waste precious human capital because they don’t understand how these skills work. Over the last 6 years, Derek has explored Team Science — which evolved from studying aviation, clinical, and military teams — for practical insights into how people work best together. If you want to help your teams cut through the “fog” and have fun doing it, Derek will use mini-games and stories to introduce you to these insights and how to apply them. Leave armed with knowledge of mental models, cognitive load, situational awareness, and boundary objects so your teams can use complexity to their advantage, solve the right problems, support each other, and finally use those whiteboards, stickies, and online tools properly.

Learning Outcomes:

• Attendees will be better prepared to lead teams in emergent, complex domains (such as software development) by learning:
• 1. Our ability to solve problems depends on our ability to internally model the world around us;
• 2. Cognitive limits of this ability, and examples of work practices which respect (and ignore) those limits;
• 3. Refactoring team communication: multi-person use of models vs. mere transmission of information;
• 4. Leadership stances which foster effective mental models at the multi-person, multi-team level;
• 5. Explicitly managing meta-information about the organization/team. Product goals, objectives, and tasks are only half of the work in knowledge-work.

Attachments:

• DerekWWade_WideMind_Lecture_75m handout.key.pdf

Abstract:
"They are resisting." "This shouldn't take so long." "We must hold them accountable to new behaviors." These are complaints I have heard from people working on Agile transformations.
It is true that change often happens more slowly than we'd like. Most organizations have built up processes, organizational structures, and formal and informal incentives that are designed for stability, not flexibility and change. Training and coaching won't overcome this organizational gravity. Sanctions and other forms of pushing also don't help, and certainly aren't truly leadership.
What does work is Change Artistry--skills and judgement to know when and what to nudge to lessen the tug of gravity and allow new practices to take hold. When it comes to leading organizational change, these are my Change Artist Super Powers: Curiosity, Observation, and Experimentation.
In this session, I'll explore the power of curious questions to reveal dynamics, interactions, and habits that hold the current pattern in place. I'll discuss the how and what of observation, and how to make sense of what you see. I'll share a template for experimentation--micro changes--that will help you lead the way to big changes.

Learning Outcomes:

• Pushing inspires push back.
• Leading change with curiosity, observation, and experimentation helps you and others to see additional options for action.
• How to pique your own curiosity, and ask questions that will reveal the dynamics of the current pattern.
• How and what to observe, and how to make sense of your observations
• A simple template for organizational experiments

Attachments:

• SuperPowersAgile2017.pdf

Abstract:
Self-organization is one of the fundamental aspects of agile organizations. Yet it is a challenge and there are lots of myths around it.
Some people say: "With self-organization, I lose control totally". Others are happy as they think "Wow! This means I can all do it my way". 
The truth is - of course - somewhere in the middle: self-organization is still a form of organization. That means, that all essential problems, that organizations need to cope with, need to be also coped with in organizational eco-systems that are stronger based on self-organization.

But how? And to what extent? And how to achieve a good balance between the essential organizational needs of alignment and autonomy.
In this talk we will look at self-organization from different angles. Based on my 20 years of SW development leadership experience at Ericsson, one of the world's largest SW companies with more than 20,000 Developers, I will share what we have discussed, experimented and learned in this area.

Learning Outcomes:

• See organization and self-organization from different perspectives
• Understand the challange of balancing alignment and autonomy
• Hear about real-world examples of how this challenge can be mastered
• Inspiration on things you can try in your own organization.

Attachments:

• MasteringSelfOrganization_PubFinal.pdf

Abstract:
75 years ago, the challenges of combat in the South Pacific were exceeding the U.S. Navy’s decision-making capabilities. Ship captains were overwhelmed with data from radars, radios and other sources. They could not make sense of their work fast enough. Today, many of us are faced with the same challenge: we have too much data and too little actionable information.
The U.S Navy’s revolutionary solution was the Combat Information Center (CIC). It distributed the cognitive load using visual tools, created a clear model of the work, and enabled faster decision-making. Effective Kanban systems accomplish the same goal, reducing our individual cognitive load while simultaneously enabling more effective decision-making across the system. I’ll describe this history, define how distributed cognition works, and give you specific ideas for how to accelerate effective decisions with your Kanban system.
Outline:

• Introduction of Concepts: Kanban & Distributed Cognition
• The U.S. Navy's Situation
  • Challenges after Pearl Harbor
  • The Need to Fight at Night
  • Limitations of Early Radar Systems
  • The Solution: the Combat Information Center (CIC)
  • Why the CIC Worked and How it Relates to Our Situation Today
• Distributed Cognition
  • What is it?
  • What are the Essential Components of it?
  • What Benefits does it Provide?
• Kanban
  • What is Kanban?
  • What is the Kanban Method?
• How does Kanban Enabled Distributed Cognition
  • Example: Kanban Dinner Planning
  • Making Policies Explicit
  • Creating a Pull System
  • Visualization
  • Work In Progress Limits
  • Classes of Service
  • Capacity Allocation
• Summary
  • How can this Help You?
  • What can You do Tomorrow?

Learning Outcomes:

• Better understanding of how to move beyond visualizing work and towards creating a shared system of knowledge that is more than the sum of the whole.

Attachments:

• Agile2017 - Distributed Cognition - Trent Hone.pdf

Abstract:
Agile Leadership is a broadly-defined buzz-word today. Does it just mean servant leadership or is there more? How does Agile leadership fit with "Agile" Management. While the industry is figuring out all this, at Riot Games, we didn't really care about terminology and definitions, but rather our focus is on building strong human-centric leaders to lead our 2500-person agile organization. Through these efforts, I think we have created our own understanding of what Leadership in an Agile organization looks like that is worth sharing.
 
In this talk, Ahmed will share his reflections on the domain of Agile Leadership in general and share the frameworks and current ways of thinking about leadership at Riot Games. He will highlight some areas where he disagrees with common agile rhetoric like "having single wringable necks" and using "commanding" stances. He will introduce a new leadership roles & responsibilities framework that provides teams a way to balance between team-level autonomy, organizational-wide alignment and strong accountability. 

Learning Outcomes:

• Participants will be able to reflect if they have an appropriate agile leadership model for their environment
• Participants will be able to distinguish between leadership accountability and responsibility in an agile environment
• Participants will be exposed to a creative leadership model that was rolled out at Riot Games - showing participants - "the art of the possible".
• Most importantly participants will leave be able really think what Agile leadership may mean for them personally - on their personal journey.

Attachments:

• AgileLeadershipRoles.pdf