Hey <Name withheld to protect the innocent>,

I’m sorry you went through the machine. Agile should be about people figuring out the best ways for the teams, the customers, and the value to come together and solve problems. Mass trainings, like the one your people went to, tend to focus more on one generic and context-insensitive way of working. Some of the ideas are probably good, but they get lost in the volume and firehose of rapid, commodity training.

Let’s see if we can pick and choose from the lengthy (sorry) menu below and get them focused more on <your company> than on someone idea of how everything should be run.

Agile Reprogramming

Because Agile Isn’t Supposed to Hurt

1 What Agile Is

1.1 Communication

You want to talk more with colleagues and customers. Not every so often. Not through proxies. Direct, real, high value communication.

1.2 Understanding

You want to understand your work. If we don’t understand it, we can’t improve it or even do it. We cannot understand our work if we are overloaded.

1.3 Sustainable Pace

This is a sustainable amount of work, not necessarily iterations. Sustainable work is within our capacity to deliver it. This requires knowing what your capacity is. You cannot know real capacity without measuring it with real metrics.

1.4 Responding to Change

You respond to change in real-time, not in increments. You respond to change by understanding what change actually looks like. Change is when reality does not jibe with expectations. If expectations are not documented or explicitly shared between team members, there is no change — only internal strife as team members lumber along blaming management and each other for the state of product.

1.5 Writing Clean Code

Documentation and readability are important. Working with your team is important. Assuming someone will implement your code and that someone else will maintain it is responsible coding. (Rogue is not agile). Clean code is respect for the craft, the team, and the end product.

1.6 Solving Problems

Solving problems requires real collaboration with people outside your team and outside IT. You might have to talk to real people from time to time. If you solve problems only within your team, you have solved your idea of the problem, but not the problem itself.

1.7 Building Your Own Process

You observe the way your work is produced. You don’t get it from a box. You, your client, your team, your company, your partners, and your product define how you will plan, select work, learn, communicate, and produce.

1.8 Working WITH Your Customer

Seriously, work with them, not for them, not isolated from them, and certainly not against them. Collaborate. Communicate in real time. Let them get builds in real time. Make decisions with them. Break down the silos between the team and the customer.

1.9 Knowable Metrics

Actual statistical measures to help facilitate planning and real-time work selection. This is not only possible, it’s trivial. Without knowable metrics, we cannot effectively plan, communicate, or complete.

1.10 Real time Release

Creating real software is now a real time business.

1.11 Inspect and Adapt

How can we really do this? Not just review and rehash. Not become even more Scrummy. We must know our work, understand our direction, understand the market, understand our team composition, and adjust when we sense imbalance.

1.12 Role Definition

Teams have roles. What are yours? A group of individual contributors is a group, not a team. Your work requires specific processing. That might change over the course of the project, but it does. There is no one set of roles.

1.13 Planning

Plans are documents that force behavior. Planning is awareness. Planning is responsibly steering the project as it progresses and the team learns more about what its best potential for success is.

1.14 Collaboration

DevOps and Pairing are the same thing. We want to form groups with appropriate skill sets to do the best job possible, create robust solutions, and intentionally learn in the process.

1.15 Learning and Feedback

Iterations are a type of loop, but not the only type. Learning and feedback are important. Single, double, triple loop — we want a system that lets us learn and doesn’t overload us so we forget.

1.16 Living in the Real World

We have customers, regulators, and other external actors that influence how we work and what we do. Sometimes these requirements are annoying and inconvenient. We can choose to ignore them, but we may put ourselves or our companies in peril. Dealing with operational imperatives elegantly is agile.