Teams are self-organizing. That is not a statement of preference or intention; rather, it is a statement of objective fact.

Agile practices, like Scrum, XP, OpenSpace Agility, and liberating structures are among a very small number of management frameworks which acknowledge that self-organization is natural. The Manifesto for Software Development asserts that the quality of decisions and the value of outcomes increase when stakeholders collaborate with and trust the wisdom of their teams.

The opposite is also true: the manifesto implies that the common misbehaviours of managers (intervention, command & control) have costly consequences.

We will examine self-organization in teams and explore examples of self-organization in the workplace. Strong opinions are welcome.

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 dangerous tendency toward exhaustive documentation is 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.

Without Taylorism, we would not have the Agile Manifesto. Let's examine the conditions in which the Agile movement formed and why it has earned so much momentum.

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.

• Note cards and stickies? Everybody scoffs at them!
• Jira? Evil!
• Trello? Sucks!
• Pivotal, Rally, Blossom, Asana, Basecamp, Sprintly? Argh!

The problem with every tool is actually simple: they solve for someone else's problems...not yours. Few aspects of the modern workplace receive as much attention and create as much controversy. Let's explore how "Agile Tools" impact our work.

Products are not Projects — simple.

A project is:

"a set of interrelated tasks to be executed over a fixed period and within certain cost and other limitations."
"What is a project? definition and meaning". BusinessDictionary.com. Retrieved 2016-04-19.

Product development cannot be constrained to "certain cost" and products do not have a prescribed end date...so no "fixed period". So long as the organization finds innovative ways to meet market demands, the products they develop will evolve.

So, why all the projects?

I teach Scrum — it's a process framework that has been used to manage complex product development. Yet:

• ~55% of the people in my classes are "Project Managers"
• ~90% work daily in "project teams" (sic)
• and ~0% are ready to let go of Project Charters!?

Project charters in a complex problem domain create an illusion of safety, certainty, and confidence, but are wholly inappropriate in most organizations represented at this conference for one simple reason: the nature of our work is complex and therefore it is not possible to predict a "set of interrelated tasks to be executed over a fixed period and within certain cost and other limitations".