The following content is taken from the popular whitepaper, “Agile Project Management: What’s the story?” written by Jerry Manas. It’s so good, we wanted to make it free to our readers and give it everlasting life on our blog for your enjoyment.
Before reading ahead, we suggest you read part one of this series on why you should adopt a collaborative and iterative approach.
Agile is a whole different way of thinking, so, not surprisingly, the terminology is different as well. Below is a summary of how Agile works, along with the relevant terminology:
- Features are defined in stories, which identify the user(s), actions(s), and benefits for that feature (as an analogy, think of stories in fiction: they involve character, plot, and motive).
- User stories are estimated in relative points (though some organizations use ideal days). Story points are a measure of relative complexity and effort. As work is completed, the team can “earn” points for the completed stories.
- User stories are prioritized so that the highest value features or enabling features are delivered as soon as possible. The team works collaboratively on prioritized stories from a backlog in fixed-time iterations, generally 1 to 4 weeks in duration (in the Agile Scrum methodology, popular in software development, these iterations are called sprints).
- The team meets regularly to share information and progress. In the Agile Scrum methodology, these are daily 15-minute standup meetings. The key is to stay out of the weeds. There are not problem-solving meetings.
- After each iteration/sprint, the team and stakeholders meet to assess progress, make adjustments, and plan next steps (i.e. evolutionary planning). This is often referred to as retrospective. It differs from the traditional post-implementation review, which is usually held long after the project and far too late to make a difference on the current project.
- Progress is tracked via burndown charts, which track work remaining over time (in terms of story points planned vs. earned).
- Velocity measures story points completed per iteration/spring (i.e. the speed at which value is being delivered).
A release of a product is generally made up of multiple iterations/sprints. Often, there is a planning sprint at the start of each release to plan out the stories for that release.
Agile Roles
With Agile projects, the role of the project manager must be reconsidered. This is because:
- Baselines are irrelevant – A baseline is meaningless if the whole concept of Agile is to plan and adapt the features to fit within fixed time and cost iterations.
- Formal up-front requirements don’t apply – Customer needs must be understood, but detailed requirements are not all fixed up front; requirements evolve with learnings from each sprint.
- The devil is in the details – Agile projects succeed or fail based on mutual understanding of customer needs and technical capabilities. Thus, leaders of Agile projects need to understand the details.
- It’s all about the product – Unlike traditional projects, where the focus is on managing the scope, schedule, and budget, Agile projects are all about the product as opposed to the project. Items like schedule and budget are fixed.
- Agile projects are community-driven – In Agile projects, developers, analysis, product owners, and customers are in constant communication. If they’re not, then the Agile methodology is not being followed. Unlike traditional projects, the project manager is not the primary source of communication.
- Agile projects are relatively low risk – With a large, complex project with lots of cross-team involvement and moving parts, Agile may not be the best approach. Agile is often used in software development and other knowledge-work projects that can bear some sort of tolerance for uncertainty and a single team can work at a rapid pace.
With all this in mind, some may ask the inevitable question: What, then, is there for a project manager to do? It’s a valid question, and organizations have taken different approaches, from not having a project manager at all to using the project manager as a facilitator across the product owner, customers, and developers. In some organizations, the Scrum Master serves as the project manager.
Below are typical roles in an Agile project:
- Product Manager/Owner – determines the product vision and ensures that features listed in the backlog are prioritized and understood; provides User Stories (users/actions/benefits)
- Customer – monitors progress and provides input for valuable deliverables (Note: The Product Manager typically serves as the proxy for the customer when it comes to electronically recording comments and input)
- Development Manager/SCRUM Master/Project Manager – populates sprints from the project backlog and updates story points based on planning sprints; facilitates daily meetings and sprint demos
- Developers – are assigned to stories and make testing notes against stories; report effort for cost tracking purposes
- Resource Managers – optimize resource utilization across multiple projects and ensure resource availability on critical projects
- QA/QE Manager/Testers – focuses on quality assurance/engineering, including process improvements, testing, and measurement
Have you filled these roles within your organization? Adapting to this mindset, especially if it is new for your teams, can take time, but the benefits are worth any growing pains. Visit https://www.planview.com/lean-agile-delivery/ to learn how our solutions can help your organization adapt, and register for a free demo of our Lean and Agile Delivery solution to experience the benefits for yourself. In the final part of this series, we will examine the concerns many people have around switching to and Agile methodology.
