Agile 1 - The Fundamentals of Agile
Google Project Management Certificate · Course 5: Agile Project Management
Everything in this program so far has described the traditional way of running a project: initiate, plan, execute, close, in that order, with the plan settled up front and change treated as something to control. That is Waterfall, and it works beautifully when the destination is already known. This course turns to the alternative that grew up alongside it, and that now runs a large share of the world’s projects: Agile.
The first thing to get straight is what Agile actually is. It is not a methodology in its own right. It is an overarching approach and philosophy for delivering value to customers, expressed as a set of values and principles, and underneath that umbrella sit many concrete frameworks and methods, of which Scrum is by far the most used. So there are two ways to do Agile: adopt the mindset, and adopt one of the delivery frameworks. The real power comes from doing both.
The second thing to get straight is that Agile is not the upgrade that makes Waterfall obsolete. Both are effective, both add specific value, and the interesting question is never which is better but which fits this project, this team, this environment. This module builds the vocabulary to answer that: the history, the Manifesto, VUCA as a diagnostic, the main frameworks, and how to blend the two worlds.
Where Agile came from
Section titled “Where Agile came from”The word agile in ordinary English means able to move quickly and easily, and by extension flexible, willing and able to change and adapt. The project management movement borrowed exactly that meaning.
Agile methods emerged organically during the 1990s as the software industry boomed. Start-ups were racing to ship more software in less time, and the incumbents were experimenting with faster ways to build better products and stay competitive. In that environment, it was not enough to invent new products, companies had to innovate the processes used to build them. (Software here is broader than apps and websites: it is also the code behind agriculture, medical devices and manufacturing.)
In 2001, the thought leaders behind several of those new lightweight processes met at a ski resort in the Wasatch mountains of Utah. Seventeen of them, self-described organisational anarchists, looked for common ground between their methods and agreed on the underlying problem:
Their answer was the Agile Manifesto - guidance on what really matters when developing software, namely keeping the process flexible and putting people, both the team and the users, ahead of the end product or the paperwork. It was meant to improve software development, but other industries saw the value almost immediately.
Agile is not only for software
Section titled “Agile is not only for software”The values, principles and frameworks have been applied to nearly every industry. Agile itself draws heavily on Lean manufacturing principles that originated in Toyota’s car factories in the 1930s, and Agile methods now show up in aeronautics, healthcare, education and finance, among many others.
Iterative and incremental delivery
Section titled “Iterative and incremental delivery”An Agile project takes an iterative approach: the project processes are repeated, often many times, across the life cycle. The team works inside many shorter blocks of time called iterations, and an individual iteration may be repeated depending on the feedback that comes back.
Inside each iteration the team takes a subset of all the project’s activities and does everything required to complete that subset, so the work is essentially a series of mini waterfalls, one per activity, rather than one enormous waterfall for the whole project.
So the term Agile carries three ideas at once: flexibility, repetition and openness to change. And Agile project management is simply an approach to managing projects and teams that is based on the Agile Manifesto, a collection of four values and twelve principles that define the mindset every Agile team should be aiming for.
Waterfall against Agile
Section titled “Waterfall against Agile”Agile was created in response to the strict linear process of Waterfall. Waterfall aims for predictability and tries to avoid change; Agile accepts as a starting fact that the world, the markets and the users are uncertain and unpredictable. The classic failure it targets: the customer asks for feature A, and only when the finished thing lands do they realise they actually wanted feature B. Getting customer feedback faster is how Agile attacks that.
Cutting waste
Section titled “Cutting waste”Part of the Agile mindset is constantly hunting for more efficient ways to work, which means streamlining processes without reducing product quality or value, and the key to streamlining is reducing waste. The module names two forms of waste: unnecessary documentation, and building the wrong thing, meaning weeks or months spent on a feature that customers, users or stakeholders turn out not to want. Both shrink with the same medicine: more collaboration with the team and stakeholders, which buys less documentation and earlier feedback.
Three concrete differences
Section titled “Three concrete differences”- Requirements fixed up front in a product requirements document
- Formally approved plans, sometimes a dedicated team to write them
- A change control board to manage any change to requirements
- Heavy documentation for handoffs between phases and teams
- One big deliverable released at the very end
- Requirements treated as dynamic and expected to change
- An initial list that keeps growing, reprioritised with stakeholders
- Change is welcomed rather than defended against
- Short documents, just enough detail, written only as needed
- Smaller, more frequent releases, each earning feedback
| Aspect | Waterfall | Agile |
|---|---|---|
| Requirements | Documented, formally approved, guarded by change control to prevent scope creep | Dynamic, prioritised continuously with stakeholders, most valuable items to the top of the list |
| Documentation | Lots of it, because work moves in big chunks with many handoffs | Emphasis on real-time person-to-person conversation, plus short documents with just enough detail |
| Deliverables | Usually one release at the very end, a big event with real fanfare | Smaller and more frequent, each celebration less formal but building up to the same thing |
When each is the right choice
Section titled “When each is the right choice”The Agile Manifesto: four values
Section titled “The Agile Manifesto: four values”The Manifesto opens by saying its authors are uncovering better ways of developing software by doing it and by helping others do it, and that through that work they have come to value four things. The crucial sentence is the closing one: while there is value in the items on the right, they value the items on the left more. It is a statement of emphasis, not a ban.
| The Agile team leans towards | …over | What it means in practice |
|---|---|---|
| Individuals and interactions | processes and tools | People talking to each other beats forcing outcomes through process. A long email chain of follow-up questions could often have been one short conversation. Tools should facilitate good management and collaboration, never become a barrier between people |
| Working software | comprehensive documentation | Spend time on the thing that creates value, not on debating, writing and reviewing documents beyond what is needed. Substitute your own deliverable for the word software: a legal brief, an office layout, a sales presentation |
| Customer collaboration | contract negotiation | Customer satisfaction is the highest priority, because if it is not valuable to the customer there is little point building it. Contracts still exist, but the freedom to collaborate early and often beats negotiating terms for every small change. Show prototypes, ask questions, invite them to test |
| Responding to change | following a plan | Change is inevitable, and the bigger, longer and more complex the project, the more uncertainty it carries. A plan locked at the start may well deliver on time and on budget, and still miss what the customer needs. Agile PMs still plan, they just cope with revising the plan at any point |
The twelve principles, in four themes
Section titled “The twelve principles, in four themes”From the four values, twelve principles were developed that reinforce and clarify the message. The course groups them into four themes as a memory aid - these themes are a teaching device, not part of the Manifesto itself.
How do teams deliver highly valuable products to their customers?
How do teams work with business partners and stakeholders to create value?
How does a team build the interpersonal dynamics that deliver value?
How does the project keep learning and lifting performance?
Value delivery
Section titled “Value delivery”Deliver as quickly as possible, because feedback mitigates the risk of building the wrong thing, and because nobody gets any value from the work until it is delivered - not the customer, not the company. The longer delivery takes, the longer you wait for revenue and the more room competitors have to get ahead.
- 1. Satisfy the customer through early and continuous delivery of value. A steady value stream builds trust and confidence, and realises business value sooner.
- 2. Welcome changing requirements, even late on. Agile processes turn change into a competitive advantage for the customer, so keep scanning the environment and fold changes into the plan.
- 3. Deliver working increments frequently, on a timescale of a couple of weeks to a couple of months, preferring the shorter end. Small frequent increments create regular openings for feedback.
- 7. A working product is the primary measure of progress. Meaningful completion means a demonstrable piece of the solution, not a finished document. Saying the team is 80 percent done means nothing without something reviewable.
- 10. Simplicity, the art of maximising the work not done, is essential. Skip features the user or product owner never asked for, drop procedures that are no longer needed, cut unnecessary documentation.
Simplicity is worth dwelling on: think how much engineering time goes into buttons and features that end up confusing the user. In practice the theme looks like getting feedback on a prototype so you learn which features actually matter, keeping the team on approved features only, or reserving roughly ten percent of the team’s time for bug fixing and polishing processes so future iterations run faster.
Business collaboration
Section titled “Business collaboration”Here business people means those in sales, marketing, customer support and account management, and developers means those making and creating the product.
- 4. Business people and developers must work together daily throughout the project. Removing the barrier builds trust and keeps the builders in tune with user needs.
- 6. Face-to-face conversation is the most efficient and effective way to convey information to and within the team, because it carries cues, body language and expressions that email, chat and phone lose. Where that is impossible, agreeing effective communication norms in whatever format you have is what matters.
Practical forms this takes: seating business people near the development team, ideally in the same office or virtual space, or co-locating one day a week, encouraging instant messaging, or blocking shared time in calendars. And rather than keeping customers away from developers out of fear of scope creep, run a weekly huddle where customers and business people explore feedback and new ideas with the team. That is often how you discover that one genuinely valuable feature is easy to build, while a feature everyone assumed was easy is actually very hard.
Team dynamics and culture
Section titled “Team dynamics and culture”This theme is the first value made concrete: an effective team culture that is inclusive, supportive and empowering is essential to a project’s success.
- 5. Build projects around motivated individuals, give them the environment and support they need, and trust them to get the job done. Teams build better solutions when they are empowered, and when sponsors and executives trust them too.
- 8. Agile processes promote sustainable development - sponsors, developers and users should be able to keep a constant pace indefinitely. Overwork causes errors and burnout, while an underused team gets bored and loses its creative spark.
- 9. Continuous attention to technical excellence and good design enhances agility. Working fast is not licence to sacrifice quality. A well-built solution can absorb feedback quickly, a low-quality one makes every change slow and complex.
- 11. The best architectures, requirements and designs emerge from self-organising teams. Members should design their own working processes rather than have a manager dictate them, and should feel free to raise questions, concerns and feedback.
Two examples: ask the team what equipment they need to do the job, then actually give it to them; and let teams write their own processes and templates instead of imposing something from headquarters. Teams work best when their input is visibly valued, so the PM’s job is to make space for them to shape the culture.
Retrospectives and continuous learning
Section titled “Retrospectives and continuous learning”- 12. At regular intervals the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.
This one stands alone because it deserves the attention. Set time aside after each iteration purely to work on how to improve, and use it to step back and ask: how is the team doing, are the customers happy, which processes could be optimised, are the tools working for us, are we living the values, and are we accumulating debt, meaning processes or technology that slow us down. No team is perfect, so learning from both successes and failures has to be continuous.
VUCA: deciding when to go Agile
Section titled “VUCA: deciding when to go Agile”Before choosing an approach, examine the environment and conditions the project sits inside. The US military war college developed a concept for exactly this kind of assessment, and it transfers neatly to projects.
| Letter | What it refers to | What it feels like on a project |
|---|---|---|
| Volatility | The rate of change and churn in a business or situation | The next disruption to operations is always around the corner, and nothing ever settles into a normal rhythm |
| Uncertainty | Lack of predictability, high potential for surprise | Plans for the future rest on a large stack of assumptions that may all turn out wrong |
| Complexity | A high number of interrelated forces, issues, organisations and factors | One product depends on diverse global suppliers, and everything touches everything else |
| Ambiguity | The chance of misunderstanding the conditions and root causes of events | You cannot pinpoint what is causing the delays, so you cannot design mitigation plans for the risk |
High VUCA is the signal to consider Agile. Agile will not remove VUCA, but it gives the team tools and systems to mitigate the risks VUCA creates, and it is a proven, well-documented response to those challenges.
Agile works best in industries and projects that are exposed to, or that actively encourage, change and uncertainty. Obvious candidates: biotechnology with emerging vaccines, treatments and technologies, media with endless new ways to share content, food with celebrity chefs and the latest craze, and fashion, an entire industry built on shifting trends. The apparently stable ones - agriculture, aerospace, manufacturing, mining - have rigorous supply chains and codes, and still have to adapt to new laws and regulations, natural disasters and other unforeseen events. The lesson of 2020 is that no industry is truly immune to change.
The running example: Virtual Verde
Section titled “The running example: Virtual Verde”The course scenario continues from earlier courses at Office Green, a commercial landscaping company doing interior plant design for offices, restaurants and hotels. Market research spots a major shift towards people setting up home offices, which is both a huge new market and a threat to the existing office service. The shift arrived suddenly, so there were no project plans to start from and no time for much prep work, but the opportunity would not wait. Office Green forms a scrappy new Agile team to deliver a new service called Virtual Verde.
Read that against VUCA and every letter is present: volatility as a major disruptive change to the business plan, uncertainty making concrete future plans impossible, complexity from interrelated factors like suppliers and the economy, and ambiguity because nobody could determine or control what might cause the next change. Rather than watching the business erode, Office Green embraced the changing market and stayed flexible about how to approach the project.
Scrum is by far the most popular methodology under the Agile umbrella. In the 2019 State of Agile report, 72 percent of teams using Agile methods were using Scrum or a hybrid of it, so anyone working in Agile project management will very likely use Scrum or something based on it.
The name is not an acronym. It comes from rugby, where a scrum is the formation in which players lean forward, lock their heads together and work as one unit to drive the ball towards the scoring line. The originators saw their team the same way: heads down, working very closely together to move the ball down the field.
The mechanics
Section titled “The mechanics”In Scrum you form a team that works together to develop and test a deliverable quickly, in short cycles, meeting daily to discuss current tasks and clear anything blocking progress.
| Term | What it is |
|---|---|
| Backlog | The central artifact of Scrum, where every possible idea, deliverable, feature or task is captured. Prioritised and proactively managed by the team continuously, for the whole life of the project |
| Sprint | The time-boxed period in which work is done, between one and four weeks, most commonly around two. This is the Scrum name for the iteration |
| Daily Scrum (Stand-up) | A meeting of 15 minutes or less, every day of the Sprint, where the team inspects progress towards its goal |
| Scrum Master | Ensures the team lives the Agile values and principles, follows the processes and practices the team agreed to, shares information with the wider project team, and helps the team focus on doing its best work |
| Product Owner | Maximises the value of the product and of the team’s work. Owns the inventory of work and has the final say on prioritisation |
| Development Team | Responsible for how the team will deliver the product |
Why it is so popular, and where it fits
Section titled “Why it is so popular, and where it fits”- Clear roles and responsibilities, while continuously emphasising the power of the team as a whole.
- Regular, predictable meetings and delivery schedules with predefined agendas and outcomes, which makes it easy to teach newcomers.
- It supports the Agile values and principles while adding structure that helps new teams start and experienced teams improve.
- It is free and open for anyone to use, with a huge body of online guidance, training and certifications.
The ideal Scrum team is cross-functional, with roughly three to nine members, sometimes called a pizza-size team because that is how many people could share one large pizza. Too small and you lack the diversity of skills to get the work done, too large and information becomes hard to distribute. Scrum also needs a team and a management layer that are open-minded, adaptable and keen on continuously learning to be a better team.
Note that none of that mentions software. Scrum emerged from software projects, but people have adapted it to wedding planning, house moves and building rockets.
Where the ideas came from
Section titled “Where the ideas came from”The word Scrum was first used for this kind of work in a 1986 Harvard Business Review paper by Hirotaka Takeuchi and Ikujiro Nonaka, The New New Product Development Game, in a chapter titled Moving the Scrum downfield. The paper identifies six characteristics of teams that manage it:
| Characteristic | What it means |
|---|---|
| Built-in instability | Teams get freedom to achieve important outcomes against challenging requirements, supplying the element of tension a strategically important project needs |
| Self-organising teams | Each operates like its own start-up, with an order that lacks true hierarchy, showing autonomy, continuous growth and collaboration |
| Overlapping development phases | Individuals synchronise their pace to meet deadlines until a collective team pace forms |
| Multi-learning | The framework leans on trial and error, and members stay current with changing market conditions so they can respond fast |
| Subtle control | Self-organising does not mean structureless: checkpoints through the project analyse team interactions and progress, keeping control without hindering creativity |
| Organisational transfer of learning | Everyone is encouraged to learn skills that are new to them while supporting other members |
The authors’ central point still holds: no single element on its own produces speed and flexibility, it is the whole set together that creates the dynamic.
Kanban
Section titled “Kanban”Kanban comes from two Japanese words, kan meaning sign and ban meaning board, and it can be applied in a very simple way or used to drive an entire project. The Kanban board is its most famous feature and has been adopted by most Agile enthusiasts, because it gives transparent visual feedback to anyone interested in the status of work in progress. The classic board displays progress as to do, in progress, done, and plenty of software tools generate digital versions.
The less visible half of the method matters just as much. Kanban ensures the team only accepts a sustainable amount of work in progress by setting a WIP limit - a cap, decided by the team itself, on how many tasks can be in progress at once, based on what they can genuinely handle in a given period.
The WIP limit is Agile in miniature, since the teams are both self-organising and empowered, and they are operating at a sustainable pace.
Extreme Programming (XP)
Section titled “Extreme Programming (XP)”XP got its name because it takes traditional software development activities to an extreme level, and it emerged around the same time as extreme sports like snowboarding. Its aim is to improve product quality and the ability to respond to changing customer needs, by pushing development best practices to their limit.
The worked example is test-first development: testing parts of the product before building them in full. Ordinarily only the larger features get tested, which is fine but lets details slip. XP takes it to the extreme by finding ways to test more, and smaller, features so the team collects even more feedback.
XP came out of software and uses software vocabulary, but it adapts to non-software work. It targets four basic activities:
| Activity | In software | Outside software |
|---|---|---|
| Designing | Writing a design document describing the parts of the code and how the product will function | Describing the pieces of whatever you are delivering. For an ad campaign, the artwork, the copy and the ad buy plan |
| Coding | Clear, concise code others can easily read and understand, which makes troubleshooting far easier | Clear, concise processes or instructions for how to build or use the product |
| Testing | Checking for flaws before they reach the final product, and checking features against customer requirements | Same idea: eliminate flaws in a feature before building it and moving on. More testing is better |
| Listening | Listening to the customer and making sure requirements are integrated into the product | Identical, and it is the direct link to the Agile value of customer collaboration and regular feedback |
Designing is where XP stresses simplicity: start with a simple design that meets the most basic and important requirements, since simple designs also take less time to complete, then add features once the basic model is designed and tested.
XP practices that spread everywhere
Section titled “XP practices that spread everywhere”| Practice | What it means |
|---|---|
| Pair programming | Two team members working together at the same time on one task, usually side by side, though digital collaboration tools make it work remotely |
| Continuous integration and continuous refactoring | Merging product changes into a shared version several times a day, to get quick feedback on the quality of the code or product |
| Avoid big design up front | Design just enough to get started, then improve it continuously as the product evolves |
| Write tests, not requirements | Rather than a requirements document plus a separate test plan, let the test plan do both jobs: tell the team what to build, and compare what was built against what was supposed to be built |
Lean predates Agile, and the inventors of Agile were directly inspired to apply Lean manufacturing principles to software development. Like Agile, Lean is a set of principles and a value system, and many of the apparent differences between them are really differences of wording. Its five principles work as a recipe for improving project outcomes.
-
Define value - identify and focus on what the customer wants, and include the customer in the process. A product’s value is the sum of all the things the customer wants.
-
Map value stream - map out the process, every step involved in producing value for the customer, and challenge any step that is wasteful or unnecessary.
-
Create flow - make sure the product moves through the value stream efficiently, removing interruptions, delays and barriers, and continuing to eliminate waste throughout the cycle.
-
Establish pull - like pulling something off a shelf: make sure the customer is asking for the product throughout the value stream, pulling for features and incremental deliveries. The smoother your process, the more readily you can show what you have been working on or take a feature request at any moment.
-
Pursue perfection - push the team to keep improving the first four steps.
Blending Agile and Waterfall
Section titled “Blending Agile and Waterfall”Agile project management includes most of the same phases and tasks as Waterfall - initiation, planning, executing and completing tasks, closing out, along with goals and scope, scheduling, budgeting and risk management. They are just done differently. Which is exactly why blending them often makes sense.
It also means you can capture some of the benefit of thinking in an Agile way, applying the values and principles from the Manifesto, even when the delivery approach has to be Waterfall.
Reasons to blend
Section titled “Reasons to blend”- Stakeholders, customers or sponsors are more comfortable with traditional approaches and find traditional work products easier to follow, while the project team is already established in Scrum and wants to continue.
- Regulatory requirements insist on certain traditional work processes, such as large requirement documents needed for certifications.
- A vendor on a large project already follows a traditional approach, so integrating the teams requires some blending.
Blending in practice
Section titled “Blending in practice”Two everyday examples. In a Sprint retrospective a team member says they need to implement a feature they have little experience with, someone else on the team is an expert, so you pair them up to build it together next Sprint - that is XP pair programming inside a Scrum retrospective loop. And most Scrum teams track their Sprint progress on a Kanban board, another blend so common that nobody remarks on it.
Back at Office Green, blending shows up in two places on Virtual Verde. The existing plant suppliers are used to dealing with the original office delivery team and only some are interested in experimenting with Agile, so involve those vendors in discussions early to win buy-in and address concerns. And because Office Green has to watch costs closely, use traditional budget management controls to keep the program from overrunning.
The rule of thumb: go for it as long as different parts of the project benefit from particular processes without negatively impacting the project as a whole.
Scaling: the Spotify model
Section titled “Scaling: the Spotify model”Spotify is the standard reference for scaling Agile while staying flexible. Agile coaches Henrik Kniberg and Anders Ivarsson built an approach of constantly blending methods and adapting over time, using an organisation system of Squads, Tribes, Chapters and Guilds to encourage innovation, collaboration and productivity while preserving autonomy, quality and necessary communication.
| Unit | What it is |
|---|---|
| Squad | Like a Scrum Team, meant to feel like its own start-up inside the company. Self-organising and collocated, working towards a long-term mission such as improving app usability on Android or providing payment solutions. No formal leader, but it does have a Product Owner, and access to an Agile coach for continuous improvement |
| Tribe | A collection of Squads working in a specific area, intentionally kept under about 100 people |
| Chapter | A small group of people across a Tribe with similar skills, working in the same general competency area |
| Guild | The largest grouping: people from across the organisation who want to share knowledge, tools, code and practices |
Product Owners across Squads collaborate to maintain a roadmap tracking Spotify’s progress as a whole.
Revision summary
Section titled “Revision summary”Next: Scrum 101 → - the most used Agile framework, in detail.