Agility: Heuristics for Effective Software Development Organizations. (Jan 19–20)
2 half-day remote seminar.
Jan 19–20, 2023
In this seminar, you’ll learn how to leverage Allen Holub’s Heuristics to create a highly effective (software or other) product or service organization. This is a limited-size class with lots of discussion (and no slides).
12 slots remaining
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).
The best outline of this course is the heuristics themselves (You can also find them at here). We will discuss all of the following:
- 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 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 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.).
- 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, sit down with the teams and help them.
- 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.
- 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.
- 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.
Hands-on workshop. Jan 19–20, 8AM-12PM US-Pacific time (San Francisco/Los Angeles).
Time converter at worldtimebuddy.com
This is an interactive seminar. In-house presentations require a full day. Remote presentations can be done in a single day, or we can split the class into two 3-hour sessions on two consecutive days. The public remote class is presented at:
|8AM–2PM||Pacific Time (US)|
|11AM–5PM||Eastern Time (US)|
We may go overtime. Class is taught in English. We require cameras on, and please use a headset or a good-quality microphone. We will email additional details to you a few days before class.
Once the COVID situation allows, we will be happy to present this class in-house as full-day sessions. All in-house attendees must provide proof of vaccination and follow CDC masking guidelines. Please contact Allen (email@example.com) for pricing and other details.
Allen Holub (http://holub.com, @allenholub, firstname.lastname@example.org) is an internationally recognized software architect and consultant/trainer focusing on organizational agility. He speaks all over the planet on these topics and agile-friendly implementation technology like microservices and incremental/evolutionary architecture, but his bread and butter is helping you create or improve highly functional Lean/Agile organizations, and helping you design and build software architectures suitable for agile environments. He provides both in-house training and consulting services. Allen started his career as a hardware engineer, but after being pressed into writing a compiler and real-time operating system for the robot his team was building, ended up a developer. He's helped with many commercial applications, web based and otherwise, and has served twice as a CTO for early-stage startups.
Allen is widely published (10 books, many hundreds of articles both in print and online) and was a Contributing Editor at both Dr. Dobb's Journal and JavaWorld. His many video classes have been published by Pluralsight (Swift in Depth, Picturing Architecture, Object-Oriented Design), LinkedIn Learning (Architecture Fundamentals, and Domain-Driven Design), and O’Reilly (Design Patterns in the Real World). Allen taught for the University of California, Berkeley, Extension for many years, and is the current Chan-Norris Distinguished Professor of Computer Science at Mills College.
If you'd like to bring Allen in house for keynotes, consulting, or training work, set up a chat to discuss your needs.