We like to say that agile teams own their own process by choosing their way of working, their “WoW.” This of course is easier said than done because there are several aspects to WoW. First, our team needs to know how to choose the appropriate lifecycle for the situation that we face. Should we take a Scrum-based approach, a lean/Kanban-based approach, a continuous delivery approach, or an exploratory/lean startup approach? Second, what practices should the team adopt? How do they fit together? When should we apply them? Third, what artifacts should the team create? When should they be created? To what level of detail? Finally, how do we evolve our WoW as we experiment and learn?

There are several strategies that we could choose to follow when we tailor and evolve our WoW. One approach is to bootstrap our WoW, to figure it out on our own. This works, but it is a very slow and expensive strategy in practice. Another approach is to hire an agile coach, but sadly in practice the majority of coaches seem to be like professors who are only a chapter or two ahead of their students. Or we could take a more disciplined, streamlined approach and leverage the experiences of the thousands of teams who have already struggled through the very issues that our team currently faces. In this talk you’ll discover how to develop your WoW without starting from scratch and without having to rely on the limited experience and knowledge of “agile coaches.”

Shared understanding is a pre-requisite to success for any agile teams. Many Agile teams rely on User Stories to help them get consensus on what to deliver, and what done looks like. Stories are a great practice for agile teams, but as the complexity of the problem or solution they are building increases, they often need more. Agile teams can face serious churn in the story writing process as complexity increase. Different team members can have completely different understandings of the meaning of key business and solution concepts. Often the same concepts end up being discussed over and over again, significantly slowing down story exploration. Even worse, different stakeholders end up having ambiguous and even conflicting understanding of the solution.

During this session, we will discuss how we have integrated story exploration practices such as Story Mapping, Story Grooming, and Spec by Example, with the Domain Driven Design method, with the goal to promote the creation of a ubiquitous language and share understanding of both the solution and business domain. We will show how various teams have leveraged light weight, informal tools to enable both technical and non technical stakeholders to execute in a highly aligned way, and dramatically decrease churn and rework as a result.

A key part of this session will be taking the audience through an integrated example that show cases how one can elaborate on an idea through progressive refinement of Stories and CRC Card based domain driven models in parallel. We will showcase how Story Maps can be refined through creation of an initial Domain Driven Model expressed through Class Responsibility Cards. We will illustrate how to connect story grooming and refinement of domain models in order to create a precise business and solution language. We will illustrate how domain model walkthroughs can be used to battle test your stories against your domain model, validating key assumptions before coding starts. We will also showcase how both story grooming and domain driven design can be done directly in code, and how this approach dovetails perfectly into test driven development.

Wave 2 of Agile is a way to understand the high-performance results that come from Being Agile. We know many in our industry have fallen into the trap or “Doing Agile” – where people lose sight of the objectives and lasting results.

Wave 2 is about Living Agile. It is how we show up. It is how we work with people and organizations to shape the Culture. It is living Mahatma Gandhi's truth:

“Be the change that you want to see in the world”.

When we focus on our own behaviour, we model Being Agile. This is the only way to invite the Agile Mindset. This is Wave 2 Agile. We stop creating conflict and resistance. We become the effective leaders and influencers of lasting change in our organizations.

“To be or not to be? That is the question.”

Myth: "Agile teams don't document."
Truth: Some of the best documentation we've ever seen comes from Agile teams.

Agile Engineering practices have revolutionized the ways in which documentation is treated and produced. In high-stakes environments with heavy compliance and audit requirements, a tendency toward exhaustive documentation is dangerously common. This workshop provides direct guidance and simple tools to help a document-heavy workplace think differently about documentation.

I have developed this workshop to help an organization reframe their understanding of documentation with respect to knowledge work in complex environments so that they may eliminate unnecessary artifacts and simplify/automate others.