Briefing: Agile Project Management
A lot of my current work is helping clients with Agile project management to develop software and web content. I’m by no means an expert, but I have learned a thing or two over the years. I produced this no-nonsense, plain English overview to help managers and stakeholders get to grips with this ‘new’ way of working and make the most of the very real benefits it has to offer. And then I thought, why not share it with you?
What Is Agile?
Agile is a popular working methodology that enables people and businesses to efficiently create new software by following familiar steps. It focuses on continuous improvement, scope flexibility and teamwork. You’ll also hear it referred to as Extreme Programming (XP), Scrum or Lean Development.
A Brief History
The “Flexible, holistic product development strategy where a development team works as a unit to reach a common goal” was first proposed by Hirotaka Takeuchi and Ikujiro Nonaka in 1986’s The New New Product Development Game. Their writing formed the core of the methodology first developed by Schwaber, Beedle and Sutherland in the mid-1990s, but it didn’t gain the now familiar Agile name until 2001, with the publication of The Manifesto For Agile Software Development.
How Does Agile Work?
Unlike many development processes, Agile puts the focus first and foremost on the end user. And for that, I love it. The project’s lifespan should begin with gathering user stories to understand their needs and how they would like to interact with the end product. This phase of Discovery is crucial in determining the product’s functionality and user interface when it comes to Delivery.
The overall project is broken down into a series of stages, called Sprints or Iterations. These last between one week and one month and you could have multiple teams running sprints alongside one another. The idea is to focus on one achievable objective at a time, meaning that you don’t need to worry about the daunting prospect and enormity of the whole project.
Within these short Sprints are even shorter Scrums that last a single day. This refines the focus even further, breaking the Sprint objectives into daily deliverables. It’s good practice to review both the product and the process at the end of each Sprint, to see what work remains to be done and how your project cycle could be improved. Then it’s time to start another Sprint.
Rinse and repeat until your product is ready to publish…
The Agile Roadmap
Any Agile project is broken down into a number of stages. The exact number will vary with whoever is leading the project and how they want to implement an Agile environment, but the principle remains the same.
Some practitioners work to just three stages:
- Discovery (research and planning)
- Development
- Review
But that seems a little simplistic for any complex project.
It’s more usual to split Agile projects into seven stages:
The Discovery Phase
Stage 1: Product Vision
Stage 2: Product Roadmap
Stage 3: Release Planning
The Delivery Phase
Stage 4: Sprint Planning (also called Iteration Planning)
Stage 5: Daily Scrum (also called Stand-up Meeting, or Daily Commitment)
Stage 6: Sprint Review (to assess the product)
Stage 7: Sprint Retrospective (to assess the process)
Post-release Phase
You might want to add two further stages:
Stage 8: Product Release
Stage 9: Ongoing Maintenance
In theory, it’s the four stages of the delivery phase (stages 4-7) that you will need to iterate for the majority of the project’s lifecycle. Although you may find that you need to revisit stages 1, 2 and 3 as a result of work in this phase.
Artefacts
Agile teams need to be able to measure their project’s progress, so for the most part, they refer to six main artefacts. These are also often referred to as deliverables. Keep an eye on yours for a ready reckoner of your progress.
- Product vision statement: A concise explanation of why the product benefits your company. What should it achieve?
- Product backlog: A comprehensive list of the projected work in order of priority.
- Product roadmap: An overview of requirements, with a rough schedule for developments.
- Release plan: An approximate timetable for the release of working software.
- Sprint backlog: Your goals, user stories, and tasks.
- Increment: The functionality at the end of each sprint.
Of course, you can add more – and more specific – artefacts to suit your project, but these are the most frequently used.
Typical Roles
Who works in an Agile environment?
Development Team
The people who create the product. (programmers, testers, designers, writers.)
Product Owner
The person responsible for connecting the customer, business stakeholders and the developers.
Scrum Master
Supports the developers, clears obstacles and keeps the process consistent.
Stakeholders
Anyone with an interest in the project.
Agile Mentor
An Agile veteran who can guide new project teams.
If you found this briefing useful, please share it via LinkedIn, Facebook, Twitter, or your own blog. I’d really appreciate it, thanks. If you need Agile project management or professional copywriting for anything from your new web copy to marketing collateral and press releases, I’d love to hear from you. Get in touch today to find out how I could help your business.