Agility: Heuristics for Effective Software Development Organizations. (July 11–12)

Allen Holub’s list of Heuristics for Effective Software Development Organizations describes 26 rules of
thumb for creating highly-effective organizations. They were originally intended to apply to software development,
but it turns out that they are much more general, applying
to many organizations across the board (thus the strikethrough).
These heuristics are at the core of agility (not Agile™), a characteristic that everybody needs to succeed in today’s rapidly changing business climate.

In this interactive seminar, you’ll learn how to build a nimble organization, easily able to accommodate change and create great products. You don’t do that by implementing some framework. You don’t do that with rigid rules, processes, and tools imposed by management. Instead, you use a set of values, principles, and practices to release the potential of your organization and develop processes that work for you. This class gives you a leg up and prevents lots of expensive flailing around on your path to agility.

Your entire organization, particularly upper management, will benefit from this seminar, and it is a seminar, not a lecture. No slides, though we’ll use a virtual whiteboard. Just valuable discussion. There will be plenty of time to ask questions and get answers. Real agility questions many assumptions that people make about how companies are supposed to work, so be prepared to be challenged. The class size is limited to make those discussions possible.
(We can present the concepts to a larger group—even the entire company, but it’s more valuable when we can interact).

Outline

The best outline of this course is the heuristics themselves (You can also find them at here). We will use these as catalysts for discussion, not bullet points. For example, topics like how slack time makes you faster and how backlogs are a bad idea stem naturally from these guidelines.

1. Without psychological safety, respect, and trust, none of the following is possible.
2. 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.
3. Process exists in service of people; the people come first. Processes not developed by the people who use them rarely work well, if at all.
4. 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.
5. Welcome change—in organizations, processes, products, plans—at any time. You cannot be simultaneously rigid and agile.
6. Outcomes matter more than output. A focus on output yields sub-par outcomes.
7. Knowledge work has unique concerns, unrelated to those of a factory or construction site.
8. 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.
9. 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.
10. 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.
11. Work is transient. We expect to change, or even discard, everything we build, from products to organizations and processes. Everything is an experiment.
12. 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.
13. We think holistically. We work on complete products, not projects. If you have no projects,
    you have no need for project management.

14. At the core of our way of working is continuous and rapid feedback. We make a small change, deliver the result into our customer’s hands, get feedback, 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, &c.).
15. Quality is not negotiable. (This rule applies to all aspects of quality, not just testing.)
16. The best plans are strategic, not tactical.
17. Predictions are unreliable. Estimates are not promises.
18. Our only measure of progress is delivering into our customers’ hands things they find valuable. It’s okay if they change their minds.
19. 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, sit down with the teams and help them.
20. 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.
21. 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.
22. 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.
23. Teams that depend on other teams cannot respond fast enough, so team members have between them all skills needed to get an idea into our customers’ hands. Skills overlap, so no single person is essential.
24. People must start every day refreshed, relaxed, and able to do their best work (and stop when those conditions no longer hold).
25. Relatedness, autonomy, mastery, and purpose are essential drivers. Rewards and punishments are actively destructive.
26. 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.
27. 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.

Details

Hands-on workshop. July 11–12, 8AM-11PM US-Pacific time (San Francisco/Los Angeles).

Time converter at worldtimebuddy.com

Your Instructor