Agile is a type of approach which involves the collaboration of end-users and cross-functional teams to deliver business solutions and products in a flexible and nimble way. Agile provides early delivery and continuous improvement and the capability to support rapid and flexible changes to the requirements.
If you’re not familiar with agile or have heard the term agile, but still don’t fully grasp what agile is about, then you’re not alone. Agile can be difficult to understand for the inexperienced, but understanding what agile is can be simple to understand once you start working in agile ways. Agile requires an open mind that is receptive to being guided by ideas and concepts, instead of rigid frameworks and processes.
The challenge of understanding what is agile is that agile will mean different things to different people. Starting with a dictionary definition of agile can be the easiest way to grasp what agile is. If you look up ‘what is agile’ in a dictionary, you will find that agile is the ability to move quickly and easily. In contrast, something that is not agile is slow, stiff and clumsy. Hence something that is agile will have characteristics including grace, suppleness, dexterity, and the ability to move quickly.
Some call Agile a methodology, while others refer to agile as a framework. Agile isn’t either of these. Agile is a way of thinking and a set of values that promotes a fast and nimble way to work that focuses on meeting user requirements efficiently and effectively. Agile has an emphasis on efficient production, collaboration, communication, and rapid development of smaller sets of features under the guidance of an overall plan. The key to success with agile is to remain open-minded, be flexible, and willing and able to adapt to change.
According to the Agile Alliance, the developers of the Agile Manifesto and the Twelve Principles of Agile Software that first defined what agile is in a business environment, “Agile is the ability to create and respond to change. It is a way of dealing with, and ultimately succeeding in, an uncertain and turbulent environment.” In other words, agile is about adaptiveness and responding quickly to changes as they occur, as they will always do. Hence agile is a way of thinking and not a methodology. This prevents the precise definition of what agile is becoming rigid and frozen in time. The agile movement supports and embraces the development of new ideas and concepts that enhance the definition of what agile is.
Agile encourages the creation of self-sufficient, self-determining teams, empowered to develop solutions, ways of working, and resolutions to issues themselves. Each member of an agile team has multiple skill sets and can work as an individual or with others in the agile team.
This is how the Agile Manifesto defines the values of agile:
We are uncovering better ways of developing
software by doing it and helping others do it.
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
That is, while there is value in the items on
the right, we value the items on the left more.
The definition of what agile is initially benefited software development, but agile is now in use across many sectors and many industries, both within and outside of IT. Each has developed its own view of what agile is, tailored to specific requirements and circumstances. As an example, agile has been adapted and adopted in project management and IT service management, displacing traditional project management and product delivery methods, using fixed plans and sequential waterfall approaches with more flexible and adaptable agile approaches.
Ways of doing things in what became known as agile have been around outside the work environment for a long time. Today’s understanding of what agile is came about in 2001 when the Agile Manifesto was published along with the Twelve Principles of Agile Software. This codification of what agile is was the consequence of industry frustration with software development in the 1990s. Before this definition of agile, there was a long-time lag between capturing business requirements and delivering the solution to meet them. The final product often did not meet the user’s needs, in part because the software development models of the day, such as the waterfall model, were not agile, and did not meet the demand for speed and flexibility. Thought leaders in software development realized that a manifesto was required to address these issues by defining and promoting what agile is.
The impetus to define what agile means in the work environment is believed to have started in the spring of the year 2000. Some proponents of Extreme Programming and others met in Oregon, USA, and voiced support for a variety of "light" software development methodologies. During 2000 a number of articles were written that referenced the category of "light" or "lightweight" processes, but still there was no definition of what agile is. In conversations, it became clear that no one really liked the term ‘light’. In February 2001 the term was replaced by the term agile, with the publication of the Agile Manifesto for Software Development and the Twelve Principles of Agile Software, developed by a group known as the Agile Alliance. These defined what agile is, initially for software development. This codification of what agile is provided an alternative to the documentation driven, heavyweight software development processes that existed at the time. The definition of what agile is had to be easy to understand and freely available to all. The Agile Alliance's definition of agile had to be easily embraced by the wide range of different methodologies that were used to develop software.
Before agile was defined in the Agile Manifesto and the Twelve Principles of Agile Software, these methodologies focused on processes and documentation. The definition of agile used a different approach, focusing on the customer and a set of agile values. These values define what agile is based on trust and respect for each other, promoting organizational models based on people, collaboration, and building the types of organizational communities in which people want to work.
The concepts in the definition of what agile is were soon taken up by many across the spectrum of software development. The early adopters of agile saw the value of delivering good products to customers by operating in an environment that does more than talk about "people as our most important asset" but actually "acts" as if people were the most important thing. Resonance with these values drove a very rapid rise in interest, adoption, and development of what has become widely known as agile.
While the values and principles defined in agile can be applied to a very wide variety of circumstances and situations, there will be some of these where agile is not the best approach. Despite the proven benefits, Agile, irrespective of how you define what agile is, cannot be applicable for everyone in every circumstance.
Agile requires more than just team working. Once a team embraces what agile is, they can come across deep-seated issues with management that have not yet embraced agile. For agile to be truly effective, every part of the organization and every individual in it have to understand what agile is and at the very least embrace its values. For some organizations that is too much to ask. The whole organization needs to change its culture from being authoritative and hierarchical to the open, trusted, empowered culture inherent in what agile is.
In theory, anyone can transition to agile, provided that they have the desire and determination to understand what agile is and then make the necessary changes to their attitude, behavior, and culture. However, not everybody is built the same. There can be barriers at both individual and organizational levels to embracing what agile has to offer. Here are some of the potential barriers to agile adoption:
As previously mentioned, the definition of agile is based on the Twelve Principles of Agile Software in support of the Agile Manifesto. Together, these provide guidance for all of the individual methodologies that have come to be known as “The Agile Movement.” They describe a culture in which change is welcome, and the customer is the focus of the work.
The Twelve Principles of Agile Software are:
Because Agile isn’t a prescriptive framework or methodology there are many different ways to apply what agile is all about. The concepts in agile have proved to be very popular in software development, project management, IT service management, non-IT product development, procurement, HR, and many other disciplines. In software development, in particular, other movements and frameworks have taken the principles defined in what is agile, and have extended them and adapted them to particular circumstances. The same has happened in project management, where agile methodologies for managing projects are now in wide use.
A large number of frameworks and methodologies that claim to be agile can be confusing, however, this clearly demonstrates the adaptability of agile. This ability to be applied to a wide variety of situations was a fundamental consideration when what has come to be known as agile was first conceived by the Agile Alliance.
The ongoing discussions about agile, what it is, and where it can be adapted and extended, have resulted in a continual evolution of agile and its application, ever since the first definition of agile in the Agile Manifesto and the Twelve Principles of Agile Software. This can be frustrating for those who are used to fixed methodologies, however, it fosters a fundamental aim of agile: the need to continually inspect, reflect, and adapt. Feedback from each iteration of each framework that is founded on agile, both positive and negative, provides the information to shape the next "version". This is an excellent example of the principles defined in agile being used to develop how agile is used in many sectors.
Because agile is based on a set of values and doesn’t prescribe the details of what you should do to be agile, it has resulted in the development and publication of many different frameworks and methodologies, especially in agile software development. Some of these agile approaches, like Scrum and Kanban, have been around for a long time and are in widespread use. Other agile methods, like LeSS (Large Scale Scrum), and SAFe (Scaled Agile Framework) are more recent approaches, derived from the earlier ones, but still very much agile in their nature. All are still aligned with the definition of what agile is that was set down in 2001. All use the agile principles to use small teams, delivering products incrementally in short iterations, focusing on the customer, and with an open culture using feedback to continually improve.
The different approaches apply the principles that define what agile is, adapting them to circumstances such as varying sizes of projects and developments, specific sector requirements, and organization size. Some of them are lighter touch than others, which provides a more prescriptive model for how to apply their version of agile. Each of these agile approaches has its own supporters, pros and cons, and often qualification schemes.
There is a view that the schemes that provide qualifications in specific adaptations of agile stifle their development, which is contrary to what agile is all about. However, they provide individuals that want to learn how to be agile with grounding in the definition of agile, with the specifics of each different agile methodology.
The Waterfall approach is much older than Agile and has been traditionally used for large scale software developments for many years. Agile and Waterfall have contrasting cultures, so they cannot be used together. Waterfall, unlike Agile, is a strictly formalized and linear approach to software development. Waterfall starts with the development of a hierarchy of fixed requirements, unlike agile where the requirements are encouraged to change over time. The highest level of requirements in the Waterfall is user requirements, which is the same as in Agile. However, Waterfall describes these in a great deal of detail, unlike Agile that captures them as simple ‘user stories’, in the form of ‘I would like to be able to ….’.
Each successive level of requirements in the Waterfall then goes into the design of more and more detail, the purpose is to define a design for every specialist group involved in each stage of the development and testing. These include usability designs, technical designs, user acceptance test definitions, and program specifications. In contrast, the only documented requirements in Agile are the user requirements. In agile, everything else is deemed to be superfluous as it adds no value. In Agile, the design evolves over time.
This is a typical sequence of events in Waterfall.
In a true Waterfall development project, each of these represents a distinct stage of software development, and each stage generally finishes before the next one can begin. There is also typically a stage gate between each; for example, requirements must be reviewed and approved by the customer before design can begin.
In contrast, the sequence of events in Agile can be summarized like this:
Gather requirements as succinct, discrete user stories and store in the product backlog
Select enough items from the product backlog that can be completed in one increment
Code and test in parallel
Deliver the product increment
Go back to step 2
One of the greatest challenges with Waterfall is that it is difficult to capture a complete and comprehensive set of requirements and detailed designs. Frequently, users don't always really know what they want until they can see it. Customers are not always able to visualize an application from a requirements document. This often means that customers are dissatisfied with products delivered using a waterfall approach. Agile addresses these issues, by first delivering a minimum viable product that the customers can use, then building on it incrementally according to customer feedback and developing requirements.
Lean is a conceptual model that was first developed for use in manufacturing industries. This lean model, like Agile, is based on culture with principles and values. These lean principles and values are very much in line with the principles that set out what agile is. Lean offers additional guidance in techniques and practices that can be applied. Both Lean and Agile share the principle of adding value. Lean in particular focuses on this, with the concept that every activity done in the delivery of a product must add value to it. A consequence of this is that Lean provides many techniques to achieve this, whereas Agile does not specify any specific techniques.
Lean techniques are particularly good at best eliminating or at least reducing waste, known as ‘Muda’ in Lean. Waste is defined as anything that does not add value to the product. This includes queues within processes (whether agile or not), partially completed products that are lying around without any work being done to change them, and any quality inspections. All of these are valuable to apply to any implementation of agile, irrespective of which particular agile approach is adopted. Hence many implementations of Agile have re-interpreted Lean thinking for use in environments and disciplines outside manufacturing.
Here are some of the things that differentiate Lean from Agile:
Lean is mostly applicable for building the same product, or doing the same thing, over and over again. Agile is better suited to building something for the first time, every time.
Lean has a different set of principles to Agile, although they can be used very effectively to supplement the Agile principles. Lean principles include Eliminate waste, Amplify learning, Decide as late as possible, Deliver as fast as possible, Empower the team, Build integrity and See the whole. As you can see, many of these align 100% with the principles that define what agile is.
Agile focuses on users and delivery of value to them, whereas Lean focusses on the identification and removal of waste.
The principles of agile deliver primarily in terms of the product whereas Lean principles deliver primarily in terms of value.
Lean has cost-cutting techniques in its model, Agile has no mention of this.
Agile allows for high levels of uncertainty and ambiguity whereas Lean relies on repeatable known activities.
Agile gives more value to working products whereas Lean gives more value to the process by eliminating the waste that is of no use.
Agile implementations have short, iterative development steps whereas Lean has flow management which reduces the number of workflows in progress at any one time.
DevOps is an adaption of Agile that blends the activities of two stages of a product lifecycle into one. Dev refers to the Development under agile principles, and Ops refers to IT Operations once the product has been put live. Operations in DevOps can also be interpreted as after-sales service, including support and service management, but using agile instead of traditional fixed and hierarchical approaches. DevOps includes applying agile to fault finding, bug fixing, and adding new features after the initial application has been developed.
In some ways, DevOps can be seen as an incarnation of the Agile principles that applies across the full lifecycle of IT products. Because Agile itself is conceptual, it can be challenging to implement as it requires the interpretation and development of ways of working that are agile. DevOps thinking has already developed these, including valuable agile techniques such as continuous delivery.
The DevOps movement places a heavy emphasis on tools, whereas the definition of what is agile has no mention of tools. DevOps tools include code repositories, automatic testing tools, deployment tools, and monitoring tools.
Continuous delivery is a particularly useful variant of Agile and DevOps. It requires tools so that every code change is automatically tested against a comprehensive set of tests (1000’s rather than 100’s) and automatically rejected is any test fails. This requires a code repository tool with concrete version control, and the ability to check-out code, work on it, then check-in the changes. For truly agile continuous delivery and DevOps, this testing is triggered automatically.
Another example of where DevOps demonstrates the application of the principles of what is agile is automatic monitoring and self-healing. This is an application of agile to the operations side of DevOps. The health of the live system is continually monitored by tools, often simulating user activity to get a true picture of how the system is behaving. This is commonplace in non-agile systems, but when used in agile way rules are scripted into the tools, with assigned actions depending on the precise circumstances. The agile application of these tools can then invoke specific actions to preserve the availability and performance of systems, for example by switching from a potential faulty server to a backup one, or by automatically increasing the capacity to forestall any performance issues. This is an excellent example of agile principles being applied.
Kanban is a system for agile workflow and process management that provides visual signals to communicate information in order to improve efficiency and effectiveness. Kanban is used in many sectors including manufacturing, process improvement, agile software development, and ITSM. Kanban is particularly used in Lean agile systems, as it provides a simple and understandable way to identify waste, especially bottlenecks between the different steps in an end-to-end process.
The principles of Kanban are very much aligned to the principles included in the definition of what is agile:
Kanban visualizes the workflow so that it is easy to understand
Kanban encourages acts of leadership at all levels
Kanban helps to measure and improve collaboration
Kanban encourages respect for the process, roles & responsibilities
Kanban helps the team to make the process explicit and easy to understand
The term word Kanban is Japanese for ‘signboard’. In applications of agile, Kanban is also used as the term to describe a visual system to display tasks, their status, and their progress towards completion. This Kanban Board uses different columns and colors to differentiate between different types of task and their status. This is the most used form of Kanban in agile approaches.
This Kanban Board plays a vital role in displaying the workflow of tasks in agile approaches. It helps to achieve the principles of agile by optimizing the flow of task between different teams, and between different stages. Kanban Boards as a useful method for defining, managing and improving services, working in an agile way. BY displaying work items visually on the Kanban Board, team members can see the state of every piece of work at every development stage, and get a common understanding. Moreover, a team member gets an overview of who is doing what so that they can identify and eliminate problem areas in the agile process.
Like all agile approaches, the Kanban methodology allows work to be prioritized according to the needs of the customers. As work moves from one state to another, extra work can also be added from the backlog to maintain a steady flow of work through the system. The agile team members collaborate with each other to improve the flow of work throughout the project. Kanban boards are commonly used in conjunction with the agile Scrum approach to display progress and support discussions at the daily sprint meetings. However, Kanban is an agile approach that differs from Scrum, as the process is never restricted to a set process or a defined sprint backlog. Kanban is more aligned with the aim of what is agile, to maintain flexibility.
Prince2 is the world's most widely-recognized project management methodology. Until recently, PRINCE2 used a waterfall approach to managing projects. There is now a variant of PRINCE that has embraced Agile principles. This new application of what is agile to project management is rapidly becoming the standard approach for managing projects.
Before this new variant, there was considerable debate about whether PRINCE2 or Agile methods were best for projects. The answer depended on many factors, including the type of project, the expected duration, the likelihood of changes to requirements, and knowledge of the agile principles. Even when PRINCE2 was being rigidly applied, it was still possible for agile techniques to be used within the project workstreams by individuals who were committed to the principles of Agile. Today, both PRINCE2 and Agile are being used on projects, often together. The rise of agile project management methods may soon overtake PRINCE2.
The most fundamental difference between PRINCE2 and Agile is that PRINCE2 is primarily and historically a project management methodology, whereas Agile is a set of principles initially applied to software development but now used in many other disciplines.
PRINCE2 is a project management methodology that, like Agile, aims to focus on the customer. Like Agile, PRINCE2 offers a set of principles. However, unlike Agile, it also prescribes terminology, artifacts, and processes to enable the justification, specification, management, and delivery of a project. PRINCE2 is based upon a set of 7 principles that guide all aspects of the methodology. IN key contrast to Agile, PRINCE2 specifies the project management roles and responsibilities of all members of the project management team, including higher levels such as the project board, as well as the project manager and team manager roles. Agile does not go beyond expressing the principles. The organization adopting agile is then free to define the roles and responsibilities that are most appropriate for them.
One key difference between PRINCE2 and Agile methods is that PRINCE2 is often described as a predictive (plan-based) approach, while Agile calls for short-term, incremental achievements independent of an over-arching plan (the adaptive approach). This means that, while PRINCE2 enables the customer to remain focused on the project’s original business goals, Agile approaches are very responsive to changes in the project environment and customer requirements.
The most important thing to consider before you implement agile is your ability and desire to transform the culture across your whole organization. Adopting agile requires open minds that are prepared for change. This aspect of agile can frighten the types of individuals who expect certainty in everything. Agile also requires collaborative team working, where every team member supports their colleagues, there are no ‘bosses’, and lessons are learned after issues rather than blame being apportioned. This can be a major change for an organization that has been used to autocratic and hierarchical management, using task-oriented instructions.
Any implementation of agile must therefore by supported by an aligned organizational change management (OCM) initiative. The OCM activities can and should themselves be done in an agile way, recognizing that every organization and every individual are different and that there is no single prescribed approach to get to a culture that is suitable for agile working.
Agile requires customers to work as part of the agile delivery teams, with frequent and early opportunities to see the work being delivered, so that they are part of the process to make decisions and changes throughout the agile development project. These customers need to be prepared for this involvement, as some customers might not have the time or interest necessary for success with agile.
In a similar way, Agile requires full dedication by all team members to the culture of agile, working together towards a common goal. Before starting to implement Agile you should consider the capability of your individual team members to work in this way. There is a risk that some might not want to work in agile ways, as they are more comfortable with non-agile fixed approaches. You should what you can do with these individuals. Education and training in agile are an approach, but if that fails you may need to re-deploy staff.
You will need to review the different agile approaches that are available and decide which is best for you. This selection should be done carefully, otherwise, your investment in agile may be wasted if you make an inappropriate choice. Hence you need to budget for and plan for up-front education of key individuals on the wide variety of agile approaches. While you may get some help from external agile consultants, selecting the best agile approach requires knowledge of your organization, products, values, and existing culture, as well as knowledge of what agile is.
When making the selection of the most appropriate agile approach, you must look beyond the jargon and product marketing. Agile does not come in a shrink-wrapped box, with regular updates. Agile is a concept that can be of immense value to your organization, but changing to be agile will require a lot of dedication and hard work. You should view your implementation of Agile as a new adventure. You are likely to have challenges in the initial stages of agile, which you may need help with to fix, but ultimately moving to agile can only be done by your own staff. This will require open minds, flexibility, and above all a focus on the customer. All of these are of course the fundamental principles that define what agile is. Trying to stick to a fixed timetable for implementing Agile is likely to lead to failure
Have someone in your organization that is an evangelist for what is agile. They should be prepared to lead the transformation to agile, but be a good listener too. Following the agile principle of asking for feedback, and acting on it, is fundamental to a successful implementation of Agile.
Some Agile approaches, for example, Scrum, define particular agile roles that need to be in place. But just having these roles in place doesn’t mean that a team is agile. Put simply, an agile team is one that follows the agile principles. So, an agile team is one that works collaboratively, focusing on delivering working products the customer wants, at pace.
You can soon spot a team that claims to be agile but in reality, isn’t agile at all. This type of fake agile team will have an obvious boss, one who is in charge and says what needs to be done. In truly agile trams there is no obvious leader. Every member of the agile team is encouraged to contribute views and opinions, from the newest member of the agile team to the longest-serving. Good agile teams respect every individual and will listen to what they have to say.
Good agile teams also demonstrate their commitment both to agile and to the customer. Agile team members will go the extra mile to deliver what is needed. There is a buzz around a good agile team, with lots of activity but very little, if any, negativity. When issues arise, as they always do, good agile teams will get together to discuss the issue in a positive way. Even when the issue is caused by the failure of a team member, the agile culture will ensure a focus on learning the lesson and finding ways to stop it happening again, rather than blaming the individual concerned.
Just about any function of a team can adopt agile in some way. Some may be able to fully embrace agile, especially teams that deliver products such as software, infrastructure, and projects. Others, where the processes have to be more rigid because of legislative or compliance reasons, may not be able to embrace all of the agile principles that define what agile is. However, they can still use the agile principles in parts of what they do to gain the benefits of delivery speed and customer focus.
As an example, consider the processes used for managing releases in IT service management. Where these are releases of safety-critical products, such as in the healthcare sector. There will be tests and checks that are necessary to comply with legislation. While it isn’t feasible to fully embrace agile across the end-to-end process, with the agile team members determining what should be done, agile can still be used in certain parts of the process. Taking the same example, the customers could be invited to describe their requirements for the release in simple ‘user stories’. These can be given to the agile development teams, who can work in short development cycles, delivering solutions to these requirements incrementally. The ITSM team should be part of the development team, working alongside them ensuring that any legislative requirements are built into the product and that satisfactory testing is done before the end of the sprint. This example of the application of agile principles avoids the delays usually found between the completion of development and deployment, caused by the non-agile waterfall culture typically found in most ITSM functions.
Agile can drive an enormous change in the culture of your organization. Following the principles that define what agile is will encourage a focus on the customer and what is important to them. Instead of work happening in a rigorous way based on set plans and rigid, formal approaches, organizations that have embraced the concepts in the Agile principles work in a culture that values collaboration, communication, and trust.
Adopting Agile will move your culture away from one straight-jacketed with up-front planning, analysis paralysis, siloed waterfall approaches to engagement with users, and blame. Instead, Agile will deliver a culture where innovation thrives, where products are delivered frequently, delighting your customers. Agile will lead to an explosion of new products and applications, resulting in a culture that embraces change, instead of resisting it. Adopting agile will transform how you have grown and developed your staff, improved morale and staff retention.
Agile is not a theory that is waiting to be proved, agile is an accepted way of working for now and for the future that can transform your culture for the better.