Without psychological safety, respect, and trust, none of the following is possible.
The way we work, the work we do, and the organizations within which we work are all part of a connected system. You cannot change anything without changing everything. You cannot improve a system by tinkering with the parts.
Process exists in the service of people; the people come first. Processes not developed by the people who use them rarely work well, if at all.
The best ways to work are collaborative. Negotiation is not collaboration. Isolated individuals making heroic efforts are never as effective as collaborative groups. We get the best results when customers, business people, and developers literally work together.
Welcome change—in organizations, processes, products, plans—at any time. You cannot be simultaneously rigid and agile.
Outcomes matter more than output. A focus on output yields sub-par outcomes.
Knowledge work has unique concerns, unrelated to those of a factory or construction site.
The most effective organizations are learning organizations. Learning—about both the products we produce and the way we produce them—is continuous. Learning is not just a normal work activity, it is the work.
We continuously improve by observing how we work and fixing any problems we encounter. Improvement is an ongoing, not a periodic, activity. When something goes wrong, we pause and figure out a way to improve our process so the problem can’t happen again. We focus on the system, not the people. Occasionally, we’ll stop and reflect on our work to make proactive improvements.
Simplicity is essential. This rule applies to everything from organizational structure and process to the fine details of the products we develop. We do not waste time building (products or organizations or details) for a future we cannot predict.
Work is transient. We expect to change, or even discard, everything we build, from products to organizations and processes. Everything is an experiment.
We work to make our customers’ lives better and their work easier. We do that by providing a steady stream of artifacts and aid that they find valuable. Our user/customers “drive” that process, but that means that you communicate often, watch them work, understand their problems, and collaborate on solutions. It doesn’t mean that you mindlessly do what you’re told.
We think holistically. We work on complete products, not projects. If you have no projects, you have no need for project management.
At the core of our way of working is continuous and rapid feedback. We make a small change, deliver the result into our customers’ hands, get feedback, and then adjust what we do based on that feedback. That cycle is as short as possible—minutes, hours, occasionally a few days—not weeks. This inspect-and-adapt loop applies to both process improvement and product development. The changes we deliver are high quality (e.g. in code: no known defects, production-ready, secure, etc.).
Quality is not negotiable. (This rule applies to all aspects of quality, not just testing.)
The best plans are strategic, not tactical.
Predictions are unreliable. Estimates are not promises.
Our only measure of progress is delivering into our customers’ hands things they find valuable. It’s okay if they change their minds.
Management provides strategic guidance and support only. Tell the teams what you need, and trust them to figure out how to execute. Do not collect data and make decisions. Instead, sit down with the teams and help them make decisions.
Give people the environment and support they need, then get out of the way. We trust autonomous teams to control the way they work and the environment they work in. Teams are self-organizing and self-managing. They choose their own tools and methods. We expect them to change both the product and themselves as they deem necessary. If all the teams are working in the same way—using the same process or framework, for example—you have no autonomy.
Autonomy does not mean that the teams do not coordinate with one another and with the larger organization. Alignment around everything from strategic goals to implementation technology is essential.
The best teams are stable, but self-selecting. Bring work to the teams; do not form teams to do the work. Fund the teams, not the work. Teams recreate themselves as necessary.
In seeming (but not really) contraposition to the last point, teams and people can move to meet demand. Flexibility is required.
Teams that depend on other teams cannot respond fast enough, so team members have, between them, all the skills needed to get an idea into our customers’ hands. Skills overlap, so no single person is essential.
People must start every day refreshed, relaxed, and able to do their best work (and stop when those conditions no longer hold).
Relatedness, autonomy, mastery, and purpose are essential drivers. Rewards and punishments are actively destructive.
Communication is central to effective outcomes. Communication effectiveness improves with the degree of physical proximity and the richness of the communication media. Face-to-face in real time is best, though not always possible, so we sometimes approximate that as best we can.
Much of the dysfunction in management comes from fear, which in turn comes from a lack of transparency. Our processes must be as transparent as possible.
*This list is hardly original thinking on my part. It started out as a way to present the values and principles of the Agile Manifesto in a clearer and more contemporary way, though I’ve added a few things. It represents a snapshot of my thinking in a moment in time, not a set of irrefutable truths.
[This post was originally on holub.com/blog, but I’m gradually copying stuff over here.]
Interested in a private, custom talk or full-on class for your organization? Contact me! I still have some slots open in the current quarter. Email me at allen@holub.com, or:
Ariel, That's a big topic, but consider a bonus based on an individual performance appraisal. That's a zero-sum game, since the bonus pool is of fixed size. That means that people will compete against each other for the money. That, in turn, leads to not helping people so that you can be the "hero," not sharing your knowledge because it would make somebody else look good, and other negative consequences.
Punishments are the opposite of this. If you punish "underperformers," they are probably "underperforming" because they're not getting help from "seniors" for whom they're competing for bonuses. That means that they'll never get better, and they'll drag the whole team down with them.
Also, 22. By far the most misunderstood idea. If your team needs some SEO help, either learn SEO or grab an SEO expert. I’ve seen people use this as an excuse to not build stable product teams. Who wants to go to the “testing team” to get help thinking through quality?