The agile model

How is it that we can read so many success stories about life-changing agile transitions, but at the same time witness other organizations struggle with getting results from agility?

As a way to shed some light on this question, we gathered the most crucial traits of successful agile organizations into a simple agile model, based on more than a decade of experience in helping organizations to succeed with agile.

What we found is that it's not the applied agile framework (e.g., Scrum, Kanban, or XP) that makes the difference between success and mediocrity. It is actually the understanding and application of the principles and values behind agility that dictate whether an organization will thrive in agile or fail miserably.

Elements of an agile model

According to the Agile Alliance, agile is the ability to create and respond to change. The premise of our agile model is that the ultimate goal of an agile organization is to improve their ability to succeed in an unpredictable environment.

Different agile frameworks define different practices and focus on different values. However, if we dig deeper, we find that the following eight traits are always part of the culture of successful agile companies.

• Early and frequent delivery of working product increments
• Ongoing evaluation and prioritization of work to maximize value
• Limiting work in progress
• Emergent architecture backed with automated testing
• Empowered, cross-functional teams
• Transparency
• Close collaboration between customers and developers
• Safety, as a prerequisite

Let's take a further look into how these eight elements of the agile model contribute to the adaptability of an organization, and why their presence is indispensable in the creation of a corporate culture that can succeed in an uncertain environment.

Early and frequent delivery of working product increments

The most crucial attribute of agile organizations is their ability to deliver solutions early and often.

We can't understand a complex environment via analysis, nor can we develop reliable plans to cope with unforeseeable challenges.

Rather than elaborating theories about the nature of our business context, agile organizations actually deliver something and then test the reaction of the environment. They build projects based on empirical data instead of theories.

The more uncertain the environment, the more critical it is to explore via experimenting with working product prototypes. The findings of earlier experiments serve as an input for the next product version. The production, evaluation, and modification cycles are known as feedback loops.

The length of the feedback loops determines the adaptability of the organization. The shorter the feedback loop, the more adaptable (or agile) the organization is.

Limiting work in progress

If a team wants to deliver working product increments early and often, they need to narrow their focus on a limited number of problems. In other words, they need to limit the amount of work in progress.

Limiting work in progress is an essential principle of both Scrum and Kanban frameworks. Scrum limits the amount of work in a given timeframe with the sprint backlog, while Kanban sets explicit limits for the number of items in each phase (or column on a Kanban board.)

By focusing on a limited number of things, the team earns the capability to deliver small increments faster. This capability has several benefits.

• Boosts efficiency by reducing the amount of partially done work and the cost of context switching. The organization creates value when they deliver a working, valuable product increment to the hands of the end-user. Work items that have been started but haven't been finished yet are investments without generating any value. Partially done work can be considered as a form of waste. Limiting the number of work-in-progress helps team members to avoid the cost of context switching. That is, when a team member needs to suspend a task and switch to another job, she needs to accommodate to the new context, which has a time cost.
• Improves adaptability. By finishing and delivering work often, the team reduces the risk of leaving a work item unfinished as a result of unexpected changes in priorities.
• It helps in avoiding capacity overload by enforcing prioritization. Working on many tasks at once leads to the false perception of making progress with many goals parallelly. The illusion of progress hides the capacity limitations of the organization, so decision-makers won't realize that the organization has already reached its potential, and they keep pushing more and more tasks on the organization. By limiting work in progress, teams won't start a new job until they finished something. As a result, queues of desired work will begin to pile up waiting for the team, which will make capacity constraints clearly visible. Visible constraints trigger deliberate prioritization, which helps the organization to concentrate on the most valuable work.

Ongoing evaluation and prioritization

The premise of traditional project management is that we can define our end goal upfront, which makes it possible to design a process that is optimized for maximum efficiency.

But what if we can't be certain about the outcome or the stages of the development process? What if we know that some parts of the product will be more valuable than others, and there will be some requirements that we have no information about at the beginning of the project?

In these cases, we can't optimize our plans to minimize the implementation cost, but we'll need to define small increments and select the one that provides the highest value according to our understanding.

Once we build and test the most promising increment on the target environment, we'll reassess our plans and select the next most valuable increment, based on our most up-to-date knowledge.

As we release new versions of the solution, we learn more about our environment and face new challenges and new opportunities. Each discovery can be a potential sign that we need to change our plans.

So, an inevitable element of agility is an ongoing evaluation and prioritization process, which ensures that we move forward with choosing the most promising investment at the time.

Emergent architecture backed with automated testing

To deliver solutions as early as possible, agile teams focus their efforts on the most valuable elements of the solution first. As a first version, they build the simplest possible solution.

Let's see an example.

Imagine that your team will build a new webshop. A webshop has several features, like the option of browsing products by visitors, managing stocks by warehouse department staff, and creating and handling sales campaigns by the sales department.

Let's say that the team wants to start with the browsing experience of first-time visitors because they believe that this feature will be the differentiator that makes this particular webshop stand out.

The idea of emergent architecture is that no elements will be built into the first version of the system that aren't required to make the browsing experience of first-time visitors work.

Since they focus on first-time visitors (not returning customers) in the first version, there is no need to implement an algorithm that suggests products based on previous orders of the customer. The team knows very well that suggesting relevant products to a returning customer will be an essential part of the webshop, but they still don't implement it in the first version.

Why?

The emergent architecture approach allows the team to keep the product simple. With a simple architecture, they can move forward faster. Also, a smaller and simpler code is easier to modify if it turns out that the initial ideas are flawed.

What are the risks of emergent architecture?

As the notion "architecture" suggests, it needs to be rock solid. Building a decent architecture in an emergent way requires disciplined engineering practices. Often, the team needs to redesign and reassemble some parts of the solution to satisfy new requirements.

To keep the solution stable, each increment requires thorough testing. Since an agile team makes changes in the code often, regular testing can quickly become a bottleneck and a considerable cost factor in the process. A crucial part of emergent architectures is automated test suites that ensure that modifications of the code don't introduce bugs to the system.

Empowered, cross-functional, self-organizing teams

In a turbulent environment, organizations need to make and execute decisions as quickly as possible. This can't be done with large organization units and bureaucratic, centralized decision-making procedures.

Small teams with no more than 12 members are the best in coping with complex situations and making deliberate decisions quickly. Teams focus on a well-defined goal. They take full responsibility for a product or an aspect of a higher initiative. Team members must clearly understand how their efforts contribute to the success of the company - or even better, to the wellbeing of humankind. The more engaging the goal is, the better.

To ensure responsiveness, teams should be as independent of the rest of the organization as possible. Agile teams are empowered and self-organizing; that is, the team members make most decisions. Rules and processes that drive the team are defined by those who are closest to the problem, not by top-level management.

To support self-sufficiency, most agile teams are cross-functional, that is, they're made up of people from different working areas so that they can deal with all the functional aspects of a solution.

Close collaboration between customers and developers

Agile organizations strive to deliver the highest possible outcome to their customers. However, in an uncertain environment, the solution that provides the highest possible outcome can't be defined upfront.

As the team is progressing in the project, they discover new opportunities, new challenges, and new options. The customer has the best understanding of what output provides the most significant value for their goals. On the other hand, the development team has a better understanding of the available implementation options, costs, and risks.

To keep steering the project towards the most beneficial direction, the customer and the development team need to maintain a shared understanding of what's going on, and where to go. To keep up with that shared understanding, customers and developers need to work closely on a daily basis.

No detailed plans, nor carefully written contracts can replace the constructive collaboration of developers and clients.

Transparency of important aspects of the process

Agile frameworks build on empowered and self-organizing teams, formed by motivated individuals. Since teams are self-organizing, the development process is not controlled by a single manager; instead, it's the shared responsibility of the team members to manage the development efforts and make decisions.

The collective ownership of the development effort could quickly turn into chaos if the team members don't agree about the essential aspects of the project. The most important aspects of the process are goals, measures, activities, and working agreements.

To build an agreement based on shared understanding, they need to access the same information that is relevant to the work. Also, they should maintain a single source of truth that is easily accessible to all members who contribute to the success of the project.

In other words, important aspects of the process must be transparent for all involved in the development process. Software tools used by agile teams serve transparency. Organizations often misinterpret the goal of an agile project management tool. The primary purpose of agile tools is to provide transparency, not to control the development process.

Safety

Agile is not a magic method that gives wings to teams per se. Agile teams lean towards high performance by continuously uncovering new ways of working. They use their creativity to find better ways of solving problems.

On their way to exploring new - or even revolutionary - approaches, teams sometimes fail. In fact, failure is an unavoidable inherent part of innovation, so it is to be agile. There is no agility without establishing a safe working environment.

To succeed with agile, safety must be established on the following levels.

• Social safety around the teams. The organization must accept that the best-performing agile teams sometimes end up with a conclusion that their initial concept didn't work.
• Social safety within the team. To establish an atmosphere where team members feel encouraged to come up with novel ideas, safety must be a prerequisite within the group.
• Safety at the engineering level. Although we acknowledge that risk is a natural ingredient of innovation, the team must do everything humanly possible to design and build a protected ground where the effects of failures can be minimized. The ongoing endeavor to technical excellence and extensive use of automated tests are typical ways of creating safety around the solution.

What are the potential benefits of agile?

Don't expect that implementing agile practices will turn your organization into a hyper-productive value generation machine in 2 weeks. That may be an outcome for the long-term, but only if your teams develop unique and efficient solutions to provide exceptional value to your customers.

And this is the key advantage of agile: increasing the chance that your organization can outperform your competitors by recognizing, understanding and generating change smarter and faster than your competitors, through the work of courageous and creative teams.

To support this goal, when done well, agile can introduce some more predictable benefits. Agile can improve the return on investment (ROI) of the development efforts due to the following reasons.

• The early and frequent delivery of working solutions improves ROI since it reduces the elapsed time between investing in a development effort and delivering the results.
• The ability to evaluate our ideas via testing working solutions in a real-world environment minimizes the risk of wasting our investments by developing features that nobody needs.
• The ongoing value-centric prioritization, along with small increments, helps us to deliver the most valuable elements of the solution at the earliest possible time. As a result, we can enjoy the benefits of our investments from the first moment. Agile can significantly increase employee satisfaction and reduce employee churn.

An agile mindset helps the organization to implement a safe working environment, where work has an igniting purpose and creativity can flourish. This makes working for a real agile organization an asset for motivated employees.

Increased operational safety is an often-overlooked benefit of real agile organizations. This benefit comes from the team-oriented nature of agility. In a self-organizing agile team, individual responsibilities and the overall progress of the team is transparent for all team members. This setup reduces the risk of any team member becoming a single point of failure by being the only one holding sufficient knowledge in a specific area.

Where can I learn more?

There is no single definition of agile. There are, however, some widely accepted values and principles that drive high-performing agile teams, and there are proven frameworks that helped many organizations to succeed with agile. Our agile model is an attempt to collect the essential pieces into a single compilation. By reading an uncountable number of articles, whitepapers, and guides, we gathered the most valuable resources we've found below.

• The agile alliance's introduction to agile
• The agile manifesto and the 12 principles behind the agile manifesto
• The guide to the Scrum framework
• Simon Powel's model to explain what is agile
• The Modern agile initiative
• The Heart of agile approach