Software is eating the world. Or so they say…. Everyone wants software results but not everyone gets them. Digital transformation, continuously devops microservices, a constant parade of buzzwords with the promise to help. Why does an organization using the same methods and tools get drastically different results from another similar organization? Why is software so hard? Is software hard? Are we really getting better at software? What does better look like? How would we know? A mix of anecdotes and research will shed light on these serious questions.

As more companies seek the benefits of Agile within and beyond IT, Agile Leaders need to build and sustain capability while scaling agility – no easy task – and they need to succeed without introducing unnecessary process and overhead.

The Agile Performance Holarchy is an empirical model for Agile leaders that provides guidance for scaling and sustaining agility and capability throughout a modern technology organization.  The APH is drawn from lessons learned while observing and assessing hundreds of agile companies and teams.  It is not a process or a hierarchy, but a “Holarchy,” centered around a series of Performance Circles with embedded “holons” that reflect the behaviors of high performing Agile organizations.  The Agile Performance Holarchy provides implementation guidance in the areas of Leadership, Values, Teaming, Visioning, Governing, Building, Supporting, and Engaging within an all-Agile organization.

So they say the retrospective is one of the strongest and most powerful tools in the agile scrum methodology tool kit, and is often overlooked or skipped. So how does a scrum master find ways to creatively explain and express the importance of this agile scrum ceremony, or even the basics of agile scrum in general. How does the scrum master explain the importance of banding together as a team in this brave new agile scrum world. In many organizations, nowadays, the teams are even made up of outside vendors as well as in house associates. So how do you even start to pique the interest and the importance of team collaboration to a bunch of folks who are strangers to one another on a agile scrum team? Even more specifically, how do you explain how the retrospective ceremony will help improve the way they work with one another over time?

My answer: ZOMBIES!!! Everyone loves zombies, right? So come, take a bite!

I will be hosting two 45-minute Lean Coffee collaborative conversations at AgileDC this year. One session will take place in the morning; the other in the afternoon.

What is Lean Coffee?

Lean Coffee is a type of discussion for the people, by the people. Participants gather, build an agenda together, and begin talking. It is sometimes called a structured, but agenda-less meeting.

1. We will identify what we want to talk about
2. We will vote & discuss
3. We will identify key findings/ideas/takeaways

Why do it?

It's a great technique to learn when you want to spark some engaged -- yet casual, collaborative conversations around topics that are of interest to the group. You can use the Lean Coffee format within your department, across departments, as a brainstorming platform or for team retrospectives. There are many different possible applications.

What will we discuss?

For the AgileDC sessions, our conversation topics will be determined by you! Our theme will be pretty broad. You've probably guessed it...Agile!

When you come to Lean Coffee, please be prepared to write down at least 1-2 topics in the form of a question.

Examples:

• "My organization struggles with ____. How do we take some steps to get better at this?"
• "Here's what we're doing in regards to ____, what are you doing?
• "What metrics do you actually use?"
• "How big are your agile teams?"
• "We've got some basic processes in place, but what's next?"

When you take Lean Coffee back to your organization, the theme of each session could be a real democratic set of agile topics making for truly spontaneous networking/collaborative/experiential learning and participation opportunities, or you can announce a theme in advance and attendees will be asked to focus their topic ideas around that specific theme.

I hope you will join me at AgileDC for a Lean Coffee conversation!

I will be hosting two 45-minute Lean Coffee collaborative conversations at AgileDC this year. One session will take place in the morning; the other in the afternoon.

What is Lean Coffee?

Lean Coffee is a type of discussion for the people, by the people. Participants gather, build an agenda together, and begin talking. It is sometimes called a structured, but agenda-less meeting.

1. We will identify what we want to talk about
2. We will vote & discuss
3. We will identify key findings/ideas/takeaways

Why do it?

It's a great technique to learn when you want to spark some engaged -- yet casual, collaborative conversations around topics that are of interest to the group. You can use the Lean Coffee format within your department, across departments, as a brainstorming platform or for team retrospectives. There are many different possible applications.

What will we discuss?

For the AgileDC sessions, our conversation topics will be determined by you! Our theme will be pretty broad. You've probably guessed it...Agile!

When you come to Lean Coffee, please be prepared to write down at least 1-2 topics in the form of a question.

Examples:

• "My organization struggles with ____. How do we take some steps to get better at this?"
• "Here's what we're doing in regards to ____, what are you doing?
• "What metrics do you actually use?"
• "How big are your agile teams?"
• "We've got some basic processes in place, but what's next?"

When you take Lean Coffee back to your organization, the theme of each session could be a real democratic set of agile topics making for truly spontaneous networking/collaborative/experiential learning and participation opportunities, or you can announce a theme in advance and attendees will be asked to focus their topic ideas around that specific theme.

I hope you will join me at AgileDC for a Lean Coffee conversation!

In software development, we’re trying to meet the given “requirements.” I prefer to call these “desirements,” because they what we want, not necessarily what’s required. And who wants them? We do better when we pay attention to the needs of everyone involved, both those using the system, those paying for it, and those building it. We may not get everything we want, but we can get what we need.

The Modern Agile Principles proposed by Josh Kerievsky focuses on outcomes rather than particular practices.

Most experienced Agilists understand that you might start with practices but only as a means to an end. In the same way that practicing scales is a place to start for a musician but not the ultimate goal. The real end is business agility. During this interactive session we will explore the four principles, the value of those outcomes and how you might achieve those outcomes without defined practices on your team.

Not every continuous delivery initiative starts with someone saying "drop everything. Let's do DevOps." Sometimes you have grow your practice incrementally. And sometimes, you don’t set out to grow a practice at all-- you are just fixing problems with your process, trying to make things better.

I'll walk through a case study of how our team worked on an exemplar project for the Department of Defense to show that agile could work in a decidedly waterfall culture. I’ll also discuss techniques and tools we used to bring a DevOps mindset and continuous delivery practices into an environment that wasn't already Agile.

I'll talk about how we were able to start in development, where we had the most control, with a "let's starting being Agile" initiative and working on "why is continuous integration important?" From there, we tackled one problem after another, each time making the release a little easier and a little less risky. We incrementally brought our practices through other environments until the project was confidently delivering working, QA-tested, security-tested releases that were ready for production every two weeks. I’ll discuss the journey we took and the tools we used to get to build quality into our product, our releases, and our release process.

Developing a delivery pipeline means more than just adding automated deploys to the development cycle. To be successful, tests of all types must be incorporated throughout the process in order to be sure that problems aren’t slipping through. Most pipelines include unit tests, functional tests, and acceptance tests, but those aren’t always enough. I’ll present some types of testing you might not have considered, or at least might not have considered the importance of. Some types will address code quality, others code security, and some the health and security of the pipeline itself.

I’ll talk about specific tools we used to supplement our pipeline testing. I won’t get into how to use each tool-- this is more of a series of teasers to encourage people to look into the tools, and even letting them know what types of tools and testing opportunities are out there.

Product owners face a challenge: potential new markets are vast and full of unknowns. Current thinking in successful product management recognizes the importance of learning about potential customers
and adapting product decisions to reflect those insights. However, many exercises and workshops
geared towards product owners treat target products and markets as a fixed, concrete objective—failing to include any market feedback

Dicey Markets is a product owner simulation designed to reflect many of the forces driving product owners, including unknown information about the market, competitive pressure, and technical debt. The simulation
emphasizes the role of rapid regular feedback in creating successful products in the face of uncertain markets.

As organizations try to become more Agile, they face many tricky questions. How to best organize teams? How big should they be? How similar should they be? This talk looks at the world of biology for metaphors that can inform how we approach creating and sustaining successful Agile organizations.

Adopting Agile and DevOps principles and practices frequently leads enterprises down a path to significant cultural and organizational change. This creates a real barrier for leaders, coaches, and change agents to overcome. Many researchers, sparked by John Kotter’s claim of a 70% failure rate for organizational change have confirmed through scientific study that these types of transformative efforts are more likely to fail than to succeed. Fortunately, all is not lost! Scholar practitioners have also uncovered a powerful tool that consistently increases the success rate of significant organizational change. The secret weapon is leadership… but not just any style of leadership…

In this session, Dr. Steve Mayner will share the potential power of transformational leadership behaviors to drive successful organizational change. His primary research was the first to explore the correlation between this specific leadership style and positive response to change in Agile/DevOps implementations. How enterprise leaders cast vision, encourage individual growth, demonstrate authenticity, and challenge followers to maximize their creative potential can have a greater influence on the success of an Agile/DevOps implementation than any change management method, methodology, or toolset. Steve will also share examples from his own experiences observing transformational leadership in action, and the results that followed.

Imagine you were hired to provide consulting assistance for a new team just starting out with Kanban. The team has been struggling with their implementation and is looking forward to your expert guidance, support, and advice. It’s your first day and you just walked into the team room to look at their board. You want to make smart observations and thoughtful interpretations so you can have meaningful conversations with the team members. The team starts assembling in the team room for the daily standup and you plan on making some comments afterwards.

What comments would you make? What thoughtful questions would you ask?

This interactive presentation provides a detailed look at how to interpret and thoughtfully observe Kanban Boards to better understand the work of your teams. We will start with an overview of the Lean Kanban Method and then proceed through a series of interactive exercises that give you an opportunity to review and interpret various Kanban boards. The exercises will increase your understanding of Kanban systems and provide opportunities to practice interpreting various board setups so you can have thoughtful and meaningful conversations with your teams.

Are your solutions to recurring issues having only minor improvements? Are some of these solutions actually making things worse in the long run? When answering yes to these, typically, we are trying to solve the issues with too narrow a view. Oddly we think we are addressing it at sufficient level but usually not. In order to see the entire picture we need a common language that will enable us to understand an entire complex adaptive system (e.g. organizations, teams, individuals). Join us as we learn a language called System Modeling (aka. Causal Loop Diagrams).

With this language we will be able to have rich dialogue to gain a full understanding of the entire complex adaptive system so that we can create solutions at the fundamental level and not the symptomatic level. Addressing system issues at the fundamental level will significantly improve the system. Symptomatic solutions may give the appearance of improvement in the short term but typically make things worse in the long run. Unfortunately we usually pick the symptomatic solutions because they seem obvious and we don't realize the long term impacts because of feedback delays that could take weeks, months or even years to realize.

The patterns for implementing Scrum at the team levels have largely been set, but what about dealing with Agile and Scrum across multiple teams. Is the answer just magical words like scaling, or SAFe, or LeSS? What are the core concepts and successful patterns? Is it just one big group hug?

In this session, we will explore core concepts around implementing Agile concepts across multiple teams. The session starts with a simulation that explores distributing people across teams (which will actually NOT involve any hugging). From there, this session dives into:

• Prioritization across multiple teams
• Product Ownership across multiple teams
• Dependencies and team alignment
• Communities of Practice
• Communication and collaboration across teams
• The role of managers
• A quick look at scaling methods

Coming out of this session, attendees will have an understanding of core concepts and fundamental helpful practices in implementing Agile concepts across multiple teams.

For a long time multitasking has been considered a must-have skill when, in fact, it makes us less productive and more prone to error. But even with plenty of studies and papers supporting that idea, it can be hard to convince managers and stakeholders that we should be taking on less at a time. In this lightning talk, we'll run through one very quick, lightweight simulation (Multitasking is Evil) you can use to help make that case and show that lowering work in progress is the way to go!

Our roadmaps and backlogs are usually littered with pet projects, squeaky wheels, and recent ad hoc items that gain priority simply because they are the latest shot across our bow. Impact mapping is a powerful practice that helps us identify and align our work to the most valuable business goals and mission objectives and avoid many of the common challenges that arise from an unfocused set of work priorities.

Impact maps help us visualize quantifiable benefits that deliverables should produce towards our business objectives. They allow us to focus our work on those deliverables that move the needle the most, not just deliver features. The practice is a great way to communicate assumptions, create plans, and align stakeholders as well as aid in strategic planning, roadmap management, and defining measures of success and quality.

This workshop will provide an appreciation for the power of impact mapping by walking you through building your own impact maps and the facilitation process for doing so in your own organization. You will leave the workshop having participated in a tangible example of the technique, and having gained an understanding of best-practices for facilitation with a focus on an impact map’s outputs and how they lead into the creation of actionable user stories when completed. Hands-on collaboration with your fellow attendees will help encourage your own application of this technique in your real world road-mapping and backlog refinement activities.

Description:

I see that a lot of organizations use metrics in inappropriate ways to measure teams. At the heart of these metrics, nine times out of ten, are velocity and story points. These metrics lead to a lot of mistrust, fear, and bad technical practices. This talk will focus on shifting the focus to diagnostic metrics.

 Before shifting focus to diagnostic metrics, we need to understand what inappropriate metrics are. When questioning teams about why their velocity was lower from one sprint to another, teams are more likely to inflate their estimates to avoid questions in the future. This is one of my scenarios. We will explore this case and my other top-ten based on the 165 teams I have interacted with. Focusing on one metric does not provide a balanced view of the team.

For balance, I promote five metrics. The combination of metrics balances each other. These five metrics are lead time, quality, happiness, agile maturity, and business value. Focusing on these five metric areas can be used as a diagnostic tool to help teams grow and support coaching. During the session, we will use my Excel-based tool and visual model to simulate this balance.

When you push shorter lead times (how fast) on a team with a lower agile maturity, the first thing to change is quality, followed by happiness and then the delivery of value. Conversely, if a team focuses on TDD, the first thing to change is quality, followed by agile maturity, reduction in lead time, and increased delivery of value.  

Teaching teams to harness data in a positive way will help them to flourish.