What is Agility

Agility in terms of business or product development can be thought of as the ability to adapt quickly to change, and thus take advantage of the opportunities that change brings. Technology and IT have been major facilitators for disruption, the rate of change has accelerated significantly in the 2000s and continues to accelerate.

Businesses increase their agility by cultivating an agile culture and employing agile methods for product or service development.

Some of the key factors of an agile business are:

• Customer centric
• Continuous improvement
• Incremental approach
• Value focused
• Transparent

It is important to realize that agility is both a culture and a way of thinking and a software development method which when used together form a much more powerful organization for delivery on its mission and vision. Since agility is dependent on the business culture and nature, different businesses generally have different levels agility.

Why is Agility important

Technology is a driver for the speed and frequency of significant changes in the world. Access to communication tools, such as social media, on a world-wide basis has increased the scope of change to global markets. This results in these markets being more volatile and prone to disruption.

The challenge for business is to adapt as quickly as they can to the changing world around them. Therefore, agility is a key factor to ensure that a business remains competitive.

The customer centric nature of agile methods, helps to ensure that the development of products or services meet customer expectations, and provide a clear value to the customer and the business.

Another aspect of agility is continuous improvement and a focus on delivery in increments. Performing regular evaluations of the working method and suggesting improvements can help to improve productivity and quality. Focus on incremental delivery also provides a clear way of measuring progress, this creates forward momentum which is a highly motivating factor for teams.

Agility Approach

Know the constraints

Before embarking on an agile journey be aware of the constraints of the business. When making changes to a business for agility and developing agile methods, awareness of the business limitations helps to adapt any changes to fit the business in its current state. Trying to force changes or agile methods on a business without considering constraints can have adverse effects, such as stakeholders turning against the initiative, or agile disillusionment when results do not meet expectations.

Move at the right pace

The maturity and current agility of any given business is likely to affect how quickly changes in the working process can be achieved. In less mature businesses it may be reasonable to start with simple agile practices, while in businesses already running agile practices more advanced techniques may be attempted. The key factor is to ensure that the implementation of agile practices is in pace with the ability of the business to change and accept these practices.

Customer centric

Agile practices work best when there is a close relationship with the customer. Regular feedback from the customer allows development teams to tailor the product or services as they go according to the customers’ expectations. This ultimately results in a higher level of customer satisfaction. In order to achieve this, there is great importance placed on the relationship between the customer and the team.

Just in time and one at a time

Agile practices tend to focus on performing one or a very few tasks at a time. This way the likelihood of delivering a usable product is increased. That is to say, that it is better to deliver 3 fully complete tasks out of 5 tasks than to deliver 5 partly complete tasks. The idea is that it is better to have 3 tasks that can actually be delivered, than 5 tasks that cannot.

Another aspect of agile practices is to make decisions just-in-time. This ensures that there is time to gather information to support decisions and reduces the scope for assumptions. This is in-line with reducing the planning-up-front. While this is a good principal, it is important to realize that just-in-time for some decisions might actually mean they have to be made well in advance, thus introducing planning-up-front.

Automation is key

A key part of improving agility is automation, particularly in product development. Adopting agile practices with a low level of automation reduces the ability to make quick changes. This is evident in software development where in order to deliver working products at every increment the version management, deployment and test cycles have to be executed quickly. Automating version management and deployment through continuous integration provides a means of quickly making releases of the software. Automation of regression testing provides a means of continually checking the effect of changes to the software. This ensures that any adverse effects on functions which have already been implemented in previous increments can be detected.

Agile Methods

Agile methods provide processes and tools which help to increase the agility of an organisation. These methods originate in modern times from the manufacturing industry where the car company Toyota is merited as a cornerstone for lean and agile practices.

Agile software development methodologies gained popularity in the early 2000s, these methods are widely used in the industry and the broad principles of agile methods may be considered a de-facto standard in the industry.

Agile methods have expanded their scope to consider not just the development of software, but the agility of the business.

This article does not go in to detail regarding specific agile methods, since there is a sea of information widely available for further reading on the subject. Instead, the following is a short description of the essential aspects of agile and the most popular agile methods.

Essential Agile

The core of agile methods is the execution of a continuous series of increments which deliver a working product. These increments can be thought of as having three important stages: planning, execution and evaluation.

The planning and prioritization of work in agile methods is often performed in a backlog. The role of Product Owner is responsible for the backlog and decides what is to be done and in which order. The Product Owner can split the backlog up into a series of increments which are executed over a fixed period of time. The Agile Team is responsible for delivering an increment, and the contents of the increment are agreed upon between the Agile Team and the Product Owner, according to what the team feel they can manage to deliver. Once the Agile Team commit to delivering the agreed contents, the execution of increment starts and development of the product features begin. At the end of the execution an evaluation of the increment is performed via a demonstration to the customer and a team retrospective. Improvements are suggested which are fed into the next increment.

It is also worth mentioning the term Minimal Viable Product (or MVP), which is an important factor for agility. What this means, is that the focus is place on delivering a working product with the minimal features required to satisfy the customer needs. This avoids planning for perfection which increases lead time to delivery. Using the MVP principle, it becomes feasible to release working software within an increment. The customer can actively see the result and suggest changes or improvements. This way the product evolves according to the customer expectations, rather than trying to second guess the customer expectations in extended functional design activities or very detailed requirements.

Kanban

Kanban is an agile method which is used when planning a continuous flow of work. Work items are fed into a backlog where they are prioritized for work. Highly prioritized items are picked from the top of the backlog by the team, and placed on a Kanban board which shows the flow of the work item. The team work the item through the flow until it is delivered. Once an item is delivered the team pick a new item to work with. Periodically the team will review the current situation and suggest improvements, through a retrospect.

The Kanban method is particularly suited to scenarios where work items are difficult to plan up front and require a quick response. For example, in customer support organizations where issues may be submitted at any point in time and they must be delt with as quickly as possible.

Further information regarding Kanban can be found at the www.agilealliance.org .

Scrum

Scrum is an agile method which is used to incrementally develop complex products. The scope of the product is defined in the product backlog, and work items (often termed as user stories) are prioritized by the product owner. The work to deliver the items is performed in set increments called sprints which are executed over a specific time period (often 2-3 weeks). Sprint planning is performed before each sprint to decide which work items from the product backlog can be completed in the sprint, this is a dialog between the product owner and the scrum team, and this forms the scope of the sprint. At the end of the sprint planning the scrum team is committed to delivering the agreed scope of the sprint.

The sprint starts and the work items are placed on a scrum board where they can be seen by all, and the scrum team can change the status of the work items as they go. Status of the sprint is communicated daily with a short meeting called a Daily Stand.

At the end of the sprint the result is presented in a demonstration to gain feedback from the product owner and other stakeholders. A retrospect is held by the scrum team to examine what went well with the sprint, and what can be improved in the next sprint.

The Scrum method is particularly suited to building products where some idea of the requirements or scope are available in advance, and where work can be performed and delivered in a short period of time. This is very much suited to software development where the features of a product can be developed step by step in short increments.

Further information regarding Scrum can be found at Scrum.org .

SAFe (Scaled Agile Framework)

The former Agile methods are often focused on software development or devops. However, these methods may be used in a business environment where other business activities such as strategic planning or portfolio management are run in a traditional fashion. SAFe is an agile method which attempts to address the “big picture” taking an enterprise view of agility.
The method provides a framework for scaling agility to manage portfolios, large solutions and the essential methods for delivering a solution release.

At the portfolio level, the framework covers areas such as strategic themes, portfolio vision, budgets and KPI’s. The portfolio level is where the Enterprise Architect is most active. This feeds into the large solution level which aligns with the portfolio. At this level a backlog of solutions is maintained and a solution roadmap which can be used to visualize solution delivery over time. This is the level where the solution architect is most active. The essential level is mainly concerned with the delivery of product releases which contribute to a complete solution delivery, this level is where the products are built according to the requirements for the release. The Scrum or Kanban are methods which can be used at the essential level.

Further information regarding SAFe can be found at www.scaledagileframework.com .

When considering the above methods, it is important to treat them as frameworks rather than “by-the-book” methods. Adapting these methods “out of the box” may not automatically improve agility. No two businesses are the same, and agile methods almost always require some kind of adaption to best fit the business. When considering using agile methods, the key factor is that the business improves its agility, rather than rigidly applying a particular agile method.

Constraints on Agility

When embarking on a journey to improve business or product development agility, one of the most important things to consider are the business constraints. Ignoring the business constraints may result in agile methods not working, sub-optimal results or disillusionment with the agile approach. Some constraints may be removed, but the process of removing these constraints may well be long-term and costly. The existence of these constraints doesn’t mean that the business cannot improve its agility or use agile methods, rather that the business has to account for the constraints when developing and adapting agile methods. The following sections describe some of the common constraints on agility.

Fixed contract business models

Agility relies on the ability to adapt as the surrounding world changes. Agile methods often rely on a high degree of flexibility in the business model.

For example, a product development team may run a series of sprints. The product owner may decide to release the product with the scope that was delivered during these sprints. However, if it is felt that the scope does not provide a minimum viable product, then further sprints can be run until a minimum viable product or release is achieved. This means that there has to be flexibility in time, cost and scope.

If we consider the “iron triangle” of project management we can see that there is a relation between cost, time and scope. The following scenarios apply:

• Increase scope = increased cost or time
• Reduced cost = increased time or reduced scope
• Reduced time = reduced scope or increase cost

Agile methods work best when there is flexibility in scope, cost and time. This can work well where the business has full control of these factors, for example, when delivering products or services to a broad market of customers.

However, many businesses have fixed contract models with their customers, especially where the products or services being provided are of a complex nature. These contracts may set constraints on the scope, cost or time for product or service development thus reducing agility.

While agile methods may be used to improve agility, it is likely that up front planning is required to reduce risk, reach agreement between the parties and agree legal terms. Traditional project methods can be combined with agile methods to ensure adherence to any contractual obligations.

Heavily regulated industries

Heavily regulated industries have to adhere to stringent requirements which are non-negotiable. If the requirements are not fulfilled there can be severe consequences for the release of the product. Examples of such industries are medical/healthcare, aerospace, nuclear power or defense.

Since regulation is so critical to the product, substantial planning up front is required to interpret the regulation and mitigate risk. This is often required since regulations may affect the very foundations of the architecture, and changing this after development has started is both difficult and costly.

There also has to be assurance of the product according to regulations, and this normally incurs substantial quality assurance activities prior to delivery.

The regulation has an impact on agility since it is non-negotiable and has to be accounted for in the event of proposed changes. The up-front planning and substantial requirement for quality assurance also impacts agility.

Culture and agile maturity

A business culture is built up over many years and is often difficult to change. Assessing the agile maturity of a business is essential to ensuring that any new methods are a success. The pace of change to agile methods has to suit the ability of the organization to cope with the change. For example, businesses with little or no experience in agile methods have to be given time to adapt, and perhaps start with the basics before exposing the organization to more advanced concepts. Moving too quickly may lead to the organization resisting agile practices, and can result in disillusionment with the methods.

A key factor in promoting agile practices to the organization is to gain the trust of important stakeholders. This can help to drive changes in culture and promote the positive results of agile practices. The use of agile practices can then begin to grow naturally into the culture over time.

Legacy systems

Many businesses have legacy systems in their IT-landscape which often perform essential functions for the business. These systems often remain active since the cost to replace the system outweighs the perceived benefits of migrating to modern technology, or simply that investment is prioritized to other initiatives. Since legacy systems are often difficult to change, they have a significant impact on agility. The difficulty in implementing changes can be a result of legacy technologies or lack of automation in the development process, for example, low levels of automated testing or continuous integration.

Of course, to increase agility it would be best to modernize legacy systems but this is not always feasible. One strategy is to encapsulate the legacy system with a modern technology, thus reducing the reach of the legacy system until it can eventually be replaced. This can reduce the constraint on agility, however significant consideration should be given to legacy systems when developing agile practices.

Limited access to customer or sponsor

Agile practices rely on a closeness to the customer or sponsor to gain quick feedback about progress and to gain support for decisions. In some cases, the customer may have a reduced availability, perhaps due to other priorities, shortage of time or that the business culture is unfamiliar with that way of working. This has a significant effect on agility since it will likely lead to the team making assumptions in the absence of the customer, which can in turn result in re-work later when these assumptions are shown to be incorrect. Another effect is the speed at which decisions can be taken, this is likely to reduce the productivity or velocity of the team.

One way to reduce the effect of this constraint, is to appoint an internal sponsor to the team who acts on behalf of the customer. The internal sponsor can schedule meetings with the customer to gain requirements and feedback. At the same time, the internal sponsor may also have a mandate from the customer to help in the decision-making process.

Architecture and Agility

The origins of agile methods are born out of the manufacturing industry where just-in-time, quality and continual improvement are key factors. This is based on a process of Plan-Do-Check-Adjust (PDCA) which iterates in short cycles to continually improve and adapt. However, if we compare agile practices with manufacturing, it is often forgotten that a substantial amount of time has been spent designing the product before it even hits the production lines. For example, creating a new car model requires a lot of design up front before prototyping starts, this is because it is too expensive to make substantial changes after the prototype car is built, and it is too expensive to make the car adaptable for all types of designs. When a car is designed around a particular set of components, for example the engine, this is unlikely to be significantly changed later in the process since this would incur great effort, however the design may be refined. Equally, it might incur a great effort and cost to design a car which is adaptable to several engine models. Therefore, the decision on which model of engine to use in the car is a major decision, which has to be taken long before the car reaches production.

In this respect, a major part of architecture can be thought of as creating the fundamental designs which include the major decisions, upon which other designs are built. Just as with the major decisions which are required to design a car model, the significant architecture decisions are often assessed and taken long before the architecture goes into production.

Perhaps the most important part of working with an architecture is making the decisions which are key to the business and difficult to change after implementation has begun. This is where there is friction between agile methods and architecture. Agile methods aim to take decisions as late in the process as possible and reduce planning up front, this places the focus on getting a working implementation. However, there is a need in architecture to consider the long term, and identify principles and designs which provide a foundation to all future designs, this requires planning up front since these foundations are very difficult to change later in the process.

This can be seen in the case of enterprise architecture which often has a wide scope. This means that changes made to the enterprise architecture are likely to have a very broad effect. This requires planning up front as the implementation of enterprise-wide changes often require substantial effort, and the consequences of getting it wrong can be severe. Therefore, using agile methods to develop an enterprise architecture is very challenging.

Using agile methods with solution architectures can also be challenging, consider the quality attributes of an architecture, for example, performance, scalability, security, reliability, testability, etc… These often provide a foundation and drive for the designs that will be built on the architecture, and cannot easily be changed after implementation starts. If the architecture foundation is unstable, then the designs based upon the architecture will also be unstable.

For example, when architecting for security, we build the required security into the architecture foundations as it will flow through all aspects of the future designs. Trying to bolt security on to an architecture at a later stage may result in major re-work of designs and implementations, or result in the required level of security being unachievable. In severe cases, this may result in the failure of the solution or significant financial costs if security fails when the system is in operation.

The following are other areas which are key to an architecture but are difficult to approach in an agile fashion:

• Solution Components – decisions regarding the major solution components such as, databases, development environments and operating systems
• Architecture patterns – decisions made to follow specific architecture patterns such as SOA, Microservices, MVC, etc…
• Legal or Regulatory Requirements – decisions which account for legal or regulatory requirements in the architecture

It is equally important to realize that all aspects of the architecture do not need to be planned up front. Some aspects of the architecture can be developed in harmony with the solution or enterprise as a refinement of the architecture. It is important to get this balance right, in order to ensure that aspects of the architecture which are difficult to change and from a key foundation to designs are planned up front, while other aspects that are perhaps more adaptable can be planned closer to implementation.

References and further reading

Business Agility Manifesto
https://busagilitymanifesto.org/

Scrum.org
https://www.scrum.org/

Agile Alliance
https://www.agilealliance.org/

SAFe
https://www.scaledagileframework.com/

Villanovau University
https://www.villanovau.com/resources/project-management/iron-triangle-project-management/