235: Breaking the Mold and Embracing the Agile Mindset

Thank you for reading Snippets of Text. Snippets from media about tech, programming, parenting, and more. This is a preview of a post available exclusively to paying subscribers. You can get unlimited access to all articles by purchasing a subscription.

I am currently writing a book about Agile methodology, and it specifically highlights the importance of autonomous teams. I'd like to share a brief excerpt with you:

Current Work: Breaking the Mold and Embracing the Agile Mindset

Companies must understand that technical problems are also business problems. The last thing an engineering organization wants is for teams to slip into "agile zombie mode," a common industry occurrence.

Engineers should only need to complete a checklist for some pull requests they merge. Do they still need that on-call rotation where engineers acknowledge and silence alerts 99% of the time? Teams assigned to these components reduce their ambitions to fix the technical debt. They should push back on newcomers' attempts to settle the debt and ask to get reassigned elsewhere. Maintaining the status quo may be comfortable, but removing ineffective methods is more effective. Agile zombie mode is prevalent in the engineering industry. The team regurgitates what's on an Agile board each morning while everyone tunes out. Hours of team time are dedicated to pointing out tickets and debating estimates, but people need to know who the calculations are for. Many engineers have been on an Agile zombie team before, which is frustrating. Only some strategies are meant to exist forever. Consider declaring bankruptcy in your process. Restart with minor or even no function and reincorporate the process pieces that solve pain points that arise. Any strategy should balance efficiency and stability with the need for innovation and progress.

Software development is unpredictable, and investing too much time upfront in a plan generates waste. The time to market is extensive, and end-user learning takes too long. Agility is all about empiricism and cooperation. It works well once teams can embrace uncertainty and are empowered. Completing 100 PRs in a week doesn't matter if they don't contribute to helping the business. Teams should be the keepers of their process. A project is not only about code but also about delivering value to the customer. A value-driven agile process enables collaboration through open and consistent communication.

Managers are crucial in ensuring a team's success by managing and directing their employees' work. Bugs and operational issues are often discussed in meetings, and developers may be blamed for not being productive enough. Managers manage people, and as long as they are in charge, they are happy to have their direct reports working faster. Managers use complete transparency to micromanage developers and push them to work faster. Product owners do not consider themselves part of the team and do not share the responsibility when things go wrong. Product owners and managers may feel responsible for the team's success only sometimes. We must consider both the process and the people involved in agile transformations.

A sprint is a predefined, repeating window (usually between 1–4 weeks) in which pre-selected tasks must be completed. Not all agile practices are positive.

Agile processes promote sustainable development. The sponsors, developers, and users should maintain a constant pace. The philosophy of intolerance to self-examination is present in all its practices. SCRUM may enjoy meeting deadlines and creating a structured approach to managing time, but it also has drawbacks. Agile doesn't make the team go faster; instead, it allows the team to see how they can improve in time to make a difference. Many organizations need help putting Agile processes in place. Agile is a robust method that can benefit software development teams. However, it can also be challenging to implement. We will delve into documentation and establishing a framework supporting Agile teams. Maintaining integrity in your work is of utmost importance. Engaging in collaborative work sometimes compromises the main thought behind it.

Agility in Modern Organizations

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 Agile Implementation Process

The first thing you need to do when implementing Agile is to create a Backlog. Then, create a roadmap 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 few weeks to a few 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. The key message is that everything is being done in the open.

Thanks so much for looking at the free preview of Snippets of Text. To celebrate Labor Day, I want to give you a fantastic deal: 50% off on the subscription for life! Please subscribe to the paid version if you find my work helpful and informative. I would appreciate your support!