Webinar
Capabilities include project timelines, resource management, and stakeholder collaboration.
Manage, track and enhance your project delivery processes efficiently.
Manage account goals, tickets, and stakeholders while gaining full customer journey insights from onboarding to renewal.
Everything you need to run your projects on Salesforce. Choose from Waterfall, Agile or Water-Scrum-Fall, track time and use repeatable project templates.
-
Solutions
Capabilities include project timelines, resource management, and stakeholder collaboration.
Manage, track and enhance your project delivery processes efficiently.
Manage account goals, tickets, and stakeholders while gaining full customer journey insights from onboarding to renewal.
Everything you need to run your projects on Salesforce. Choose from Waterfall, Agile or Water-Scrum-Fall, track time and use repeatable project templates.
-
Features
-
Resources
There are no silver bullets or hacks when it comes to becoming an Agile organization or team. Any business owner can slap recurring deadlines on their employees and call themselves “Agile”. They can use the fancy words like “scrum master” and “product owner” and stick flashy Kanban boards on the wall, next to their poster of the 12 principles—but none of that means they’re actually Agile.
The secret to truly Agile teams is internal: team members need to live the principles and build a company culture that’s invested in its success. It’s the accumulation of hundreds of small actions and beliefs—at every level of the business—compounding over time that gradually makes Agile project management second nature.
And once you get to that point, you won’t be turning back. Agile project management has been transformative for teams in many industries, stemming from origins in software development all the way to marketing, design, engineering and more.
This guide is about Agile project management: what it is, how to do it, and why it’s so industry-shakingly powerful.
Introducing Agile Project Management
If you’re looking to introduce Agile project management into your organization, don’t start with the job titles and weekly sprints—start with the values. Build up slowly and carefully, with constant collaboration and communication about where you’re headed and why.
This guide will walk you through every step. We’ll explore exactly what Agile means and how it came about; how a methodology for software development evolved into a diverse project management tool; different Agile frameworks you can employ; how to build a successful Agile workforce and deliver exceptional project results.
We’ll even touch on essential tools and scaling Agile to an enterprise level.
So here’s our recommendation: read the guide from start to finish. Identify the principles or actions that will be easiest to implement in your business and start with those. Use this guide as a reference point going forward as you slowly, carefully and brilliantly transform the way you conduct projects.
ADDITIONAL LINKS
What is Agile Project Management
We’ve written this for anyone that’s interested in the world of Agile project management: why it works, its benefits, and how to do it. But if you’re a business owner or leader, you’ll get extra value as we explore the broader, higher-level impact that Agile projects have on your company’s biggest objectives.
So without further ado, let’s clarify what Agile project management actually is—and what it most certainly isn’t!
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:
- 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.
- 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.
- Overlapping development phases—Every element of the project progresses in tandem. This is a stark contrast to the traditional, sequential product development process.
- 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.
- 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.
- 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:
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.
Helpful Resources
See Cloud Coach In Action
We’d be happy to provide a bespoke 1:1 demo on how Cloud Coach can benefit for your business.
