For many, the future of project management is agile. But what does ‘agile’ actually mean?
Read this eBook if you want to learn all about the agile philosophy and which particular method suits your own project management needs.
What do we mean by agile?
Broadly speaking, agile methods put an emphasis on delivering projects in increments with regular stakeholder and team consultation. This approach enables the team to adapt the product to the customer’s specification and any changes made can be handled efficiently.
Agile methods have the following characteristics:
- Iterative and incremental delivery – agile projects are split into short iterations, normally taking a matter of weeks (or even less) to complete. At the end of each iteration, part of the product (an increment) is expected to be finished, ready for testing and for the customer to review.
- Regular stakeholder consultation – the customer is closely engaged with the project and receives regular feedback. This leads to increased customer satisfaction as it can see the progress being made and make suggestions for change.
- Change and adaptation – because the product is developed and delivered incrementally, change is easy to track and implement. In fact, the requirements in agile projects are expected to change and evolve over time.
- Empowered teams – agile teams tend to have an inverted management pyramid with no ‘command and control’ leadership. Because of this, agile teams collaborate and work strongly together. They feel free to do whatever they want in order to achieve their aim.
- Regular communication – face-to-face communication is preferred and casual team meetings are held called ‘stand ups’. Agile projects also have less documentation than traditional project methods.
Let’s now look at why agile was developed and the problems it was intended to solve.
History of agile
The history of agile techniques stretches back surprisingly far.
Back in the 1950s, IBM programmers were working on defence software so complicated that it simply had to be built gradually. Each completed section required testing before they could move on and add extra details. This method of project management is known in its basic form as iterative and incremental development (IID). In the 1960s, NASA also used this method on Project Mercury. The project was split into very small iterations and modifications to the spacecraft were made after intense testing.
During the 1970s, IID began to evolve even further. A heavy rejection of traditional project management led to computer scientists creating new techniques which laid the foundations for modern agile methods.
In 1970, Winston Royce published ‘Managing the Development of Large Software Systems’. In this paper, he criticised the common software development model used at the time (what we call ‘waterfall’) and argued for an iterative method instead. He also stressed the importance of involving the customer and rigorous testing, which are two other characteristics of current agile methods. Later in the 70s, both NASA and the US Army used IID on their projects. The benefits of iterative project management were obviously being realised and traditional waterfall approaches were on the way out.
But it wasn’t only large organisations in America that recognised the benefits of an IID approach. During the 1980s, the Japanese car giant Toyota pioneered the Toyota Production System (TPS).
The main objective of TPS is to make what is needed, when it is needed and in the amount needed. Waste, inconsistencies and overburden are to be avoided; continuous improvement, respect for people, staff development and using the best system you can, are to be sought.
One of the stand-out principles of TPS is that of continuous improvement or ‘kaizen’. When any team member suggests an improvement, a cycle known as ‘Plan, Do, Check, Act’ is started. This strategy for making changes and empowering the team is in fact an essential characteristic of many modern agile methods.
In the 1990s, three researchers from the Massachusetts Institute of Technology (MIT) released a book called ‘The Machine That Changed the World’, which concluded that the TPS approach was much more effective than Western methods. In the book, the researchers coined the term ‘lean’ to describe the TPS method.
It is safe to say that the 1990s marked a huge turning point for agile methods. As organisations worldwide began to realise the benefits of lean methods, its use became widespread in sectors outside manufacturing. The IT world in particular took notice. Lean ideas were fused with established iterative approaches, and well-known agile methods such as Scrum, Extreme Programming (XP), Dynamic Systems Development Method (DSDM) and Adaptive Software Development (ASD) were born.
Agile as a term came about in 2001, when prominent advocates from the above methods (Scrum etc.) held a meeting to find common ground and find an alternative to software development methods at the time. They named themselves The Agile Alliance and wrote the Manifesto for Agile Software Development (or Agile Manifesto for short).
According to the manifesto, successful software development should disregard strict processes, planning and documentation. Instead, teams should aim for customer collaboration, adaptation to change, strong communication, respect for individuals and actual working software.
The Agile Manifesto is the basis for modern agile methodologies and their subsequent training courses. Combining already established ideas regarding incremental development, Toyota’s philosophy and lean methods, the manifesto finally bought everything together under one set of values.
Popular agile methods
The majority of agile methods became established during the 1990s and 2000s. Their origins within the software development industry meant they weren’t initially well-known or widely used. However, agile methods are now used to manage projects in many different industries worldwide. Their use in marketing and the creative digital industries is especially noticeable.
We will now examine three of the most popular agile methodologies, so you can decide for yourself which one is best for you.
The term ‘scrum’ was initially used in the 1980s by two Japanese theorists, Hirotaka Takeuchi and Ikujiro Nonaka, in their publication ‘The New New Product Development Game’. This paper described how product development teams should work very closely together, like the players in a game of rugby (hence the term scrum). Takeuchi and Nonaka also believed teams should be given objectives rather than tasks, as well as the freedom to do whatever necessary to achieve those objectives.
Scrum was properly defined and put into use properly during the 1990s, by Ken Schwaber and Jeff Sutherland, both signatories of the Agile Manifesto and creators of the Scrum Guide. Scrum is now a very popular method used in many different industries worldwide. It gives project teams a simple framework to use on any project, no matter how big or complex.
Scrum teams are small and tightly knit, with no reliance on anyone outside the team. These teams consist of the Product Owner, Development Team and Scrum Master. Scrum teams are empowered, self-organizing and communicate regularly. They also deliver projects in increments, within set time limits. Here’s how Scrum works:
- The Product Owner liaises with the customer and is responsible for something called the Product Backlog. This log is a list of prioritised objectives that must be completed by the Development Team. During a Sprint Planning meeting, the team chooses items from the Product Backlog and decides how to get them done.
- The team are given a timeframe or iteration called a Sprint, which details how long they have to get the work done. The team have daily meetings, called Scrums, in which the Scrum Master is also present. The Scrum Master is responsible for ensuring Scrum is being implemented properly across the entire team.
- At the end of a Sprint, the work should be ready for use. The team then conducts a Sprint Review and Retrospective. The Sprint Review allows everyone (including stakeholders) to inspect the completed work and adapt if required, whereas the Retrospective allows the team to assess their performance on the last Sprint and improve if necessary.
- The team then go back to the Product Backlog and select the next items to complete, which starts the cycle all over again.
Projects using Scrum experience a quick product turnaround time, leading to high customer satisfaction and an increased return on investment. Scrum teams achieve a quick turnaround due to their high levels of communication, collaboration and an iterative delivery approach.
Keeping everyone informed and working to a common goal ensures the team keep control of the project, which minimises risk. Daily Scrums and a self-managing mind-set also increase freedom and morale.
Delivering in increments means closer monitoring, which leads to a reduction in risk and a speedy turnaround time. Projects have a higher chance of being delivered on time and within budget.
Scrum embodies the values of the Agile Manifesto and adopting it may require a change in office culture. For instance, the lack of managers required by Scrum would certainly put a lot of traditional companies off.
Relying on the team to self-manage has its pitfalls. As Scrum teams work as a unit to complete Sprints, just one disorganised or unmotivated individual could ruin the entire Sprint, or even the entire project. Training can help eliminate this issue, but this can be costly.
This huge reliance on team work also makes Scrum unsuitable for large or dispersed teams, where it isn’t so easy to hold daily Scrums, communicate regularly or work closely together.
Scrum training comes in the form of Scrum Foundations, Scrum Master, Scrum Product Owner, Scrum Developer and Scrum Professional.
You can find accredited training providers through Scrum Alliance, the official accreditation body for Scrum courses. Please visit their website: https://www.scrumalliance.org/
Dynamic systems development method (DSDM)
The IT industry rapidly changed during the 1990s. Prototyping became possible, which helped both developer and customer track project progress.
Combined with the shift away from traditional project delivery methods, prototyping lead to birth of software development method Rapid Application Development (RAD). This method involves a very minimal planning phase, followed by a continuous user design phase (where the customer can use prototypes). Once the customer approves the product, it goes through testing and implementing stages.
Although revolutionary, RAD lacked structure and was too focused on quick fixes. Many developers felt RAD had to change and become a stronger framework. This lead to a group of software development experts forming the non-profit DSDM Consortium in 1994. They created the DSDM method based on the group’s best-practice experiences.
DSDM incorporates the principles of RAD with a stronger sense of control, quality and detail. It covers the entire lifecycle of a project, enabling project management and product development to be completed as one process. Although having its roots in software development, it can be used to manage many different types of project.
The principles of DSDM are very much the same as the Agile Manifesto. There is an emphasis on customer involvement, team empowerment, simplicity, collaboration, incremental delivery with frequent releases/updates and openness to change. However, DSDM also emphasises a business-driven approach, with development and testing teams working together.
Just like Scrum, DSDM has a variety of roles to be filled by members of the team, these being:
Executive Sponsor – The contributor of money and resources. They will normally be in a position of power within the organisation and be able to make major financial or business-related decisions.
Visionary – The Visionary understands the Sponsor’s needs and conveys these to the team. They stay involved throughout the project, ensuring the objectives laid out in the Business Case are achieved by the team.
Ambassador – Communicates user needs to the development team and reports updates to the user. Should understand the product very well.
Advisors – Team members with strong knowledge in practical areas of the project. These are normally split into Business Advisors, who provide business expertise (e.g. legal advice) or Technical Advisors, who provide specialist technical knowledge (e.g. how to maintain the product).
Project Manager – Oversees the management of development work and testing throughout the project.
DSDM projects consist of seven incremental phases – Pre-project, Feasibility, Foundation, Exploration, Engineering, Deployment and Post-project. A variety of specific techniques are used, such as the MoSCoW prioritisation method, timeboxing, modelling, prototyping and workshops.
Here’s how a DSDM project works:
- Pre-project is a short phase designed to formalise the need for a project. An Executive Sponsor and Visionary should be selected, so it is clear where funding/resources will come from and who is the driving force behind the project.
- Feasibility is an important phase where it is decided if the project is actually possible from a business and technical point of view. What are the benefits? How much will it cost? How long will it take? The project can be terminated at this stage if it isn’t feasible.
- Foundation aims to establish the focus of the project. This is a more detailed phase describing the overall strategy, how risk and quality will be assessed, how technology will be used and how the project will be organised and managed. Roles should also be established. This phase is sometimes merged with Feasibility, especially on smaller projects.
- Exploration is an iterative development phase. This phase produces early releases of the product, which are tested continuously to see if they meet business requirements. It is not expected that this product be ready for release at the end of this phase. This phase is all about testing, changing and evolving.
- Engineering allows for further iterative development. The aim during this phase is for the product to be completely ready for use. By now, there is normally a functioning product, but testing revolves around things like security, performance and how it can be maintained.
- Deployment aims to get the product out for full use. Documentation should be created for maintenance, training or packaging. This phase brings the project to a close and allows for a review of the project team’s performance.
- Post-project acts as a formal reflection on the success of the project. Did it meet the requirements? This should happen when the success can be measured, whether that be a few weeks or months.
DSDM puts the end user in the driving seat. The emphasis on heavy testing and incremental releases ensures the end user has a lot of input regarding how the product evolves. This is great from a customer satisfaction viewpoint.
Techniques such as MoSCoW, are used to help the team prioritise requirements and plan the work effectively, thus enabling faster delivery of prototypes to the customer.
As with other agile methods, DSDM may require a cultural shift at your organisation to make it work. This will inevitably require money for training.
DSDM is quite bulky compared to other agile methods. This is due to the larger amount of project phases and one of the downsides of this is that rather more documentation is required.
For complete knowledge of managing DSDM projects, accredited AgilePM courses are the most popular option. Based on the DSDM framework, AgilePM comes in the form of AgilePM Foundation and AgilePM Practitioner.
APMG International accredit these courses and Knowledge Train is an accredited AgilePM provider. You can find details of our AgilePM courses here: https://www.knowledgetrain.co.uk/courses/agile-project-management
Lean Six Sigma
The Lean Six Sigma approach is actually a combination of two methods – Lean and Six Sigma.
As discussed earlier, Lean ideas come from the Toyota Production System (TPS) developed in Japan. In the 1990s, a book called ‘The Machine That Changed the World’ used the word ‘lean’ to describe the TPS method.
The book concluded that TPS was faster and reduced more waste than car production methods in the West. The manufacturing industry outside Japan started using these new techniques, where it became known as Lean Manufacturing.
Lean values affect the entire company culture. Everyone from the production team, to the managers and administrative staff will use Lean once adopted. Here are the values:
- Continuous improvement – embodied in the Lean term Kaizen, which means ‘change for better’ in Japanese.
- Eliminate waste – anything that doesn’t add value should be eliminated.
- Deliver value to the customer – the end product should be high quality and fall within cost and time limits.
- Respect for employees – teams and individuals should feel empowered, not overworked and undervalued.
- Visual management – think white boards and Post-Its on the wall where everyone can see.
- Simplicity – if something is too complex or a waste of resources, it has no place in your operations.
- Long-term journey – adopting Lean means changing the entire company culture. You must be in it for the long haul.
The first step of Lean is to establish what the customer wants and values. The customer must decide on activities to be added to the Value Stream. These activities must add value by transforming the product, being something the customer is willing to pay for (in time, money or resources) and be done correctly first time around.
Secondly, the team must analyse the Value Stream and decide on what needs to happen to get the product completed for the customer. A ‘flow’ must be established, meaning any activity that is deemed not valuable must be eliminated. Such activities can be defined as Muda (waste of resources), Mura (uneven quality, cost or delivery) or Muri (overwork of people or systems). A visual Value Stream Map is then created for the whole team to see.
Finally, the team can get to work. Supply happens only upon demand, meaning production happens when the customer ‘pulls’. The Kaizen value is very important during this stage, with activities such as ‘Plan Do Check Act’ being implemented to ensure quality is high and waste is reduced.
In contrast, Six Sigma has its roots in the US, where it was developed by Motorola to reduce product defect rates. The underlying principle of Six Sigma is that a business can solve any problem. It achieves this by gathering and analysing data, before implementing a plan or project. Solving problems (whether they are related to the product, service or customer satisfaction) ultimately leads to business success.
The core process used in Six Sigma projects is called Define, Measure, Analyse, Improve & Control (DMAIC). It flows like this:
- Define the problem, goal, resources and project scope. Get a team together.
- Measure, collect data and establish the baseline. Team decide what to measure and how.
- Analyse the data. Identify the root causes and eliminate them.
- Improve by testing and inventing a solution to the problem.
- Control and monitor the improvement. Update business documents, training and processes as necessary.
As you can see, both Lean and Six Sigma complement one another. The idea to fuse both methods together started in the early 2000s with the publication of ‘Leaning Into Six Sigma: A Parable of the Journey to Six Sigma and a Lean Enterprise’. Lean Six Sigma was born and it combines both approaches into one powerful method, which is now popular across a whole range of industries.
Organisations that use Lean Six Sigma reduce waste and solve problems. This increases efficiency and saves money, which leads to higher output, satisfied customers and an increase in revenue.
Eliminating wasteful processes means teams don’t feel overworked. They are free to contribute ideas for continual improvement. Also, the belt qualification framework ensures individuals know their responsibilities. Leaders don’t just lead – they mentor and teach junior staff too.
Just like other agile methods, adopting Lean Six Sigma may require a complete overhaul of office culture. It requires total participation, so any individual or department that isn’t on board means Lean Six Sigma won’t work.
As the focus is on increasing quality, certain products might not benefit from the Lean Six Sigma approach. If your company produces an item that competes with lots of cheap competitors, then quality might not be number one priority.
Individuals or organisations looking to adopt Lean Six Sigma require quite a bit of training. This exists in the form of courses that lead to certification called ‘belts’ - Yellow belt, Green belt, Black belt and Master Black belt.
To find an accredited Lean Six Sigma training course, please contact APMG International, the official accreditation body for Lean Six Sigma in the UK. You can search for providers on their website: http://www.apmg-international.com/
Other agile methods
Lesser-known agile methods include Extreme Programming (XP), Adaptive Software Development (ASD) and Kanban. Let’s find out a bit more about these three methods.
Extreme Programming (XP)
Extreme Programming (XP for short) is an agile method used solely in the software development sector. Based on values of communication, simplicity, feedback, courage and respect, XP projects allow for change by delivering in iterations with frequent testing.
XP describes four activities essential software development: coding, testing, listening and designing. An XP project starts with a simple design and a release schedule, before the project is split into iterations. Each iteration is tested before being released to the customer. Any requested changes then take place in the next iteration.
A unique aspect of XP is Pair Programming, which involves two people writing code at the same computer. This decreases the chance of mistakes and helps to avoid costly revisions later on. Teams often work in one room and, like other agile methods, daily stand up meetings are held.
XP is ideal for small software projects with rapidly changing requirements. The emphasis on communication, feedback and testing ensures cost and time are saved. This leads to high customer satisfaction. However, the open work space and daily meeting culture of XP makes it unsuitable for large or remote teams. XP is also not suited for industries outside the IT industry.
Whilst there are no formal XP qualifications available, the Scrum Developer course teaches XP practices. You can find further information on the official Scrum Alliance website: https://www.scrumalliance.org/
Adaptive Software Development (ASD)
Another method that grew out of RAD was Adaptive Software Development (ASD), which was created by Jim Highsmith in 1999. Based on the idea of constant change, ASD projects have three simple and continuous phases - speculation, collaboration and learning.
The speculation phase involves Adaptive Cycle Planning. This form of planning involves looking at the customer requirements and project constraints (budget, deadlines etc.) before splitting the project into cycles. The project is then initiated.
Once initiated, the team enter the collaboration phase. The team carry out Concurrent Component Engineering, where they work concurrently to deliver the working software. A heavy emphasis is placed on teamwork and communicating with the customer, rather than documenting the fine details of the coding or design.
During the learning phase, the latest release of the software is made available for the customer to test. Any desired changes or bugs that need fixing can be identified for the next cycle. Before starting the next cycle, a thorough quality review is conducted by the team.
ASD is a very loose framework. This can lead to a perceived lack of control and chaotic workplace. Also, not documenting the plan, code or design makes looking back on the project a little difficult.
However, as ASD allows for change, it is ideal for use on projects using new, complex or unpredictable technology. Like other methods, the focus on communication and testing is great from a customer satisfaction viewpoint.
No formal qualifications are available for ASD. However, Jim’s book ‘Adaptive Software Development: A Collaborative Approach to Managing Complex Systems’ is highly recommended.
Developed by Toyota and related to Lean Six Sigma, Kanban is a lean scheduling system. It helps teams understand what to make, how much to make and when to make it. It is very often used alongside other agile methods, such as Scrum.
Kanban uses a visual workflow. The team will have a physical or digital ‘board’ split into columns named ‘to do’, ‘doing’ and ‘done’. Cards representing different products in the backlog are placed into these columns, depending on status.
Each column will have a limit (called a Work In Progress Limit) on the number of products that can be in there at once. This allows the team to visually spot problems in the workflow, called ‘bottlenecks’, and the team can then collaborate and fix the issue. Bottlenecks are to be avoided, as the aim to get work completed swiftly.
The visual aspect of Kanban is a definite advantage, as the entire team can monitor the product backlog. Team members will see exactly what needs to be done, what is currently being worked on and what has been finished. This helps eliminate waste and ensures work is delivered quickly.
However, mistakes can be costly when using Kanban. Teams will need training as errors disrupt the entire workflow. For this reason, Kanban is also not ideal for very large scale projects with many components.
For official Kanban training, the course to go for is the Team Kanban Practitioner (TKP) qualification, which is accredited by Lean Kanban University (LKU). Accredited courses can be found here: http://edu.leankanban.com/certified-training