A look at Agile 2’s values and why we need both sides of the coin to create value.
While the values of the original Agile Manifesto have helped shift the way software is developed today, it is very much left to the interpretation of the individual applying them as to how it should be done. This interpretation can often be dogmatic to focus solely on the left, sometimes at the total exclusion of those on the right, even though it clearly states “That is, while there is value in the items on the right, we value the items on the left more”.
Agile 2 consists of six values and 43 principles. It comprises a deep and nuanced set of ideas, and all of its ideas are supported by the thoughts that led to them. In this article I am going to provide a view into Agile 2’s six values and why we chose the word ‘and’ instead of ‘over’. Agile 2 seeks a balance of both the left and the right, both are needed, and both are useful. Also, Agile 2 seeks to speak to a broader range of activities beyond only software, including product development in general, and in fact any collaborative human endeavor.
The Values of Agile 2
Let’s take a look at them one by one.
1. Thoughtfulness and Prescription.
Frameworks are good and useful. They often give us a place to start and help us to solidify an approach. But they should not be followed blindly without considering your own context – where are you and what can and can’t you do in the context of your organization. Many variables are at play to construct the perfect environment for a framework to succeed, including organizational structure, culture, compliance regulation, and leadership support to name a few. A practice that is best for one organization may not be the best or have a chance of succeeding in another. That is not to say that you can’t move towards an ideal, but it very often isn’t the place you can start.
This contextual variability is why thoughtfulness is essential when applying a framework, or any practice or methodology. However, there are cases when one should start with a well-defined practice and follow it precisely. For example, if one is replacing a component of a complex machine, such as a blade on a jet engine, following procedure is often essential for ensuring that it is done right. Lives and safety might depend on following the procedure rather than improvising.
Still, judgment is sometimes required. Surgeons often have procedures for specific types of operations, but they need to be able to improvise, using their own judgment, when things do not proceed as expected; their experience and judgment are key, and the patient’s life might depend on it.
There is a place for prescription; and there is a place for thoughtfulness. Knowing the right balance is a matter of context.
2. Outcomes and Outputs
In the course of product development, outputs are the things that get produced by the development teams. These are usually design artifacts: digital files that define the product and its fabrication (hardware) or deployment (software).
Outputs are important – they help us measure our progress using metrics such as the team’s throughput, number of defects, quality of the software etc. These are mainly what you might call activity-based measures. But ultimately, we are building products or creating a service for our customers using Agile to achieve some business outcome. Sure, the customer will care about the quality, no one wants a product that is not stable, and the organization may not achieve its revenue target or market share if the product is not released on time. But the product also needs to be what the customer wants and will use. It must be the right product and someone or some group needs to be accountable for directing that vision to achieve the desired outcome, which is the true measure of success for the organization.
So, outputs matter: they are essential elements of any process; but they are not the end goal. The end goal is the outcome.
3. Individuals and Teams
We often hear there is no ‘I’ in ‘Team’ and much of what is written about Agile is written regarding the practices of the team. Teams are necessary to accomplish much of what we do, as no one person has the knowledge or capacity. But Agile often advocates for the team’s preference over the preference of the individual, be it with team norms, communication style, and even the team environment. This can be to the detriment of the individual, which can then cascade into the detriment of the team reaching its goals.
Balance is needed so as not to stifle creativity or alienate team members simply because they do not think, learn, or process information in the same way. It is necessary for teams to have norms but sometimes allowing someone to operate outside of the majority’s norm is needed too to accomplish the team’s goal.
4. Business Understanding and Technical Understanding
We often hear that business is the driver, and that technology is the enabler, that the business is responsible for the “what” and that IT is responsible for the “how”. This thinking has led to many structures where development teams are led by product managers who have a great understanding of their domain but very little understanding of how it will be implemented and vice versa. But knowledge of both is necessary to make optimal decisions.
Technical decisions have financial and future business impact, and business decisions have financial and future architectural impact. Not every person can have a deep understanding of both, but they should not entirely shift the accountability of understanding to someone else. Instead, they should seek to understand as much as possible and collaborate closely.
5. Individual Empowerment and Good Leadership
Self-organizing teams is one of the first things people often talk about when discussing Agile. Two of the principles behind the original Agile Manifesto state:
“Build projects around motivated individuals. Give them the environment and support they need and trust them to get the job done” and
“The best architectures, requirements, and designs emerge from self-organizing teams.”
These are often translated into “leave the teams alone and don’t tell them what to do”. Yet not all teams are ready for that level of autonomy and authority.
Empowering teams, or individuals for that matter, is a great motivator. It can bring about better outcomes, and it can help to build future leaders within the organization. But to empower people without some level of supportive leadership and assessment is to set them adrift. Borrowing from a talk by former Captain David Marquet, teams need to have clarity of purpose to set direction and competency and the capability and skills necessary to get the job done . Good leadership will assess the level of oversight and direction that the team needs and help them navigate while teaching them how to make good decisions on their own.
6. Adaptability and Planning
One of the original values of the Agile Manifesto contains the phrase “…responding to change over following a plan”. I do not think anyone would disagree that planning can be useful, or that if there were a significant change that would cause the goal to not be achieved then adapting the plan would not be a good idea. The point is that both the act of planning and the ability to adapt that plan are valuable.
The planning in and of itself helps us to think through the variables that would have us choose one option, course of action, timeline, etc. over another. It helps us think through the constraints we must work under and the risks we face if we come up against them. Keeping these things in mind with respect to what is occurring while executing the plan gives us useful information, we can use to adapt the plan for a better outcome.
Conclusion
Both sides of the coin, heads and tails, are necessary to create value. Agile 2 believes that both sets of values are necessary to achieve agility. Balance is needed and consideration for the context of your situation when applying practices that might favor one over the other. I do not believe the Agile Manifesto meant to infer only one side of the coin either, and that the word ‘over’ has led to misinterpretation and rigidity on how to apply it. I could be wrong in my view and understanding also. Therefore Agile 2 has provided interpretation and insight as to how the values were derived, so as not to be misinterpreted. There is a lot of thought and experience behind them from the original authors. However, we expect Agile 2 to evolve and develop with input from the community. We hope that you take some time to review Agile 2 and add to the ideas and content that comprise it.