The Soul of Agile: 16 Elements of Responsible Development
A few years ago, I received a call from a very frustrated VP of Development in the midwest. He sent his staff to get trained in Scrum. He thought he was sending his team off to learn how to develop software. Instead, they came back scrumbroken.
The team spun in circles arguing about their stand up meetings, trying to wrap their heads around the arcane notion of Fibonacci based pseudo-planning, how best to set fire to their documentation, and so on.
None of them came back ready to jump into work. They had to deploy all the processes and tools, there was no time for individuals or how they might interact.
“They are all arguing about what agile is. It’s like they all went to different classes.” His pain was evident over the phone. “Is it possible for you to come in and kind of teach them how to actually work? Or maybe what agile is?”
In this video, I discuss the sixteen points I sent him in the memo below. These, for me, are 16 Elements of the Soul of Agile. Yes, you can come up with others. If you do, that’s good! Keep doing that. This list is not the end of the conversation.
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.
The Series: Intro | Who is Agile For? | The Soul of Agile | What Agile is Not
Jim Benson is the creator and co-author of Personal Kanban. His other books include Why Limit WIP, Why Plans Fail, and Beyond Agile. He is a winner of the Shingo Award for Excellence in Lean Thinking and the Brickell Key Award. He teaches online at Modus Institute and consults regularly, helping clients in all verticals create working system. He regularly keynotes Agile and Lean conferences, focusing on the future of work.
