Agile has always been considered an "IT thing”.

That’s not surprising, since it is the “Manifesto for Agile Software Development” after all. Because of this, the vast majority of transformations and the drivers of those efforts have been heavily driven from IT.

However, from the beginning, one could argue the intent of Agile was to achieve better business outcomes, through collaboration and adaptability, among other things.

So, it’s no surprise that it has taken the better part of 2 decades to cross over and start becoming a business imperative.

There is a lot of buzz in the market for “business agility”. This is NOT about that. This is about making it clear, from the start, that the only reason to take on an agile transformation, or to continue to invest in one, is to achieve some tangible business outcome. It doesn’t matter what new marketing spin we try to put on it.

If you’re not making Agile an imperative for the business, it will continue to be an “IT thing” and yield marginal benefits for the business.

A common question - "How do we even begin to change our traditional waterfall approach to Agile?" – may invoke responses such as, "we just need training", "create self-organizing teams", "setup a transition team", “SAFe”, etc. But those don’t get to the heart of the question. We need to get leaders to understand the “Why” and the "How" in order to help insure a successful transition and provide the proper support for their teams.

This session directly answers both the “Why?” and "How?" questions, by focusing on 2 key concepts and concrete practices, that leaders/managers need to learn and apply.

To do this, we start by helping them understand the context for agility and equipping them with new "agile glasses" that change the way they see and think about Agile. We equip them with 2 new "lenses" through which they can:

1. Visualize the problem domain(s) that exist in their environment and understand the relative level of complexity and uncertainty represented in their projects or product delivery efforts, using the Cynefin framework and VUCA modeling. Understanding these can help to provide better context for decision-making and mitigate the risk of taking a "one size fits all" approach to product or project delivery.
2. Visualize a multi-dimensional planning model, often referred to as the "5 Levels of Planning", that breaks the pattern of big up-front planning and wasteful change control processes, common to waterfall, by reinforcing the practice of continuous planning. This centers on getting them comfortable with key techniques associated with an adaptive approach, rather than a predictive approach to planning.

Many leaders view Agile as simply something that their teams need to learn and/or something that training alone will solve. The reality is that most agile initiatives fail due to a lack of leadership engagement (connection) because leaders aren't given the knowledge or tools to help them adapt.

If this describes you or your managers/leaders, then this session will help answer the question of “how do we get started…?”

Let’s face it, Metrics are a staple of virtually every organization.

The intent behind Metrics is to improve. A very Agile idea indeed. Unfortunately, rampant misuse tends to create more waste than value. Teams often don't understand or believe in them. Managers often misinterpret them or never really use them. NOT a very Agile idea.

We can change this. It's not just a Fairy Tale.

We can empower teams to take ownership of their data, including defining what data really helps them improve. We can educate management to better understand what to ask for and how to properly interpret the data. Thus, turning Vanity metrics into Valuable metrics, that can be used for good, not for evil.

It starts by having an open conversation with genuine curiosity about what really matters and asking, "Is the data a real reflection of the truth?", "Can you consistently reproduce the same results (good or bad)?" and "What decisions can we make, or actions we can take, based on these metrics?"

This workshop will explore these and other questions as well as provide a way to apply a well-known model to test for 'vanity'.

STATIK (Systems Thinking Approach To Introducing Kanban) can be a great way to help Scrum teams get up and running quickly. “Heresy!” you say.
But it doesn’t have to be just one or the other, a blue pill or red pill choice.

This is not the same thing as “Scrum-ban”.
This is “Start with what you do, or know, now” in order to help avoid over-thinking how existing work, structures and/or roles “fit” within Scrum.
Specifically, applying this approach designed for Kanban can dramatically accelerate the forming and improvements of a Scrum team.

This session will provide an understanding of STATIK and how to apply it effectively as part of a Team Chartering workshop for new or existing Scrum teams. We have used this approach to help teams Form and establish Norms for them to work toward, including how they will norm around Scrum. Participants will learn how to apply this approach to help remove some of the frustration and confusion often experienced by teams as they learn to apply Scrum consistently.

… and tomorrow "you will wake up in your bed and believe whatever you want to believe."

STATIK (Systems Thinking Approach To Introducing Kanban) can be a great way to help Scrum teams get up and running quickly. “Heresy!” you say.
But it doesn’t have to be just one or the other, a blue pill or red pill decision.

This is not the same thing as “Scrum-ban”.
This is “Start with what you do now” in order to help avoid over-thinking how existing work, structures and/or roles “fit” into Scrum.
Specifically, applying this approach designed for Kanban can dramatically accelerate the forming and improvements of a Scrum team.

This session will provide an understanding of STATIK and how to apply it effectively as part of a new Team Chartering workshop for a new Scrum team. We have used this approach to help teams Form and establish Norms for them to work toward, including how they will norm around Scrum.

… and tomorrow "you will wake up in your bed and believe whatever you want to believe."

Let’s face it, Metrics are a staple of virtually every IT organization.

Unfortunately, they are often poorly understood and horribly misused.

But what are Metrics anyway? It’s just Data, right? Specifically, it’s empirical data. Learning from, and basing our decision-making on, empirical data is a good thing.

The intent behind Metrics is to improve. A very Agile idea indeed. Ironically, rampant misuse tends to create more waste than value. Teams often don't understand or believe in them. Managers often misinterpret them or never really use them. NOT a very Agile idea.

We can change this. It's not just a Fairy Tale.

We can empower teams to take ownership of their data, including defining what data really helps them improve. We can educate management to better understand what to ask for and how to properly interpret the data. Thus, turning Vanity metrics into Valuable metrics, that can be used for good, not for evil.

It starts by having an open conversation with genuine curiosity about what really matters and asking, "Is the data a real reflection of the truth?", "Can you consistently reproduce the same results (good or bad)?" and "What decisions can we make, or actions we can take, based on these metrics?" This workshop will explore these and other questions as well as provide a way to apply a well-known model to test for 'vanity'.