Agility in Modern Organizations
Organizations with high delivery performance spend significantly less time remediating issues.
Bureaucracies are no match for complexity. They can’t handle the surprises we face every day, and worse, they’ll never surprise us with an unexpected breakthrough. This brings us to one of the most important things leaders and teams need to internalize: our way of working is made up. This is different from how it has to be or has always been. Every organization has a purpose. But not every organization ensures that its purpose is fractal — that it shows up at every level.
The team’s purpose serves the same function as the organizational one. Legacy Organizations are obsessed with measurement, often using it as a form of control — to find and punish weak performance. But when we obsess over metrics, we fall victim to Goodhart’s law, which states that a measure that becomes a target ceases to be a good measure. You’re doing it wrong if you aren’t making decisions and taking action based on your metrics. Ask every team in your organization to articulate their essential intent. Clarify your purpose so you can see it three decades later. Then tighten up your road map for the next half year. Purpose enables freedom and autonomy by ensuring coherent action. The sense at the bottom is that leadership doesn’t trust anyone.
This will leave space for the emergence and harness the full potential of your membership. What is our current strategy? How does our purpose inform our approach? What critical factors will mean the difference between success and failure? What are the trade-offs we’re willing to make? How do we develop, refine, and refresh our strategy? How do we communicate our system? How do we use methods to filter and steer day-to-day? How does our approach inform our planning process? Recognize that sound strategy depends on our ability to perceive what’s happening.
In the open-source community, even though many of their practices may differ from their peers, high-quality code is produced. Individuals guard their implementations; they go as slow as they need to and spend extra time designing. Others can contribute ideas and pull requests that will be accepted if they align with the author’s intentions. The world can profit from its work but does not dictate the outcome.
Accept that in areas of rapid change, your strategy is only as good as your ability to learn and adjust course. If “our money” were our money, who knows how well we could deploy it to serve our collective purpose? The tragedy of the commons is that we can’t share.
Recognize that people are not resources. They are people — capable of directing their time and attention to where they can add value. They’re also capable of delivering performance without fixed targets or individual incentives. Let relative targets and a share of the wealth created by the business guide behavior. Accept that you cannot predict the future. Cut long-term commitments where appropriate to maximize discretionary funds. Ignore annual rhythms and divide resources based on real-time information.
The first thing you need to do when implementing Agile is to create a Backlog. Then, create a road map of where you think things are going. It’s important to remember that this is a snapshot in time, so don’t over-plan. Plan in enough detail to deliver the next increment of value and estimate the rest of the project in larger chunks.
The stakeholders will have read the estimated stories and sorted them in the order of business value. The goal of each iteration is to produce data by getting stories done. An iteration should contain about the same number of stories as there are developers on the team. The team should focus on stories rather than tasks within stories. Stories are chosen by and belong to individual programmers. Managers and leads will be tempted to assign stories to programmers. This should be avoided. Let the programmers negotiate amongst themselves to promote collaboration is far better. After all, agile teams should be self-organizing teams.
Before making any new decision towards passing a change to production, we must ask, is it working? Then can we make it more readable, and how fast can I make it? “Make it work.” You are out of business if it doesn’t work. “Make it right.” Refactor the code so that you and others can understand and evolve it as needs change or are better understood. “Make it fast.” Refactor the code for “needed” performance.
The team’s highest priority must be to please the customer through the early and continuous delivery of valuable software. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage. Deliver working software, from a couple of weeks to a couple of months, with a preference for a shorter timescale. Business people and developers must work together daily throughout the project. Build projects around motivated individuals.
Working software is the primary measure of progress. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace. Continuous attention to technical excellence and good design enhances agility.
Simplicity — the art of maximizing the amount of work not done — is essential. The best architectures, requirements, and designs emerge from self-organizing teams. The team reflects on becoming more effective, then tunes and adjusts its behavior. The key message is that everything is being done in the open.
[¹]: Clean Agile: Back to Basics
[²]: Brave New Work: Are You Ready to Reinvent Your Organization?
