Effective Teamwork in Agile
Purpose enables freedom and autonomy by ensuring coherent action. The sense at the bottom is that leadership doesn’t trust anyone. Stop trying to borrow wisdom and think for yourself. Face your difficulties and think. Solve your problems yourself. Suffering and difficulties provide opportunities to become better. Success is never giving up. We need more time to work, but we pack our days with endless meetings. We need the necessary information buried in emails, documents, and data. We want speed and innovation, but we run from risk and inhibit our best people. We claim to work in teams but don’t trust one another. We know how we work isn’t working, but we can’t imagine an alternative. We long for change but need to figure out how to get it. We are addicted, despite ourselves, to the siren song of bureaucracy. People can be trusted and will trust one another to use judgment and do the right thing. We are addicted to the idea that the world can be predicted and controlled — that our stoplights are the only way to keep things in check. But when you view the world that way, today’s uncertainty and volatility trigger retreating to what has worked in the past. We need to hire more capable leaders. We need to squeeze out more efficiency and growth. We need to reorganize. The natural barrier to progress in the twenty-first century is us.
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.
Organizational culture isn’t a problem to be solved; it’s an emergent phenomenon we must cultivate. We can thank them for what still serves us and change the rest. To the legacy leader, everything still looks like a factory. And all our problems can be fixed if we work long enough hard. But our bureaucracies are different from 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.
Agile helps teams structure their learning process and assess the outcomes of their work. This enables them to make course corrections to ensure they move in the right direction. By prioritizing value, teams focus on delivering the most important tasks first. They may discover that they don’t need to complete the remaining tasks or that some tasks that seemed important are no longer necessary.
Agile principles bring teams together to work towards a common goal and create a sense of unity and purpose among team members. Yet, we must remember that more features only sometimes equate to success if teams understand the direction they should be heading in. Thus, gathering evidence and making informed decisions is crucial before starting any task. By getting feedback from stakeholders early and often, teams can ensure that their final product meets their needs.
Agile places a structure around the learning process, enabling teams to assess what they’ve created and how they made it. Making people focus on value forces them to produce that 20 percent first. When they’re done, they realize they don’t need the other 80 percent or that what seemed important at the outset isn’t. What Agile does is bring teams together to create great things, requiring everyone to see the end goal and to deliver toward that goal. More features mean nothing if you’re flying blind. Before getting busy writing code, you need evidence that it’s the right thing to do.
The first thing you need to do when implementing Agile creates a Backlog. Then, as the Product Owner, 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. Estimate. Plan in enough detail to deliver the next increment of value and estimate the rest of the project in larger chunks. The key message is that everything is being done in the open. Ship existing projects before starting new ones. Focus produces higher quality work, and shipping builds execution into a habit. Order projects so new work builds on top of previous projects, which will make changes feel organic and can have compounding effects. Create a routine around reviewing the roadmap and evaluating progress toward projects. Include a roadmap review in weekly team meetings and check in with project leads.
Create an environment that encourages project leads to share and ask for help, not report a status or expected completion date. A great plan is only helpful if you’re following through on it, and you will know how well you’re doing that with regular reviews. The roadmap should feel much and be possible. A balanced roadmap leaves up to a third of the total work hours spent on bugs, fixes, and backlog items. Do your best to estimate projects and expect them to take longer than you think–it always does. It’s also better to be ambitious and avoid adding too many tasks to the roadmap, not too few. A couple more projects than practical will motivate the team to ship. More studies can lead you into a trap of working at the speed of the schedule, slowing down momentum. We need to build with equality in mind and improve those together with our teams. This is part of building a culture around continuous learning, a vital sign of safe teams. We can help teammates learn from each other through code reviews, mentoring, or knowledge sharing. We can also use retrospectives to discuss and improve how we work together. Post-mortems are a great tool to foster a learning culture to understand problems and drive toward solutions. It’s essential to keep in mind that the way we discuss failure on our teams will shape the culture that we have.
A complicated system is a causal system subject to cause and effect. Problems with complicated systems have solutions. Complex systems comprise many interacting components. That exhibit adaptive or emergent behavior without requiring a leader or central control. As a result, complex systems are more about the relationships and interactions among their components.
The man who grasps principles can select his methods. Stop trying to borrow wisdom and think for yourself. Suffering and difficulties provide opportunities to become better. Success is never giving up. We are addicted to the idea that the world can be predicted and controlled — that our stoplights are the only way to keep things in check. But when you view the world that way, today’s uncertainty and volatility trigger retreating to what has worked in the past. We need to hire more capable leaders. We need to squeeze out a little more efficiency and growth. We need to reorganize.
Organizational debt is any structure or policy that no longer serves an organization. Within that definition, we see it manifest in many different ways at many other times. Corporations want share prices to move only up and to the right. They need to move the needle now, which means revenue or earnings growth. Executives are compensated in stock to align their interests with those of shareholders. They all fall victim to a kind of collective quarterly myopia. The antidote to the diminishing returns of the status quo is to think.
To avoid the pitfalls of organizational debt, we need constant and vigilant simplification. We must create agile roles, rules, and processes — built to learn and change. Org debt creates bureaucracy, and bureaucracy protects org debt. It’s a tragic love affair.
Considering the modern world of work, the assumptions of Theory X still feel present. Our job description tells us what to do. Our manager tells us how to do it. Our office hours tell us when to come to work. Our meeting invites tell us which conversations we can take part in. Our performance review tells us how to learn and grow. They are all distrusted from believing we cannot take responsibility for our contribution and growth. Increase autonomy, and motivation thrives. Decrease it, and motivation erodes. Treat them like all-stars, and they will become all-stars. To be People Positive is to assume and expect the best of everyone. We need more time to work, but we pack our days with endless meetings. We need the necessary information buried in emails, documents, and data. We want speed and innovation, but we run from risk and inhibit our best people. We claim to work in teams but don’t trust one another. We know how we work isn’t working, but we can’t imagine an alternative. We long for change but need to figure out how to get it. People can be trusted and will trust one another to use judgment and do the right thing.
The rules are simple: Teams can add or remove members using consent. Members can join or leave teams with reasonable notice. And members can manage their bandwidth (i.e., hold many roles). Open roles are shared, and members can “apply” by meeting with other team members, discussing the work, and sharing what they offer. No formal process here, a search for a two-way fit. They ask themselves, “If I’m not a VP, what am I?” and “If I distribute my power, what do I have left?” The breakthrough happens when they realize that they can trade control for participation. Rather than living in one place in the org chart, they can live in many, a mix of roles where their influence is direct rather than indirect.
Positional power is traded for reputation. By getting closer to work, they can find joy in it again. Recognize that people are capable of self-organizing if the conditions are correct. Create simple rules or agreements about how teams are formed and changed, then let people go where their skills and energy take them.
Organize for adaptivity. Ensure that the periphery drives your structure — the teams that touch the market — rather than those at the center. Allow teams to reorganize rather than in grand gestures every few years. 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.
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. Choosing how and where to spend your money a year in advance is folly. Cut long-term commitments where appropriate to maximize discretionary funds. Ignore annual rhythms and divide resources based on real-time information.
People will only change the way they work if they see the value. The only thing that should be acceptable is to only accept a practice by providing a better alternative. Businesses should only be involved when there is a significant impact on the cost or duration of the project. Companies and developers should have conversations about business value, not technical practices. Developers should not ask for authorization to write tests. They should not have separate tasks for unit tests or refactoring. They should not have different functions for making a feature production ready. Every time developers volunteer details of their work, they invite managers to micromanage them.
Our highest priority is 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 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.
[²]: Brave New Work: Are You Ready to Reinvent Your Organization?
