Agile Project Management

Understanding Agile Project Management

Agile is about consistently delivering value. Specifically, delivering value while being responsive to evolving business needs, changing expectations and customer feedback. Let’s take a look at how it all started. 

History of the Agile Methodology

While the Agile methodology was formally established in February 2001, its foundations were nurtured and tentatively grown over the previous two decades, from Japan to the US. 

Hirotaka Takeuchi and Ikujiro Nonaka were business research academics in Japan. In the 1980s, they observed product development projects at several major Japanese manufacturers (including Fuji-Xerox, Canon and Epson) and eventually published their results in the Harvard Business Review in 1986. 

Their consensus was simple: we had reached a new age of ultra-competitive commercial product development, and the traditional methods were too slow and too inflexible to stay competitive. 

In other words, the Agile philosophy was evolving from necessity. Across the world, consumers were becoming obsessed with new products. There was an emphasis on speed and flexibility for manufacturers; customer expectations were changing more constantly and the “linear” approach to product development—concept development, feasibility testing, product design, development process, pilot production, and final production—had become too slow to keep up. 

By the time a product was painstakingly developed and launched, the appetite from customers had waned. What Takeuchi and Nonaka discovered was that, without any official “methodology”, the leading Japanese manufacturers were already adapting to the change. 

The emergence of early Agile

The two Japanese researchers coined the term “scrum” to describe the collaborative team behavior seen at some of these cutting-edge companies. The metaphor quickly caught the imagination of the product development industry!

Based on far-ranging interviews (from CEOs or low-level engineers) Takeuchi and Nonaka identified six characteristics that were consistent and novel among these organizations that were pushing the envelope: 

  1. Built-in instability—Teams are given challenging development requirements from upper management, such as building a game-changing new product. They’re also given the time and budget to experiment and innovate however they see fit.  
  2. Self-organizing project teams—Project teams can start acting like startup companies. They create their own processes, they take risks and develop their own unique concepts. 
  3. Overlapping development phases—Every element of the project progresses in tandem. This is a stark contrast to the traditional, sequential product development process. 
  4. Multilearning—Team members are encouraged to continuously trial and error new ideas. They also acquire broad knowledge and diverse skills, becoming a more agile and problem-solving team.
  5. Subtle control—There is no direct management or prescribing of tasks to this team. However, there should be regular check-ins and soft controls to ensure the project stays on course. 
  6. Organizational transfer of learning—New knowledge from one project should be transferred around the organization. 

These characteristics laid the foundations for the more sophisticated and structured Agile methodology which was just around the corner. 

The Agile Manifesto

As we’ve seen, toes were dipped into Agile methods throughout the 1980s and 1990s. While some were better documented and developed than others—and many were used successfully for subsequent projects—it wasn’t until 2001 that things really changed. 

A group of 17 ardent researchers met up at a ski resort in Utah to finally crack the nut, as it were, and establish what was and what wasn’t working with these various non-traditional methods. And what they discovered changed the world.  

This group not only established clear, groundbreaking guidelines on how to deliver projects far more effectively than before, they also came up with the name that is still upsetting the natural order to this day: Agile

They formed the Agile Alliance, now a global nonprofit organization of more than 72,000 members devoted to supporting organizations that explore, apply and expand Agile values, principles and practices. 

The four Agile values

The biggest output from this 2001 meet in Utah was the so-called Agile Manifesto. This was a few lines of simple text that outlined the values of the brand-new Agile methodology. As taken from AgileManifesto.org, the Agile Manifesto reads:  

As we’ve seen, toes were dipped into Agile methods throughout the 1980s and 1990s. While some were better documented and developed than others—and many were used successfully for subsequent projects—it wasn’t until 2001 that things really changed. 

A group of 17 ardent researchers met up at a ski resort in Utah to finally crack the nut, as it were, and establish what was and what wasn’t working with these various non-traditional methods. And what they discovered changed the world.  

This group not only established clear, groundbreaking guidelines on how to deliver projects far more effectively than before, they also came up with the name that is still upsetting the natural order to this day: Agile

They formed the Agile Alliance, now a global nonprofit organization of more than 72,000 members devoted to supporting organizations that explore, apply and expand Agile values, principles and practices. 

The four Agile values

The biggest output from this 2001 meet in Utah was the so-called Agile Manifesto. This was a few lines of simple text that outlined the values of the brand-new Agile methodology. As taken from AgileManifesto.org, the Agile Manifesto reads:  

The Agile Manifesto


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

Note: Two decades on, the Agile methodology is deployed in many non-software applications. As such, we will generally be referring to “products” rather than “software” throughout this guide. Adapted Agile methods are common in IT, operations, marketing, HR, sales and other sectors.

The main takeaway is that the manifesto doesn’t call for abandoning all traditional project management methods. In fact, it explicitly states their importance. The difference is a shift in priority towards a new way of thinking; an ethos that essentially puts building the product ahead of following the process. 

Individuals and interactions over processes and tools

The problem with defined processes is that they are inherently self-limiting. They can cap our ability to react and improvise, and reduce the unique impact that every individual is capable of contributing. 

When Dr. Alistair Cockburn observed the most successful and unconventional teams at IBM in the 1990s, he saw that developers spent a lot of time chatting: describing what they were developing, and how, and having active discussions over the project. 

This interpersonal communication—ideally face to face, or Zoom to Zoom—is a backbone of the Agile methodology. It also provides accountability: talking about what they’re about to accomplish makes team members more likely to achieve it. 

Process is vital to the success of projects, especially once scaled to the enterprise level—it’s just secondary to personal interactions and communication. 

Working products over comprehensive documentation

Historically, developing software products required a disproportionate amount of time devoted to documentation. The Agile methodology inverts this entirely, with a significant focus on adding value to the product first and foremost. 

The idea that “there’s no documentation in Agile” is one of the most persistent myths about the entire methodology. Engineers—and, increasingly, professionals from other disciplines adopting the Agile methodology—are not magicians. They can’t hold every task, objective, finding and conversation in their heads. 

Customer collaboration over contract negotiation

Traditional projects are kicked off by signing a highly specific and process-based contract. Changes to the scope of that contract (even if designed to benefit product development) put both sides on the defensive. Re-negotiations would be entered and the discussion would largely focus on changes to cost. 

Agile sought to throw these prolonged and inflexible negotiations out the window. It argues for collaboration with the customer. The product developers should have regular meetings with the customer, sharing their discoveries (positive and negative) and iteratively adjusting product specifications as needed. 

Not only does this create a far superior product for the customer, it can also make for easier and friendlier relationships. 

Responding to change over following a plan 

This builds concretely on the previous value. Rather than blindly “following the agreement” like a headstrong bull, Agile product teams adapt to what’s actually happening. That is: rather than meeting all the objectives agreed with the customer (even if discovered to be unnecessary or sub-optimal) and handing off the product, teams will focus on building the best possible product

That means adapting to roadblocks, finding better ways to achieve the same outcomes, speaking with the customer on suggested scope changes, and acknowledging when a task is likely to waste time. This is probably the most significant departure from traditional product development—and, as we’ll see, an equally significant departure from traditional project management. 

The 12 Principles of Agile

As well as the 4 core values, the early Agile Alliance also drafted a series of “principles” which would guide Agile product development. These principles have always left room for interpretation (since no two projects are the same) and since we’re looking at Agile from the perspective of project management, we have reframed some of the principles accordingly. 

For example, principles #3 “deliver working software frequently” is changed to “deliver value frequently”. 

See below the 12 PM-oriented Agile principles, with their original wordings included for full context. 

#1—Make customer satisfaction your highest priority

This is the yardstick against which all project success will be measured. Not how closely you meet project specifications or the contracted objectives—but how happy the customer is with the final product. 

It’s therefore crucial to understand the customer’s desires at the outset, so that project execution can be geared towards satisfying them as much as possible. 

Original wording: Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

#2—Embrace changing requirements, even late in the game

In traditional PM, last-stage changes can often become heated exchanges centered around scope creep and changing costs. Within the Agile framework, however, requirements and expectations are constantly being revised based on actual project progress. 

Thanks to your established and collaborative contact with the customer (remember your Agile values!) late-stage requests should be welcomed as a way to further improve the product, rather than a hindrance to your intended route. 

Original wording: Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

#3—Deliver value frequently

This corresponds directly with the 1st value of Agile: working products over comprehensive documentation. Perhaps the most famous aspect of the Agile method is continuous delivery. 

In a software context, this means continuously building working pieces of software. In the project management context, it means being able to deliver the customer visible progress at regular intervals. Exactly what this progress looks like will depend on the specific project. 

Original wording: Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

#4—Cross-functional team members should work together

The team members who are creating the value (engineers, designers, developers, etc) should never work in isolation from other stakeholders. There should be constantly flowing contact between the entire team. This not only ensures the project is progressing smoothly, but also increases the odds of delivering exactly what the sales team has promised—and what the customer expects. 

Original wording: Business people and developers must work together daily throughout the project.

#5—Build projects around motivated individuals

In other words, allow individuals to work autonomously. This movement for empowering employees and giving them whatever they need to get the job done (and eliminating micromanagement) feels quite new, but here we see it in the earliest Agile writings. 

The idea is that you’ve hired experts for a reason. Ask them what they need in order to deliver their best work, and then provide it. This is an essential part of Agile project management. It increases engagement, productivity and every employee’s sense of purpose at work—all of which leads to a faster, better project delivery. 

Original wording: Build projects around motivated individuals. Give them the environment and support they need and trust them to get the job done.

#6—Make face-to-face communication the default

Instant messaging and email are the most convenient means of communication—face to face conversations are the most effective. Even back in 2001, the Agile Alliance understood the increased dependency on written communication and how it could become a problem. 

Direct and frank conversations leave no room for misinterpretation. They’re faster, more reliable, and more honest. While instant messaging can suffice for quick one-to-one clarifications, calls and video conferencing are essential for team discussions. It may be initially more intimidating for some, but it’s ultimately far more effective. 

Original wording: The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

#7—A working product is the primary measure of progress

It’s easy to get bogged down in KPIs, metrics and milestones which, while they might make for an impressive “To Do” list, do not accurately portray your progress. On that basis, one of the Agile principles is that you should measure success by how well the product actually works, ahead of anything else. 

So stop focusing on hours worked or problems solved, and always bring the team back to how well the product works.  

Original wording: Working software is the primary measure of progress.

#8—Maintain a sustainable working pace

Even today, many workers and managers consider “hours worked” to be the measure of a good employee. However, the truth was well-understood by Agile’s founders: the pace of work must be sustainable and consistent rather than reckless or excessive. 

The plainest example would be pulling late-nights to compensate for a lack of progress earlier in a project. Instead, maintaining an achievable and sustainable workflow will allow employees to function at their highest level more often, avoiding the need for heroics to get a project across the line. 

Original wording: Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

#9—Continuous operational excellence makes the project more Agile

When your team is run superbly and all moving parts are synchronized and fluent, you can adapt and pivot with relative ease. It’s a very simple encouragement for a team to do its best work everyday. 

Original wording: Continuous attention to technical excellence and good design enhances agility.

#10—Maximize the amount of work not done

This is our personal favorite of the 12 principles because it highlights a massive flaw in the operational model of so many companies and project managers. 

Doing more work does not necessarily mean making a better product. Look at it this way. Your team has a certain amount of effort they can contribute each day. If 30% of that effort is on unnecessary work, then the customer is only getting 70% effort worth of final product. The goal is to eliminate unnecessary or non-value adding work as much as reasonably possible. Keep objectives, tasks, solutions, and meetings as simple and short as necessary—no more and no less than that. 

A simple way to self-monitor principle #10 is, for every action taken or decision made, to ask this question: does this add value? If it doesn’t, then scrap it and move on to another task. 

Original wording: Simplicity—the art of maximizing the amount of work not done—is essential.

#11—Self-organized teams produce the most value

This echoes the sentiment of principle #5, except that the original principle was more heavily geared towards the software development environment. You should not only encourage your team to do the work the best they can, but also to volunteer ideas, feedback and criticisms of the broader process. 

Encourage your team members to challenge the status quo and suggest improvements at any point in the project. Give your collective team, not just the individuals, the power to change and improve the project. 

Original wording: The best architectures, requirements, and designs emerge from self-organizing teams.

#12—Constantly assess & improve working practices to be more effective

In other words, Agile teams should always be flexible. You are no longer in the game of following prescribed rules and agreements to the letter: if you find a way of delivering the project more successfully—removing bottlenecks in your processes, saving costs, improving communications—it must be acted on. 

Original wording: At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

How Agile Became a Project Management Style

From everything we’ve established so far, we know that Agile was built as a superior product development methodology. And this has been thoroughly validated over the previous two decades. 

In the end, the adoption of Agile principles into project management was probably inevitable. The simple reason being that its methods apply just as easily to management as to product development. It’s a philosophy of optimizing resources, maximizing output over “hours worked”, minimizing bureaucracy in favor of results, giving employees space to perform, collaborating with the customer—all of these elements are visible in today’s best-managed projects. 

Misconceptions About the Agile Methodology

Despite the fact that Agile methods have been developing for several decades, the business world (and of course, the internet in general) is rife with myths and misunderstandings about what it really means to be Agile. So before we go any further, we wanted to nip some of those in the bud. 

#1—Agile can only be used for software development

The roots of Agile are firmly planted in the software development world. As we’ve just seen, it emerged as a direct solution for the industry—but it has since transcended any individual use case. Many industries from engineering to marketing and pharmaceuticals are learning to apply Agile principles in a way that’s optimized for their work. 

As a project management solution, Agile methods should at least be considered for any industry. However, we must acknowledge misconception #2…

#2—Agile is the perfect solution for all businesses

While it would be wonderful to have a one-size-fits-all solution for perfect universal project management, it simply doesn’t exist. The traditional methods evolved for a reason: in a huge number of cases, they’re highly effective! 

Becoming Agile may require a significant shift in company culture, working practices and client relationships—it would be naive to think its benefits applied equally to all businesses. 

#3—Agile cannot be scaled to enterprise level

As you’ll see, Agile can absolutely scale for enterprise businesses. While the exact structure of your teams and how you deliver work might not match “purist” Agile, the majority of its principles (namely the ability to consistently deliver value to your customers) can scale to any level. 

#4—Agile = Scrum

Scrum is a specific framework which applies some of the Agile principles to deliver high-quality work. Agile is the larger umbrella which encompasses an entire philosophy. It is possible for teams to implement Scrum without actually adopting the Agile mindset or culture. 

Kanban, XP, Crystal and Lean Programming are all examples of frameworks—like Scrum—which have interpreted Agile in their own ways. 

#5—Agile means eliminating documentation

Some level of documentation is essential if teams are to avoid falling into a chaotic mess. The principle of “working software over comprehensive documentation” doesn’t mean abolishing documentation entirely. 

Agile teams track metrics, produce reports and assess progress just like traditional teams do. The key is that the documentation adds value to the project, rather than existing for its own sake.  

#6—Agile means no planning

This particular myth is baffling. In Chapter 4, we take a deep dive into how Agile projects are actually executed. Spoiler alert: planning is extensive at every stage.

It’s true that Agile teams forgo the traditional approach of planning every detail and outcome prior to starting a project. However, there is always a detailed plan, stemming from the high-level company goal (or product vision) down to the daily tasks completed by team members. 

#7—Team members have free reign over their work

Agile team members are generally more self-disciplined and self-organized than in traditional teams. While it’s true that they are usually self-directed in how they execute a task, the tasks themselves are formally agreed in advance of starting. There is also ongoing communication and collaboration with fellow team members and stakeholders regarding what needs to be done. 

#8—User stories must be contained within sprints

For true Scrum teams, tasks must be contained within sprint cycles—this is a fundamental part of the framework. However, the majority of Agile teams aren’t so constrained. This is simply because estimation is imperfect and, unless you’re going to make everyone work extra hours, some tasks will inevitably be pushed into the next iteration. 

Some product owners will actually encourage “sprint-spanning” stories to improve flow. 

#9—Agile is the fastest method

Agile isn’t about being fast per se: it’s about delivering the best possible product that meets customer and stakeholder requirements. It is about being focused, flexible and completing work in iterations which always deliver a valuable piece of the puzzle. 

It’s not true to say Agile is faster or slower than traditional methods, because in reality they each produce different final products. 

The 4 Main Agile Frameworks

Wait—I thought Agile was the framework? 

Agile is the guiding principle, but there are many specific frameworks which apply Agile principles in their own practical way. We’re going to look at four of the most popular and most widely-adopted frameworks used today: Scrum, Kanban, Extreme Programming, and Lean Programming/Project Management. 

When it comes to identifying the best-fitting framework for your business or team, we recommend having an open, collaborative tete-a-tete with your team members, key stakeholders and company leadership. You’ll need to consider the type of work you’re doing, the existing company culture, your gut instincts on what changes need to be made—in short, it’s a personal and imperfect process. 

The best thing you can do is list out your requirements and see which framework (if any) fits best. Remember you don’t need to confine yourself to any arbitrary limits: most businesses use these frameworks loosely and adapt them to perfectly fit their unique needs. 

Scrum

This is probably the most famous Agile framework. All work is split into isolated 1-2 week periods called “sprints”. The goal is for every team member to fully complete their assigned tasks within every sprint. Tasks are taken from the backlog, which contains all tasks for the larger (multi-sprint) project. 

Teams usually have daily “stand ups” where they share their progress or field questions. Scrums are led by the Scrum Master (not a project manager) and the success of every sprint is reviewed through a “sprint retrospective”. 

This approach is best deployed where rapid iteration and continuous improvement are desired. 

DID YOU KNOW…

The term “scrum” comes from the sport of rugby. In rugby, the ball is passed between self-directed players using real-time improvisation to deliver a specific result—reaching the try line. This collective behavior was identified by Takeuchi and Nonaka as integral to any Agile methodology, hence the development of Scrum.

Kanban

The origins of Kanban are shared with the humble supermarket. The same way supermarkets only stock shelves just enough to meet demand (and only restock once the shelf is empty) Kanban teams only pull in new tasks once their current workload is complete. 

Kanban focuses on limiting the current Work in Progress (WIP) and is a highly visual approach. Teams use a Kanban board with 3 columns: To Do, Doing, and Done. Every task is contained on a separate card, which is progressively moved through the columns as it’s completed. By limiting the number of tasks which can exist in the “doing” phase, teams avoid bottlenecks. 

Kanban is a very fluid system that is not necessarily focused on speed of delivery. 

Extreme Programming (XP)

XP is a software development-specific framework that’s built on 5 core values: communication, simplicity, feedback, courage, and respect. The framework is designed to produce higher-quality output compared to other methods, with a strong focus on self-disciplined workers and practice excellence. 

XP teams are continually focused on improving their processes, performance and output. 

Lean programming

Lean project management (originally lean programming for use in software development) is a framework devoted to increasing customer value through eliminating waste from each phase of a project. It is built on 5 values: 

  1. Identify value
  2. Map the value stream
  3. Create flow
  4. Establish pull
  5. Continuous improvement

The core value of lean management is that it can streamline virtually any process. It is a means of simplifying your work processes to leave only the most valuable components and create a far more efficient team.

Share on email
Email
Share on linkedin
LinkedIn
Share on twitter
Twitter

Want to see Cloud Coach in action?

Cloud Coach is secure and customisable platform for successfully delivering customer projects of all shapes and sizes.

Schedule a tailored demo with one of our project specialists.

  • Fill out the form below
  • Our team will reach out within 24 hours to discuss your unique requirements
  • We’ll schedule a 1:1 demo with one of our product specialists 
medal 2 1
reCAPTCHA logo@2x

protected by reCAPTCHA

medal 2 1

Before you leave…

Sign up to receive the latest project tips and tricks directly from Cloud Coach.

Email Address

Cloud Coach cares about your privacy. We may use this information for our legitimate interests to provide you with information about products or services that may be of interest to you. You can of course unsubscribe from our emails at any time. Learn more by reading our Privacy Policy.

Thank you

A Cloud Coach advisor will be in contact by email within one working day to arrange your demo.