A Meetup with Philippa Fewell!
If you missed Philippa Fewell’s Meet Up where she speaks about how Agile 2 came about – you are in luck, we have it here! Philippa shares with us how she and a group of 14 other Agilists reflected together over a period of 8 months to create a new set of values and principles called Agile 2. We invite you to listen, learn and enjoy her lively discussion!
According to Deutsche Bank CIO Frederic Veron, “enterprises that wish to reap the potentially rich rewards of getting IT and business line leaders to build software together in agile fashion must also embrace the DevOps model.”[1]
Why is that? It’s simple: DevOps is necessary to scale Agile. DevOps practices are what enable an organization to rapidly deploy changes to many different parts of their product, across many products, on a frequent basis—with confidence.
That last part is key. Companies like Amazon, Google, and Netflix developed DevOps methods so that they could deploy frequently at a massive scale without worrying if they will break something. DevOps is, at its core, a risk management strategy. DevOps practices are what enable you to maintain a complex multi-product ecosystem and make sure that everything works. DevOps substitutes traditional risk management approaches with what the Agile 2 authors call real-time risk management.[2]
You might think that all this is just for software product companies. But today, most organizations operate on a technology platform, and if you do, then DevOps applies. DevOps methods apply to any enterprise that creates and maintains products and services that are defined by digital artifacts.
DevOps methods apply to any enterprise that creates and maintains products and services that are defined by digital artifacts.
That includes manufacturers, online commercial services, government agencies that use custom software to provide services to constituents, and pretty much any large commercial, non-profit, and public sector enterprise today.
As JetBlue and Breeze airlines founder David Neeleman said, “we’re a high-tech company that just happens to fly airplanes,”[3] and Capital One Bank’s CIO Rob Alexander said, “We’re a founder-led, 20-year-old technology company.”[4]
Most large businesses today are fundamentally technology companies that direct their efforts toward the markets in which they have expertise, assets, and customer relationships.
DevOps Is Necessary at Scale
Scaling frameworks such as SAFe and DA provide potentially useful patterns for organizing the work of lots of teams. However, DevOps is arguably more important than any framework, because without DevOps methods, scaling is not even possible, and many organizations (Google, Amazon, Netflix…) use DevOps methods at scale without a scaling framework.
If teams cannot deploy their changes without stepping on each other’s work, they will often be waiting or going no faster than the slowest team, and lots of teams will have a very difficult time managing their dependencies—no framework will remedy that if the technical methods for multi-product dependency management and on-demand deployment at scale are not in place. If you are not using DevOps methods, you cannot scale your use of Agile methods.
How Does Agile 2 View DevOps?
DevOps as it is practiced today is technical. When you automate things so that you can make frequent improvements to your production systems without worrying about a mistake, you are using DevOps. But DevOps is not a specific method. It is a philosophy that emerged over time. In practice, it is a broad set of techniques and approaches that reflect that common philosophy.
With the objective of not worrying in mind, you can derive a whole range of techniques to leverage tools that are available today: cloud services, elastic resources, and approaches that include horizontal scaling, monitoring, high-coverage automated tests, and gradual releases.
While DevOps and Agile seem to overlap, especially philosophically, DevOps techniques are highly technical, while the Agile community has not focused on technical methods for a very long time. Thus, DevOps fills a gap, and Agile 2 promotes the idea that Agile and DevOps go best together.
DevOps evangelist Gene Kim has summarized DevOps by his “Three Ways.”[5] One can paraphrase those as follows:
- Systems thinking: always consider the whole rather than just the part.
- Use feedback loops to learn and refine one’s artifacts and processes over time.
- Treat everything as an experiment that you learn from, and adjust accordingly.
The philosophical approaches are very powerful for the DevOps goal of delivering frequent changes with confidence, because (1) a systems view informs you on what might go wrong, (2) feedback loops in the form of tests and automated checks tell you if you hit the mark or are off, and (3) if you view every action as an experiment, then you are ready to adjust so that you then hit the mark. In other words, you have created a self-correcting system.
Agile 2 takes this further by focusing on the entire value creation flow, beginning with strategy and defining the kinds of leadership that are needed. Agile 2 promotes product design and product development as parallel and integrated activities, with feedback from real users and real-world outcomes wherever possible. This approach embeds Gene Kim’s three DevOps “ways” into the Agile 2 model, unifying Agile 2 and DevOps.
Download this White Paper here!
[1] https://www.cio.com/article/3141577/true-agile-software-development-requires-devops.html
[2] Agile 2: The Next Iteration of Agile, by Cliff Berg et al, pp 205 ff.
[3] https://www.businessinsider.com/breeze-airways-pushing-back-launch-until-2021-what-we-know-2020-7
[4] https://www.youtube.com/watch?v=0E90-ExySb8
[5] https://itrevolution.com/the-three-ways-principles-underpinning-devops/
Everyone says you should use Agile. The call for Agile has reached the CEO level: I myself have heard CEO announcements stating that the organization must use “Agile”—whatever that is, because I wonder how many actually know.
On the other hand, how many Agile proponents actually understand what Agile is? As I wrote in a recent article, Old Versus New Agile, Agile has changed—and changed a lot. Thus if you bring in “Agile” consultants to help, are they using “old Agile,” or “new Agile”?
Old Agile is arguably very limited, and does not acknowledge the realities of a large organization. What I refer to as “new Agile”—and I believe it is described well by Agile 2—is completely focused on the general problem of agility, and how that plays out in the broad range of situations, including and especially large organizations. Because to do big things—profitable things at scale—you need a very sophisticated model. Agile 2 provides that.
I have seen IT managers make tragic and far-reaching mistakes in their attempt to follow “old” Agile. For example, in more than one case an IT SVP eliminated all roles pertaining to testing. I wrote in an article why that is a tragic error that eventually results in terrible quality issues and actually impedes agility.
Old Agile is not all bad. It broke the grip of rigid approaches being pushed at the time by PMI and the procurement school of thought. In a fast-changing market, custom market-facing software cannot be “procured”: it must be seen as something that evolves over time. Agile made us face that. Some of the ideas that it brought into the forefront were:
- Phase-based (requirements, design, implementation) software development does not usually work.
- Business users often do not know what they want or need.
- It is almost impossible to fully design software up front
- Documents alone are not effective for communicating things
- Don’t build something entirely in one go
- Big teams do not work
- Don’t micromanage how developers work
- Don’t trust anything until you see it running
- Build quality in
- More effort ≠ better; automate to avoid effort
- Continuously reflect and improve
These are all good things, especially if one views them as reminders rather than absolutes. But the Agile community also came to espouse some extreme and ultimately toxic viewpoints—again, especially if one views them as absolutes (which is often the case). I consider these views to be part of “old” Agile. These include:
⚠️ Teams do not need leaders, except to “remove impediments”.
⚠️ Always trust the team.
⚠️ A team must be completely autonomous.
⚠️ Multiple teams will collectively self-organize.
⚠️ Written communication is not important.
⚠️ Everyone must sit together.
⚠️ Most challenges pertain to individual contributor team behavior.
⚠️ Teams can resolve technical issues if leaders merely “get out of the way.”
⚠️ If Agile does not work at scale, it is the organization’s “fault.”
⚠️ Specific technical practices such as pair programming and TDD are always “best.”
In contrast, “new” Agile ideas are markedly different. A tiny sampling of these authors includes Klaus Leopold, Nicole Forsgren, Jeff Dalton, David Marquet, Matthew Skelton, Manuel Pais, Mirco Hering, Mark Schwartz, and Gary Gruver, as well as some “old Agile” authors who have evolved a mature view over time (or had one from the beginning) such as Johanna Rothmann, Diana Larsen, as well as myself and the 15 members of the Agile 2 team.
You probably see now that the peril of bringing in Agile consultants is that you might not know if they embrace “old” Agile ideas or “new” Agile ideas. But that is not all. “New” Agile includes many additional narratives that are critical for achieving agility at scale. The Agile 2 team attempted to summarize these through its principles, but a very abbreviated summary is as follows. Note that these are considerably at variance with “old” Agile, but are well aligned with the “new” Agile that Agile 2 and many of the above authors advocate:
On leadership:
- The predominant forms of leadership are the most determinant factors of success.
- Someone usually needs to coordinate things, and be the organizer.
- On any team, one wants a “missionary, not mercenary”—someone who values the organization’s success first and foremost.
- There are many forms of leadership: team focused, advocate focused, technically focused, and maybe others; as well as individual leadership.
- The organization needs to explicitly focus on encouraging benign and effective forms of leadership, and take steps to avoid giving the wrong people authority—avoiding people who “seem like leaders,” and instead selecting (actively or passively) those who are the “missionaries” and the helpers.
- Leadership is needed at every level of an organization, and the same principles apply.
- Leaders of tech-focused organizations not only need to understand outcomes, but they also need to understand how the work is done, because the “how” is often strategic.
On a systems approach:
- Don’t be extreme, unless the situation is extreme.
- Always think holistically—in terms of the whole system.
- Product design is an essential element, apart from product implementation; yet the two are intertwined.
On products:
- Direct feedback from customers and stakeholders is the only way to measure success.
- Product implementation teams must be partners with business stakeholders—not mere order takers.
On data:
- Data is strategic, and it must not be treated as an afterthought.
On collaboration:
- Collaboration is essential, but so is deep thought. People often need quiet and isolation in order to think deeply.
- People work, communicate, and collaborate best differently. A one-size-fits-all approach is not effective.
- Team autonomy is an essential aspiration; but for a complex endeavor, full autonomy is seldom fully realizable.
- Some people want to be experts. Some people want to be generalists. Some are in between. All are valuable.
- Both teams and individuals matter. Don’t over-emphasize one over the other.
- A team should collectively decide how to approach its work; but then individuals perform the work and interact as they need to.
On transformations:
- Transformations are mostly a learning journey—not a process change.
- Never use a framework as defined: treat it as a source of ideas—not an Agile-by-numbers process.
Conclusion
Agile is not a single theory or approach. There is great diversity of thought within the Agile community. When choosing consultants or an approach for adopting Agile methods, be thoughtful about who you choose. Ask yourself, are they interested in putting people on the ground to deliver a commodity service? Or are they deeply thoughtful about what they do, and represent mature and effective viewpoints? And will the people they provide be as up-to-date and astute about the nuances of old versus new Agile ideas as those who have had conversations with you? Because it matters.
Organizations with internal cultures that are aligned with their strategies are far more effective than those without aligned cultures. Decades of data prove this.[1] For example, over the last 50 years, culture specialist Human Synergistics has compiled data on more than 30,000 organizations and it clearly shows strong correlations between specific organizational culture attributes and business performance. Yet it is common for organizations to ignore culture when trying to implement their strategies.
Agile 2 is a more mature version of Agile, and it relies on having a supporting healthy culture. In fact, analysis that Agile 2 Academy has done with Human Synergistics shows that Agile 2 ideas strongly align with what Human Synergistics calls a Constructive culture, which is the most effective kind.
When an organization decides to adopt Agile 2 (or any Agile) methods, it is common to define a set of “practices” that development teams must follow. This is an essential step, but there are some great perils in assuming this approach is enough:
- Many, if not most, practices require people to learn new skills, make new judgments, and behave in new ways. Practices alone are not enough.
- Most of the obstacles to using Agile 2 (or legacy Agile) methods actually exist outside of the development teams. These obstacles are widespread and manifest as management behaviors, lack of supporting systems that Agile teams need, and processes and procedures that make it nearly impossible for teams to operate with agility.
Peril #1 means that people will not be able to execute the practices. They will “go through the motions”—but Agile 2 (agility) is, in its essence, a replacement of step-by-step processes with just-in-time contextual decision-making. If people follow practices and make poor judgments, then the organization will suffer from ongoing bad decisions and poor outcomes. But if the organization’s culture is one that encourages people to seek safety through following procedure, rather than relying on their judgment, then they will not be willing to make judgments: they will copy what others do, and perhaps do the wrong thing.
Peril #2, that most obstacles to agility originate from beyond the teams, is seldom appreciated by organizations beginning an Agile journey. Senior leadership often views Agile as something that development teams and individual contributors do. They don’t realize the extent to which Agile—having agility—relies on having the right support systems in place and the right kinds of leadership supporting the teams.
If the organization has a culture of hands-off leadership, then people who find themselves in a leadership role will not know how to behave when leadership is needed. For example, a common situation is when managers have learned the Agile practice that teams “self organize” but do not realize that that is just a placeholder or reminder. Most teams cannot self-organize well; they need leadership. Self-organization is an aspiration, not a starting point.
The need for leadership is even more acute when one has many teams, and they need to coordinate, and resolve issues such as “How will we design the product? How will we involve real users? How are we going to integrate? How will we manage quality? How will we support our product? How will we agree on branch and merge strategies for the product as a whole?”
When people in a non-Agile organization implement Agile practices, they look for a rule book or procedure to follow, because that is what they are used to, but there isn’t one. If you were to create one, it would not work everywhere, because every Agile decision and judgment is contextual. It always depends; that is what yields agility and makes it possible for people to select the shortest path for each situation.
The above are aspects of the organization’s culture: the ability to discuss issues openly and honestly so that they can be resolved, the willingness to take risks when making a decision, and the patterns of leadership that people have learned. There are many other dimensions of culture that are essential for agility, such as the inclination to learn, the tendency to try things on a small scale before scaling up, and the acceptance of things not going perfectly the first time.
As Peter Drucker said, “Culture eats strategy for breakfast,” and that certainly is true for Agile transformations. If you don’t address your organization’s culture, your agile strategy with its new practices will fail to yield the desired outcomes, and Agile will become a source of problems instead of a driving force for business agility. The good news is that culture can be changed, with the right commitment and the right approach. Agile 2 Academy considers culture improvement to be an important element in business agility. An Agile transformation strategy that includes analyzing and improving your organization’s culture is far more likely to succeed than simply adopting a set of agile practices or frameworks and hoping for the best.
[1] The best-selling book Accelerate documents research that makes this connection in the context of Agile and DevOps.
Click here to download this white paper.
To learn more about Agile 2, visit the website here.
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.
Agile 2 is here!
I was fortunate to be included in a group of exceptional Agile leaders and practitioners, led by Clifford Berg, to retrospect on Agile and improve upon what it has become over the last 20 years. Each of us began by citing issues and problems we have encountered over the years, drawing on our unique experiences. Not all of us experienced the same issues, but it was eye opening to discover what others came up with because of the diversity of the group both in practice and expertise.
We then discussed why we felt the problems occurred and what could be done to change them. This led us to revisiting the values and principles of the Agile Manifesto and many of the frameworks we use today. While I am vested in many of these, having become certified in them myself and trained others on them as well, I have seen where lack of clarity or difference of interpretation, as well as too much emphasis placed on prescription, leads to less than successful outcomes.
It is this clarity and thoughtfulness that Agile 2 seeks to deliver. It is a set of values and principles based on common problems that we believe will resonate with you, the Agile practitioner. My colleagues and I are proud of Agile 2 and the potential impact we believe it can have on the current state of Agile. Have we gotten it all right? Undoubtedly there is room for debate. Have we missed some valuable principles? Perhaps. And that is why we want Agile 2 to be open to ideas from the community, and there will be an Agile 2 version 1.1. We respect and welcome your input and ideas. We want Agile 2 to be constantly improving on what it is today so that it stays relevant. There will be Agile 2 community forums, and to begin that, there is a LinkedIn group. A book is on the way. The Agile 2 website is at https://agile2.net. Check it out!