Projects have been a feature of human development for thousands of years. Think of the pyramids, the Great Wall of China and more recently the Panama Canal. It is only over the last fifty years that the knowledge and learnings from projects have been brought together into a discernable methodology. The project frameworks that have first surfaced were designed for high certainty projects. These definable projects include car production, electrical appliances and the building of a house as examples. These projects usually involve processes that are well understood and usually have low levels of uncertainty and risk.

In more recent times there has been a rise in high uncertainty work. Particularly with the dawn of the information age. With these projects there is a level of problem solving that requires subject matter experts to come together to create solutions. There is almost a sense of exploration where experts are unlocking solutions to develop new products and services. Examples of people working in these uncertain areas include software engineers, product designers and engineers. With this level of uncertainty the traditional project frameworks and methodologies used in the past are unable to cope with the high rates of change, complexity and risk.

The need for a flexible methodology that embraced change and could deal with high levels of complexity and risk are needed. The scene was set when a group of 17 software developers calling themselves the Agile Alliance came together in Snowbird, Utah and developed a defining document of just 68 words titled the Agile Manifesto.

The development of the four values and 12 principles was a pivotal moment, not only for the software and IT industries but for other complex, highly uncertain industries.

For a closer look at the development of the Agile Manifesto follow this link:

The Agile Story

See more

Lean and its relationship with Agile

The benefits of Lean were first brought to life in the Toyota Factory in Japan in the early 1970s. Originally known as just-in-time production, the fundamental principles were to:

• Finds solutions to overburden and stress
• Remove inconsistency
• Eliminate waste

The term Lean was introduced to describe the Toyota business by Jim Womack, Ph.D. at MIT’s International Motor Vehicle Program.

The paper recognised that a lean organisation understands customer value and refines its internal processes to continuously increase that value. The ultimate aim of a Lean philosophy is to provide perfect value to the customer by providing value creation and zero waste.

The relationship with Lean and agile is best visualised in figure 1 below. One way to think about the relationship is to consider Agile methodologies as descendants of the Lean philosophy. So Lean is an umbrella philosophy that shares key attributes with Agile.

The Iterative Approach

The iterative approach is a series of steps that are repeated whilst making small improvements and improving the product with each cycle.

The agile methodology takes that iterative approach to development and brings a level of adaptability throughout the development process. It also provides the opportunity to issue high-impact releases that enable teams to deliver small successes whilst also taking on board the lessons learned.

By using the iterative method it allows teams to:

• Bring a degree of flexibility and resilience as teams learn to adapt to changing circumstances.
• Continue to develop the product with the help of input from stakeholders,
• Build relationships across roles in order to make communication more efficient and effective.

Agile Principles

• An agile project is broken up into segments and incremental steps that include regular feedback intervals
• The segments are broken up into smaller pieces and are prioritised by their importance
• In line with customer feedback, adjustments are made at regular intervals.
• Planning and execution come together which gives project teams more flexibility to respond to changing requirements.

Waterfall vs Agile

Waterfall project management is essentially a traditional methodology where there is a sequential process of initiation, planning and execution. The requirements are clearly articulated at the start of the project and project managers are clear on what the client’s expectations are. The waterfall process aligns well with goals, responsibilities and deadlines. It provides a project with stability and structure, with thorough documentation and predicted resourcing, risk identification and stakeholder communication.

Agile was originally adopted by software teams who moved from the limitations of Waterfall to a method that brings consistent feedback and adjustment throughout the development lifecycle. This occurs as agile teams will follow a sequence that that has small increments and regular feedback loops. Waterfall does not allow the flexibility of agile as it has a clearly defined set of phases and once each phase is complete it is difficult and costly to revisit a previous stage.

The waterfall technique is best suited for work that is predictable, has recurring phases and strict time schedules. The construction and event management industries come to mind as two examples of this.

Agile Flexibility and Stability

So we have seen that Agile brings greater flexibility and stability than traditional frameworks.

When a project begins that has a high level of uncertainty, there are two challenges that project practitioners will face:

• There is limited knowledge on how the final product will look
• The project team cannot predict the future.

The uncertainty with these projects almost guarantees project change. The fourth core value of the agile manifesto stated “responding to change over following a plan”, therefore the agile framework was created with flexibility in mind.

Some examples of processes that help agile teams to manage change include:

• Gathering a high-level set of product requirements from project stakeholders and prioritizing them. All requirements are not necessary, only those that give the product owner a sense of what is required.
• The development team and the product owner work together to break down the highest-priority requirements into smaller segments. The development team can start on these immediately.
• The focus for the development team is on the top priorities in each sprint no matter how recent those priorities were set.

Iterations or sprints last from 2- 5 weeks. The development team works on its highest priorities through the sprint and develops learnings with each iteration

• When changes arise, the product owner will update the requirements, and these will be attended to at the next sprint.
• The team and product owner collect client feedback at the end of each sprint, and they act on that feedback. The importance of the feedback is a key part of the process as it may bring change to existing functionality or to new requirements. The feedback may also mean a reprioritizing of requirements that may no longer be necessary.

The importance of the Agile framework is that it provides a constant cycle of development, feedback and change. It gives project teams the ability to create products with the right features but still with the stability to be creative.