“But the Agile Manifesto is just for developers! Why are we covering it during a leadership workshop?”
This stance can be common, especially when working with executives on agile projects. And they aren’t completely wrong; the manifesto was written by seventeen people with backgrounds in software development and methodologies.
However, upon closer inspection, the Agile Manifesto is also about leadership—influencing culture and creating an organization where people can collaborate to meet the needs of their customers. Here are seven lessons the Agile Manifesto can teach us about leadership.
Lesson #1: Agile is more than a mindset.
Let’s start at the beginning: “We are uncovering better ways of developing software by doing it and helping others do it.” The preamble of the Agile Manifesto is often overlooked, but it contains a clear directive: Agile is driven by action. We are learning by doing and helping others do it.
Agile is also about delivering something. As a leader, you can help your teams by expecting working software (or any deliverable) at the end of every sprint and by removing organizational impediments that put delivering tasks in jeopardy.
The phrase “uncovering better ways” is also interesting. I take it to mean that we are experimenting and exploring ways to do work more satisfactorily and that the experimentation and exploration is continual. We have not found the “best” ways, but we are seeking better ways.
Lesson #2: Agile organizations are learning organizations.
Empiricism is at the heart of agile. We conduct experiments, inspect the results, and adapt our teams’ practices, methods, and processes based on what we’ve learned. As leaders, we accept that failure is part of the learning process, and sometimes losing a sprint or release can reap far greater rewards as our projects move forward. Don’t celebrate failure, but make it safe for teams to fail when it happens.
But how do we guide the work we lead? Fortunately, the manifesto gives leaders insights and assists with making decisions:
Through this work we have come to value:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
Let’s take these one at a time.
Individuals and Interactions over Processes and Tools
People create software. Processes and tools can get in the way of delivery. Phase gates, handoffs, and endless approvals put barriers between the many people doing the work. This can be harmful, considering agile practices are driven by collaboration.
For example, when practicing Scrum—the most popular agile framework—the product owner gets feedback from stakeholders and provides it to the team. The Scrum team members talk with the ScrumMaster to work through impediments. ScrumMasters and product owners also work together closely to make sure the backlog is well refined and understood, the product vision is clear, and the team is positioned for success.
Lesson #3: Communication is essential to collaboration.
Focusing on the individuals and interactions that make agile work puts a value on the human side of delivering software and on the “soft” skills that can make or break teams. Leaders can support this value by modeling desired behaviors. Clear expectations, continuous feedback, and seeking to work alongside your teams can help foster the effective collaboration your teams need to be successful.
Working Software over Comprehensive Documentation
Agile teams work in short feedback loops. We make small decisions frequently to build alignment with our customers on what’s needed to solve their problems. Assumptions, misunderstandings, and mistakes live in comprehensive documentation, especially requirements documents.
This does not mean that documentation goes away. How decisions were made, why a direction was taken in the architecture, and the overall goals of the project are important to preserve.
However, the intent of the code under development can be better expressed in the codebase itself. This happens in the form of unit tests, acceptance tests, and even code comments, when appropriate.
Leaders can help teams get the rapid feedback they need by being realistic about the types of documentation required for a project.
Lesson #4: We learn by doing.
Documentation is still needed, but working software is how we learn the most about our application, the problem we are trying to solve, and our customers’ needs. Walking quickly with a stack of papers won’t get the job done. Leaders can help teams stay focused on delivering solutions to their customers’ problems by making delivery a priority over less valuable busywork and favoring communication over document shuffling.
Customer Collaboration over Contract Negotiation
On agile teams, the customer is the driver. They provide the “what” and the “why” to teams, as well as the funding to make the solutions to their problems possible. In return, teams act transparently and regularly show progress to the customer.
This is an energizing cycle. Rapid learning and collaboration is inspirational to both sides. It allows the development team to see firsthand how their work is having an impact on the customer, and the customer stays informed about the work and is able to drive what the team is working on.
This is far healthier than using a contract as a proxy for collaboration. Contracts can be contentious, vague, and susceptible to misinterpretation. Contract also do not age well. They represent a shared understanding at one point in time, but things can—and often do—change.
And if reality disagrees with a contract, now what? Continue to argue about the past, or respond to the changes in the present that will dramatically alter the future? Agile leaders look forward.
Creating real partnerships with your customers and having them work with the team frequently helps establish the trust needed to move away from traditional contract arrangements. In other words, we can focus on decisions and tradeoffs about working software instead of line items in a contract.
Lesson #5: Prioritize the message, not the form it takes.
Leaders, ensure that contracts enhance the collaboration between the customer and development teams, not replace it. Teams need to see the impact of their work and customers need to have visibility into the project. They both also need the flexibility to respond to the many changes that will happen during a project. Find ways to keep teams moving forward instead of arguing about the past.
Responding to Change over Following a Plan
Short feedback loops inherently mean that we will learn things frequently. This is by design. As we learn new things, we must update our plans accordingly.
Leaders must create the safety required for teams to learn from both successes and failures. If the team is unable to be wrong or to fail, they are far less likely to try new things and experiment. This is an innovation killer.
If we insist on following the previous plan, even though we learned that change is needed, then we deserve to fail.
Lesson #6: Encourage innovation.
Leaders understand that planning is essential but insufficient. Plans must be continually updated based on the insights and lessons learned by getting frequent feedback from our customers and our teams. Again, safety is a prerequisite for learning to be possible. Make it safe for teams to experiment and learn. If your teams don’t agree with you on a technical direction, give them the benefit of the doubt and trust them to make the right call
Finally, the authors of the Agile Manifesto explain what the word “over” means within the value statements: “That is, while there is value in the items on the right, we value the items on the left more.”
We are not getting rid of the things that follow the word “over” in these four directives. The difference is that the things on the right are intended to make the things on the left better.
It’s important for leaders to consider whether a contract they are about to sign will improve or hinder customer collaboration, or if a new tool will make team interactions more difficult. If you aren’t sure, ask the team before acting. They can give leaders great feedback about the possible impacts a new requirement or process will have.
Lesson #7: Remember what’s important.
There is still value in processes, tools, documentation, contracts, and planning. However, these things must support the things we value to be more important: Individuals and interactions, working software, collaboration, and responding to change.
Leaders are constantly balancing options and making critical tradeoffs. This is what the job is all about. By favoring individuals and interactions, working software, customer collaboration, and responding to change, leaders can ensure that they are supporting the values that are critical to delivering software that delights their customers.
These are the lessons that stood out to me. Take some time to reread the Agile Manifesto and gather your thoughts about the lessons it can teach us about leadership. Which lessons resonated with you? Which do you disagree with?
