The Apprentice’s Handbook to Agile Project Management

Seeing as you’ve landed on this post, I’m assuming you’re new to project management. Recently promoted, perhaps? Starting out in your first project management role? Or maybe just interested in wrapping your head around agile project management.

Regardless of your project management experience, you’ve come to the right place!

In this article, I’m going to run you through the key principles, values, and frameworks of agile project management.

We’ll look at some of the system’s benefits, why it’s preferred to traditional project management methodology, and some further reading for those looking to actively implement it within their team.

So without further ado, let’s get started!

Table of Content [hide]

What is Agile Project Management?

We all know what a project is; a planned set of work to be completed within a given time period.

And management, well, that’s easy too; general oversight to ensure the project is delivered on time.

So, what’s agile project management?

A solid definition of agile project management is:

“An iterative approach to project management that breaks processes down into shorter cycles, onboards feedback, and responds accordingly.”

The key here is the addition of agile methodologies.

Agile refers to the continuous feedback built into each short product iteration (sprints).

This enables teams to immediately respond and adapt to feedback coming from the field. Not only does this save a ton of resources, but also ensures the project is delivered on time and within budget.

Seeing as agile methodology was developed in response to the need for improving traditional project management processes, let’s take a quick look at the differences between the two.

Traditional vs. Agile Project Management

Traditional project management (or the Waterfall methodology) comes from the manufacturing industry.

Back in the 1950s and ’60s, computers required some serious hardware. It made sense, therefore, to adopt manufacturing’s rigid, step-by-step process in their construction.

Using this traditional framework, teams only move to the next phase of the project once the prior one is complete. Work cascades down through the different phases — hence, the name waterfall.

However, this process has one major drawback – its rigidity.

As mentioned, once a phase has been completed, there’s no going back. You move to the next one, and then the next one until the project is completed.

So what happens if incremental changes need to be made? What if customers don’t like the new product? What do you do then?

“In layman’s terms, Waterfall is essentially documenting a detailed plan and going with it until the end, while Agile takes a more flexible, cyclic approach.”

The answer is to turn full cycle back, to the beginning, and start all over again…which is a waste of both time and money.

This is why we saw an introduction of agile methodologies in the early 2000s.

Agile focuses on smaller sprint cycles, constantly testing, retesting, and adapting the product on an ongoing basis. It is a far cheaper, faster, and more flexible set of product management principles.

Agile Manifesto Values

In 2001, at the Snowbird ski resort in the Wasatch mountains of Utah, 17 software experts gathered together to share ideas, experiences, and uncover how to tackle the inefficiencies of the traditional Waterfall method.

What emerged from this meeting is now known as the Agile Manifesto.

“The Agile Manifesto is a document outlining the key principles behind Agile philosophy, helping development teams work faster, more efficiently, and deliver projects on time.”

It outlines 4 key values and 12 defining principles underpinning all agile methodology.

4 Agile Values

#1 Individuals and interactions over processes and tools

No matter how detailed and well thought out a process is, problems always arise at some point throughout a project.

The best way to work around it is to simply sit down with your team and have a conversation. What are the underlying issues? How do we fix them? Where do we need to go back and make some adjustments?

Trying to solve these problems by sticking to a rigid, set-in-stone process only increases costs down and adds delays to the product’s release.

Innovation comes from people, not processes!

#2 Working software over comprehensive documentation

The traditional Waterfall model begins with a long, arduous documentation process.

Product features, specifications, layouts, timelines, etc. are all written down and filed before any work on the project can begin.

While this approach sets a solid foundation, it has some serious drawbacks:

• It takes up a lot of valuable time to write the document.

• Delays the project kick-off.

• Planned features may never get used.

Instead, agile methodology suggests we get our feedback from working software (a minimum viable product or MVP).

This allows project managers to onboard active customer feedback, reduce overall costs, and the time taken to deliver the end product.

#3 Customer collaboration over contract negotiation

Customer feedback is typically onboarded during 3 phases in a traditional project:

• At the start through contract negotiation.

• Halfway through the project.

• Once it’s completed.

However, due to the required documentation process before a project begins, there’s a heavy emphasis on what’s included in that initial conversation – the contract negotiation.

And, as we’ve already discussed, the Waterfall process is rigid. It doesn’t allow for changes to be made on the fly…

That’s why agile methodology favors constant customer collaboration throughout the project, to ensure the product continues to satisfy their needs.

#4 Responding to change over following a plan

The last of the four agile values is often misinterpreted.

At face value, it might appear that the authors of the Agile Manifesto suggest scrapping planning altogether. That everything should be done on the fly.

However, that’s not the case!

Agile projects start off with a plan and a general direction in where you want to head. The difference is they respond to changes that could improve the product, instead of rejecting them for straying from the original contract negotiation. 

12 Agile Project Management Principles

The authors of the Agile Manifesto also added 12 project management principles.

Their idea was to create a checklist that project managers could use to help guide their current practices set up within the team.

Here are the 12 principles written verbatim:

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

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

3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference for the shorter timescale.

4. Business people and developers must work together daily throughout the project.

5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

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

7. Working software is the primary measure of progress.

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

9. Continuous attention to technical excellence and good design enhances agility.

10. Simplicity — the art of maximizing the amount of work not done — is essential.

11. The best architectures, requirements, and designs emerge from self-organizing teams.

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

    
    

Benefits of Agile Project Management

We’ve already mentioned a couple of the benefits of agile project management, so let’s dive in a little deeper for those who are still on the fence about the methodology’s effectiveness.

Avoid Scope Bloat

Something that plagues the traditional Waterfall method is scope bloat.

“Scope bloat refers to the addition of product features to a project that are never used by the end-user”.

This is a common issue, even with the software tools we use every day.

For example, the software I’m using right now to write this article has a myriad of buttons, icons, and different features that:

a) I’ve never heard of.
b) I’m never likely to use.

While I might be the only user not familiar with all these features, it’s more likely they’re the result of scope bloat.

The issue is they will have taken a great deal of time, money, and resources to produce.

Had the development team abided strictly by agile methodology, they would have identified that only a small percentage of users actively engaged with these features, and perhaps dedicated resources to other areas of the project.

Reduce Risk of Failure

Seeing as scope bloat is reduced, so are the chances of complete failure of the overall project. Time, money, and resources are dedicated only to areas of the project with confirmed customer interest.

The running of short sprint cycles and daily scrum meetings allow project managers to pick up on any issues quickly, and have them resolved.

More Satisfied Customers

As we just mentioned, agile methodology is all about putting the customer front and center. Products are only developed if they are going to actively benefit end-users.

Most agile projects include a product owner whose responsibility is to align product requirements with customer needs.

This is going to clearly result in a happier customer base!

Team Collaboration

All projects run into setbacks at some point – it’s just the nature of the game. What agile methodology does is allow teams to deal with them effectively when they do.

The collaborative environment of agile projects encourages team members to sit down and iron out problems by working together.

A short sprint cycle then ensures any incremental changes made can be tested immediately, and the roadblock removed. 

Better Product Quality

Do you remember the #1 principle of agile methodology?

“Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.”

When you combine all agile principles together – customer feedback, collaboration, and rapid testing – you’ll inevitably end up with a better quality overall product.

Agile Frameworks

Agile methodologies are a set of philosophies and work principles, therefore, they can be applied in different ways depending on the nature of each project.

We are going to explain the four most popular agile frameworks.

You will see that, although they are quite similar, they have their own practices, methodologies, and strengths.

Kanban

At its heart, Kanban is actually neither a framework nor methodology, but rather a set of four principles:

• Visualize work

• Focus on flow

• Limit work in progress

• Continuous improvement

Because it’s simply a set of principles it has wide applications from factories, restaurants, to software development. In fact, Kanban (Japanese for visual sign) was first adopted from the Toyota car manufacturing process.

As the first principle points out, it’s a system designed to help teams visualize their work. This is done through a Kanban board.

A Kanban board is essentially a visual representation of a workflow. Each stage is assigned a column, where Kanban cards (tasks) are “pulled” from left, to right, as they progress along the workflow.

Here’s an example of a content editorial calendar using Kanban:

A great thing about Kanban is it ensure developers only work on one card at a time. This limits their work in progress (WIP) and allows them to focus on flow (principles #2 and #3).

Also, after plotting your tasks on a Kanban board, you might notice some cards stack up in certain columns.

This could be down to a bottleneck. Identifying and clearing these areas helps teams continuously improve the overall workflow process.

Scrum

Scrum, arguably the most popular of the four agile frameworks, is an iterative approach to project management.

At its heart lies the “sprint” or iteration.

During each sprint, a specific function of a product is built and tested until it’s approved by a product owner.

Once approved, this iteration becomes a potentially shippable addition to the product as a whole.

Typically, these functions will be released to the market after several sprints have been completed (though this does depend on the scope of the project and the value of the added function).

Lean

While perhaps technically not an agile framework, it’s almost impossible to cover this section without mentioning Lean.

As the word “lean” suggests, at its core it’s about reducing waste, increasing efficiency, and building better products.

So why are we mentioning it?

One of the key principles of Lean is the short feedback loop.

Short feedback loops are essentially sprints or iterations that teams work on that actively include customer feedback.

Sound familiar?

Its application can also be applied beyond software project management.

Eric Ries’ Lean Startup Methodology is an application of these processes for business owners and entrepreneurs.

Ries suggests formulating a business hypothesis and testing it through an MVP.

After a process of validated learning, you can use the empirical data obtained from customer feedback to tweak your product type.

If it turns out your hypothesis was wrong, then “pivot” and head in a new direction.

This way, you’re able to adapt to what the market is telling you.

Extreme Programming XP

The final framework to look at is extreme programming or XP.

It was developed by one of the original Agile Manifesto authors, Kent Beck, who described it as:

“A lightweight methodology for teams developing software in the face of vague or rapidly changing requirements.”

At its core, XP is about delivering customer satisfaction.

Development teams following the XP framework work particularly closely with customers to prioritize and deliver improvements called “user stories”.

Like other agile frameworks, these user stories are developed and tested on an iteration by iteration basis. XP teams, therefore, have the flexibility to organize requests and navigate problems as they arise.

Further Reading

As I stressed earlier, the aim of this article was to simply provide broad oversight of agile project management. I’ve barely scratched the surface with some of the concepts mentioned (particularly the agile frameworks).

So, for those of you looking to actively implement agile methodologies, I’ve compiled a list of recommended books for you to get stuck into.

The Scrum Guide

Penned by the originators of Scrum, Ken Schwaber, and Jeff Sutherland, The Scrum Guide is an absolute must-read for those of you interested in implementing Scrum.

It provides a step-by-step process for setting up the framework within your team,

What’s more, it’s FREE! Simply click on the link, head to their site, and download the book.

Kanban: Successful Evolutionary Change For Your Technological Business

Many project managers who switched from Scrum to Kanban, have done so after reading the seminal book on the subject: Kanban: Successful Evolutionary Change For Your Technological Business.

Written by Kanban pioneer David Anderson, the book lays out a clear path for implementing the system within your organization.

Extreme Programming Explained: Embrace Change, 2nd Edition (The XP Series)

If you and your team are seriously interested in taking an extreme customer-centric approach to development with XP, then this is the book for you.

Written by Kent Beck, the founder of XP and the person responsible for bringing it to the forefront of software development, Extreme Programming Explained: Embrace Change is easy to read, and the framework’s fundamentals are laid out logically.

Agile Project Management for Dummies

Finally, for those of you wanting to expand your general agile project management knowledge further, then Agile Project Management for Dummies is definitely worth getting a hold of.

Don’t be fooled by the title. While it might be targeted at “dummies” the book contains 400 pages of easy-to-read, clearly defined concepts of agile project management.

It’s a great stepping stone to hop to if this article has piqued your interest.

Conclusion

While the founders of the Agile Manifesto originally focused on software development (they all came from an IT background after all) agile project management methodology has been applied in many industries.

This includes manufacturing, aerospace, engineering, restaurants, nonprofits, and even construction.

If you find yourself needing direct feedback from end-users regarding your product or service, then agile is 100% something you need to look into.