To talk about agile project management, we should talk about Scrum framework.
There are multiple definitions of the SCRUM framework, but my preferred one is this:
“SCRUM is an agile framework that helps you fail in 30 days or fewer!”
Have you heard about “Fail fast”?
This is a better approach for agile product management especially because it helps you in validating the process of an idea and in this way you are efficient, meaning that all the resources we are spending exactly when we need them and therefore we become efficiently.
Most of the people assume that Agile = SCRUM framework. And this is a mistake… SCRUM is actually the most well-known framework from Agile. Agile is not a framework, it is a mindset.
There are other frameworks that work under the Agile umbrella, including:
These methods adhere to the Agile Manifesto and its associated principles, and we can use them as its are or also as a combination of them, but the common ground for all of them is an Agile mindset.
In the agile project management, the scrum master is the advocate and the protector for the scrum team. They remove obstacles, facilitate team communication, mediate discussions within and outside of the scrum team. Above all, they exist in the team’s service – from my humble experience they are servant leaders, guiding the agile project management methodology.
The customer’s voice. We heard it through this role and has the authority to decide about the project or product.
He/she is the owner of the product who backlogs and who communicates the vision to the scrum team and defining and prioritising together with the team backlog items.
He/she works with the team daily to answer questions and to provide product guidance (even if in practice he is not happening like this, at least in theory it is mention in this way:)).
It comprises at least 1 developer, but in a SCRUM team at least 3 persons should exist.
They own the estimates (meaning they are responsible as a team – they succeed or fail together), make task commitments, and become accountable in front of the entire SCRUM team by communicating their daily status to each other in the daily scrum. The SCRUM team chooses how to build product features—the team owns the “how,” while the Product Owner owns the “what.”
The most important question is certain: Who owns the “Why”?
And the answer is: the entire team! – formed usually by members from the supplier side and as well from the client side.
They are not part of Scrum framework definition, but for sure anyone who wants to could use it.
and other metrics charts the team can use them instead to communicate progress, status, and forecasts.
As we apply the SCRUM framework as by the book we must use a few artefacts, meaning:
The level of documentation is up to the team to decide.
The agile rule of thumb is that if the customer is paying because is receiving value, then the team should create the artefact.
We usually associate the Scrum Master with the PM role. This is not always the case.
This is a list with common activities in the agile project management approach:
… using detailed tasks and task estimations to generate projections?
Traditional estimating and planning uses a bottom-up method, where the scrum team should have all the requirements fully defined, with tasks then created and estimated based on this fixed scope.
Agile estimating and planning uses a top-down method to forecast.
We often gross level estimating at the feature level using a technique called planning poker, with estimates given in points using the Fibonacci sequence.
As an SM, a successful PM attains a daily meeting with the team members. This helps the PM to identify any issues that the team members have faced or shared the update among all the team members.
Then the PM shares status reporting, communicating changes, risks, project plans and to identify any missing roles.
Contrary to waterfall method, it distributes roles among all the team members. The key people in an agile method are the scrum team members, scrum master, and the client.
As a PO, the PM should serve as a domain or subject matter expert (SME). It’s better to keep the roles separated, but this depends on the team how they prefer to be accountable.
A PM should assure that there is a tactical person by translating the product manager’s strategy into actionable tasks and work with cross-functional agile teams to make sure they are executing on those requirements.
Depending on the nature/size of the project, a PM can play unique roles like SM or PO.
Even if the Agile Project Management is not part of the framework definition, this doesn’t mean that PMs cannot practice Agile Project Management.