What is Agile and Why is it Important?

You would have to be living under a rock to not have heard of agile these days. The label is being attached to everything – agile methodology, agile sales, agile marketing, agile testing, agile you-name-it. But what does agile mean and why is it important?

This blog will explore the meaning and origin of agile, some core tenets of agile and how it compares to other ways of working. Finally, we will look at why agile is important and how those organizations that don’t adopt agile are going to find themselves at a competitive disadvantage.

What is Agile?

Let’s start with an exploration of this term, where it came from and the agile values and principles which collectively are known as the Agile Manifesto.

Origins of Agile

The term Agile has been around a while. It can be traced back to the Latin term agilis which means “nimble or quick,” and from the term agere which means “to set or keep in movement”.

So what is agile? The modern usage of agile as a way of working can be traced to 2001 and a meeting of software development thought leaders in Snowbird Utah. These thought leaders met to talk about how to improve software development.

At that time, most software development was completed using heavyweight methodologies that were based on phases and stage-gates and included a lot of process and documentation. Those development approaches were heavy and the group was frustrated and motivated to come up with something better.

The software development thought leaders had been working on various alternative development approaches like eXtreme Programming, Crystal and Scrum. Informally these approaches were called lightweight methods, in contrast to the previous “heavy” methods.

As these thought leaders met and discussed common values, they discussed possible names for their movement. They didn’t want to be known as “lightweights”. Adaptive was a term that was kicked around, but then one of their members advocated for Agile which won out with the group. The group wrote up their declaration of values and principles and called it the “Agile Manifesto for Software Development”.

Over the years, the Agile Manifesto for Software development has grown and morphed. As agile ways of working have spread beyond software development, people shortened the expression to just Agile Manifesto, and ultimately to just Agile. Agile is now applied to all facets of business and has been extended into education and not for profits.

But the Agile Manifesto remains the guiding credo of the group.

The Manifesto for Agile Software Development – 4 Values and 12 Principles

Let’s take a closer look at the 4 Agile Values and the 12 Principles Behind the Agile Manifesto.

4 Agile Values in the Manifesto

The graphic below from the Agile Manifesto website shows the four Agile Value statements.

As you can see in the preface of the values, the authors stated that they are uncovering better ways of developing software doing it and helping others. All the values are important but the items on the left are more important than the items that are on the right.

Individuals and Interactions over Process and Tools

As noted previously, when the Agile Manifesto was published, there was a push for heavyweight methodologies. The movement toward process was exemplified by the Capability Maturity Model and ITIL which were becoming popular at that time.

So it was striking that these thought leaders decided to start with people. They felt that getting the right people on the team (individuals) and helping them work together (interactions) was much more important than following any specific process and or using a particular tools. So they put a priority and those items on the left, the individuals and interactions.

Working Software over Comprehensive Documentation

In traditional or waterfall approaches for software development, teams would spend a lot of time gathering requirements and developing designs and specifications and not actually building something until very late in the lifecycle. The Manifesto authors believed is that it is more important to get a solution that works than to have a bunch of books that describe how the solution would work.

Customer Collaboration over Contract Negotiation

The third value is customer collaboration over contract negotiation and in this context contract negotiation means arguing about what was included in the scope, so for example you might hear the phrase “that’s not what you put in the requirements document” that’s contract negotiation. These thought leaders believe it’s more important to collaborate with our customers to get the solution that they need.

Responding to Change over Following a Plan

The fourth and final agile value is responding to change over following a plan. The authors agreed that plans were important and in fact, agile teams actually do quite a bit of planning. It’s just these thought leaders believe it’s for important to be able to respond to the inevitable changes than to follow a plan that is established at the beginning of the project when you had very little information

All of these values in the Manifesto are important but there’s a higher priority placed on those items on the left versus those items on the right.

12 Agile Principles

In addition to those 4 Agile Values, the authors of the Agile Manifesto agreed to a set of 12 Agile Principles that underpin agile ways of working. Though less well known than the 4 agile values, I find that the 12 Agile Principles are more useful and provide more guidance on agile ways of working.

For convenience, I’ve numbered the 12 principles but on the website they are just listed without numbers.

The first principle is the highest priority is to satisfy the customer through early and continuous delivery of valuable software. The words “valuable software” bothers some people. Keep in mind that in 2001 when those thought leaders came up with the agile values and principles, they were thinking only of software development. Since then agile has been introduced in almost every industry including, in construction, in automotive assembly, and even in the manufacturing of jet fighters. If it makes more sense for you, please substitute the words “valuable solutions” for valuable software.

The second principal is to welcome changing requirements even late in development. At the time this was written, most people were focused on controlling change or managing “scope creep”.

The reality is that change is inevitable. Agile processes defer decisions, shorten development cycles and support just in time analysis of requests. This allows agile teams to change quickly and at low cost. That provides competitive advantage and is one of the keys to agile ways of working.

The third principles is to deliver working software frequently, from a couple of weeks for a couple of months with a preference to the shorter time scale. One of the main benefits of delivering frequently is to get feedback to make sure that you’re on the right track to make sure that you’re actually building a solution that the customers need.

Similarly, number four is about business people and developers working together daily throughout the project. At the time this was written, it was common for business people to create a requirements document and ‘throw it over the wall’ to the developers. After months or years of working on it, the developers would reveal it to the requestor for final testing and only then learn that the solution was incorrectly stated, improperly built or no longer needed. The point of this principles is for those who build and those who use the solution to collaborate to avoid those outcomes.

The fifth agile principle is to build projects around motivated individuals, give them the environment and support they need and trust them to get the job done. This is actually a 3 parter – it is about getting motivated people, empowering them and trusting them.

Number six, agile processes promote sustainable development. The sponsors developers and users should be able to maintain a constant pace indefinitely.

Back when I first started working on technology projects, they might be six or 12 months long or longer. It was common for very little work to be done in the first month or two. Not surprisingly, this led to a huge crunch at the end where a huge chunk of the work had to be completed. Team members were expected to work nights or weekends to hit the date with fixed scope and fixed timelines. This was called death march projects.

Agile doesn’t say you’ll never have to work have to work an evening or on a weekend. It just says that everyone should be working at a sustainable pace.

Principle number seven is working software is the primary measure progress. Traditionally, percent complete was used to measure the progress of projects. Percent complete is super unreliable because people have a hard time establishing the percent, especially when it gets to 80 or 90%. Rarely does 90% done mean that only 10% of the effort or time remain.

Rather than using percent complete, agile teams break the work down into features or functions, decompose those into small pieces, and then build in small pieces. They track whether or not those small pieces are done and avoid percent complete.

Number eight is the most efficient and effective method of conveying information to and within the development team is face-to-face conversation. The most popular communication tool today is probably email. That is efficient for the sender – after all, they can hit send and blast out information to hundreds or thousands of people at once. However, that is not true communication.

It turns out that when we read other peoples writing there’s a lot of room for misinterpretation. Agile proponents have learned that for a true shared understanding, it is imperative to get people together. If face to face is not possible, use the highest bandwidth form of communication that is available. That might turn out to be video conference or conference call. That is still infinitely better than posting a document to SharePoint! The guidance here is to use them the highest bandwidth communication channel that’s available to you.

A side effect of the preference for face-to-face communication is that it just makes sense to co-locate people who are on the same agile team. Many organizations today ignore what seems to be common sense.

The ninth agile principle is continuous attention to technical excellence and good design enhances agility. The point being made is to avoid shortcuts or techniques that build technical debt. Don’t do something that makes it fast in the short run, or cuts out some steps but that is actually more costly in the long run. You won’t have much agility if you continue to pile up technical debt!

This was quite common on projects using waterfall development with fixed deadlines. In order to hit the promise dates, corners were cut. Testing cycles might be reduced or eliminated to save time. Which meant more problems later in production after the go live date. Which set up firefighting and hard to maintain code.

Principle number 10 is about keeping things simple and eliminating unnecessary work. Simplicity – the art of maximizing the amount of work not done – is essential. What is says is that we should be looking at our processes and eliminating anything that is not value add to the customer so maximizing work not done while still delivering what is required

Number 11 is about self organizing teams. The best architectures, requirements and designs emerge from self-organizing teams. We should let the people closest to the work make decisions on how to best get it done, that’s the essence of this principle.

Finally, principle number 12 is about retrospectives. At regular intervals the team reflects on how to become more effective then tunes and adjusts its behavior accordingly.

The Agile Values and Principles may not seem radical today, but when they were announced in 2001 they were somewhat radical. Hence the term ‘manifesto’. They outlined a way of working that was very different than how organizations had learned to work over the previous century. Up to that point, Software development was largely modeled after work practices developed during the Industrial Age. It is important to understand this historical context as described below.

Scientific Management and the Assembly Line

Most organizations are strongly influenced by two key ideas from the early 1900’s. First is the push for efficiency promoted by Frederick Taylor in his scientific management. Second, is the use of the assembly line and specialized skillsets made famous by Henry Ford.

The combination of these industrial age approaches worked great for factory work, where unskilled workers churned out huge quantities of standard parts. However, they don’t work for modern knowledge workers who work together to deliver complex and innovative solutions.

When applied to software development, the factory and assembly line approach resulted in waterfall development. There were different phases of work being done by people, with each phase requiring specialized skillsets and handoffs to the next phase. No one had responsibility for end-to-end delivery and quality problems were often undetected until the end when they would be costly to fix.

Modern knowledge workers that adopted the assembly line approach took too long to develop a solution that was no longer needed for customers that they did not understand.

Core Tenets of Agile Development

Some of the core tenets of agile development that differ from the traditional ways of working include the following.

#1 – All One Team

Rather than spread out people and create handoffs between specialities, we move all the people into one team that can deliver the end to end solution. This eliminates the handoffs and increases ownership and satisfaction for the solution.

#2 – Team and customer collaboration

Agile recognizes that it is critical for the team building the solution to work closely with the customer or/and user for that solution to make sure that we build the correct product the first time.

#3 – Timeboxed Iterations

Most agile approaches strive to break things down into small increments and deliver them quickly to get feedback. They utilize a short time box where they take items all the way to done. This creates short feedback loops and forces completion. Today most agile teams use 2 week time boxes that are called iterations . In Scrum, the timeboxed iteration is called a sprint.

#4 – Embrace Change

We should not only expect change we should accept it, that often the circumstances change, competitive dynamics change and we learn things about the solution that change the way we deliver the solution. So we shouldn’t just develop a plan and stick with it we should expect things to change along the way.

#5 – Empower and Trust Teams

It’s really important that we empower and trust our teams to deliver so we give them decision making authority and remove as much as possible the power to decide how to get things done to the people actually doing the work and then once we do that we trust them to get the job done.

#6 – Continuous Improvement

is improving continuously so we want to be retrospect infrequently and looking at ways that we can get better and better over time

#7 – Sustainable Pace

This is about working at a sustainable pace so the team members and sponsors and end users, everybody should be able to work at the same pace indefinitely.

Jimmy Janlen has a video which explains these differences that I recommend. It is called A Brief Explanation of Agile.

Agile has become an Umbrella Term

For most of us who consider ourselves agile practitioners, agile has become an umbrella term. It has come to mean one of the many frameworks or methods that people use to implement agile.

The most popular frameworks in use today include Scrum, XP and Kanban and hybrids. There are others and many frameworks have passed out of favor over the years including:

• Feature Driven Development
• Behavior Driven Development
• Crystal
• Lean Software Development
• Dynamic Software Development Method
• Agile Software Development

While it is difficult to get exact numbers on who uses what, the chart below shows the responses provided in the CollabNet VersionOne Annual State of Agile Survey about particular Agile Methods.

Why Agile Matters

Now that we have gone through the details of agile, and the historical context, let’s discuss why it matters. We can look at this on two levels, doing agile and being agile. Each provides some benefit to the organization.

Doing Agile versus Being Agile

Doing agile is about executing agile practices. It is about organizing so that we efficiently and effectively deliver the best solution for our customer in the least amount of time.

You can think of doing agile as applying the Scrum Framework with 2-week sprints and a cross-functional team to build a solution. The team works on items that a business person has prioritized in a product backlog. The team works in a consistent way and is able to predict how long things will take.

Being agile builds on the benefits of doing agile. We move beyond efficient ways of working to create a work environment, culture and mindset which supports true business agility. This means that we create psychological safety so that people feel safe to take risks, to innovate and to share themselves fully. We want teams that deliver solutions that customers love, and that love doing it.

Typically organizations that are successful at being agile have little hierarchy and they have empowered people to make decisions and self-organize. They promote the growth of the individual and foster continuous learning.

Key Benefits of “Doing Agile”

The CollabNet VersionOne Annual State of Agile Report includes a list of the top 5 benefits of adopting agile and they have been pretty consistent from year to year:

• 88% of the people who responded to the survey said they were better able to manage changing priorities
• 83% of the respondents said they experienced increased team productivity
• 83% also has listed improved project visibility
• 81% of the respondents listed increased team morale and motivation
• 81% faster time to market

Another important benefit not included in the survey above was project success rates. The Standish Group has tracked IT project success and failure since 1994. In a recent Standish Group study that included data from 4000 projects from 2013 to 2017, they found that agile approaches were 2X more likely to succeed than waterfall/traditional approaches, and traditional projects were 3X more likely to fail or be cancelled.

Key Benefits of Being Agile

In addition to the benefits organizations get by doing agile, being agile contributes to the following:

• Be more competitive
• Delight customers
• Innovating and introducing change more quickly
• Attract and retain high-performing employees

Organizations Need Business Agility to Remain Competitive

Whether doing agile or being agile, organizations need agility to be competitive. Those that are able to leverage agile will be able to identify and exploit opportunities before their competitors. They will be able to deliver on those opportunities more effectively so that they maximize their profitability. And the culture of the organization will attract and retain the type of people that will sustain it over the long haul.

All of this means the organization will be competitive and will provide for their customers, employees and stakeholders. It means long term business viability.

Summary – What is Agile and Why it is Important

I hope this post has helped to explain what is agile and why it is important. Agile ways of working have become mainstream today with most organizations claiming to use agile at least some of the time. Those organizations that are able to leverage agile ways of working and the culture of agility are going to dominate their industries. Those organizations that do not take advantage of agile are going to struggle to retain both customers and talented employees. At some point, their lack of business agility is going to threaten their very survival.

Originally published here.

Business & Finance Articles on Business 2 Community

(72)