Agile Project Management is common in Software Development and Telecommunication industries. Nowadays, it is a prerequisite for a PM role.
But!
There is no standardized agile project management approach.
It is different in different companies.
However, I would like to share my framework that describes a possible application of Agile Project Management.
It will broaden your understanding of this approach. You will learn about the most efficient way to implement it.
What is Agile Project Management?
Let’s be clear. Scrum or Kanban on its own is not an Agile Project Management approach.
Scrum and Kanban are separate and self-sufficient frameworks. Ideally, you can run a project with one of them alone.
Agile Project Management is an approach that combines plan-driven phases with agile ones in one project life cycle.
So, for example, you have Initiation and Planning phases done in a plan-driven way.
The main execution phase is done with Scrum. In the end, you may switch to Kanban to test and fix critical defects.
Once the initial implementation is finished, you may get back to the plan-driven approach to deploy and finalize the project.
Why do you mix Agile with Project Management?
Not all companies and clients are ready to be Agile. I mean, to the full extent.
Moreover, Scrum or Kanban does satisfy the management, administrative, and bureaucracy (in a proper meaning of the term) needs of a big organization.
However, I believe that for a Project Manager, it is a natural development.
A PM should select the most appropriate tools and techniques.
Without Agile Manifesto and marketing buzz around Scrum and Kanban – these are just frameworks. Tools.
It makes an excellent combination for projects with lots of uncertainties.
Sorry, no magic here.
Agile Project Management Life Cycle
I have already explained the possible agile project management life cycle. What I want you to understand is that there is no standard here.
Break down the project into phases. Use an Agile approach in one of them. Now, you have Agile Project Management.
Prerequisites to Project Management with Scrum and Kanban
There are just a few prerequisites for Agile Project Management.
You do need to ensure that stakeholders honor these prerequisites.
They need to understand their role and the PM approach in general.
1. Use User Stories for Requirements
A simplification that you and your stakeholders need to master.
Collect all requirements in User Stories. Develop Acceptance Criteria. Leave all the rest for the project team to handle.
You may collect requirements in any way available. Then, you can transform them into User Stories. It is a valid approach as well.
2. Use Iterations as a Unit of Measurement
If you use Scrum, then an iteration becomes a key UoM. You plan scope, time, and costs in terms of iterations.
You can still use the Gantt Chart for visualization if you need to. However, be ready that deadlines drift in iteration increments, not days.
3. Be Ready to Descope Project
OK, not you. Your stakeholders and clients should be ready.
Your project scope cannot be fully packed up with critical “must-haves.”
First, it is not real.
Second, you did not work hard enough with stakeholders.
Third, you did not prioritize your backlog well enough.
There should be a scope margin that makes the “agile” part possible.
4. Be Ready to Switch Frameworks and Approaches within One Project
As a project manager, you must use the most appropriate tools or approaches.
You can do everything using Scrum only.
However, is it the most efficient way?
Neither you nor stakeholders should be dogmatic about Agile. When needed, you switch approaches and do the work.
You don’t focus on company transformations.
You get things done using the strengths and weaknesses of the current organization. You choose the path of lesser resistance.
But it doesn’t relieve you from collecting lessons learned and suggesting improvement afterward.
Stage 1: High-Level Project Management
Note: Here we need to think about Project Management across all knowledge domains. Including risks, responsibilities, integration, etc.
So, first of all, you need to understand it is up to you to decide how much Agile your approach should be.
Sometimes, you can run the whole project life cycle within Scrum Framework. From a project management perspective, you build up additional processes around the Scrum implementation of project scope.
Here is the trick:
Under the Scrum or Kanban framework, you have specific inputs and outputs related to a Sprint.
For example, you need user stories for Sprint Planning. However, you may decide to fill up Product Backlog in parallel with the development.
So, you will be managing activities and a separate team to collect requirements, create designs, and log User Stories.
The Scrum Team will use the prioritized Backlog as usual.
On the other hand, you may get an increment of your product or service after a Sprint. Hand it off to another sub-team for testing.
Alternatively, switch the Scrum Team to Kanban and run tests and fix defects in Kanban way.
Every project is unique. So, no one Project Management approach will cover all possible variations.
Different frameworks have different efficiency depending on the period of the project life cycle.
These are important:
1.1 Define Your Roles of a Project Manager and Scrum Master Correctly
Depending on the project size and your responsibilities, you need to find a balance between the role of a PM and Scrum Master.
When a project is small, you are more of a Scrum Master. You just add more processes to work with Stakeholders. You may also need to control general progress towards project goals.
On a larger project, you may need to focus more on Project Management. The Scrum Master role will help you to be in sync with the project team.
When you have multiple Scrum Teams, you get on a higher level of management. It is better to delegate Scrum Master roles to someone else.
1.2 Performing Project Initiation Increases Chances for Success
In Agile Project Management, some form of Project Initiation is a must. That gives you an opportunity to:
- Identify project goals.
- Form certain expectations.
- Develop project boundaries.
- Identify external to Scrum process Stakeholders.
- Develop a project life cycle.
- Perform high-level planning.
- Develop a strategy for the project implementation.
All the benefits of Project Initiation apply here.
Project Charter is usually present in bigger Agile Projects.
1.3 How to Conduct Proper Agile Planning
Planning in Agile Project Management is simplified.
There are iterations. There is a team’s capacity. It is the unit of measurement of your scope increment.
Based on high-level planning, you can identify the approximate number of Sprints that the project will have.
It is a high-level release planning. Estimation here is rough. You may want to apply rougher grades like S, M, L, XL rather than Story Points.
This way, you have a roughly estimated Backlog.
Now you fill in the Sprints to its capacity.
So, you can get milestones you can present to stakeholders.
Again, it is up to you how close you will keep to Scrum or Kanban canóns.
So, you can apply a custom Definition of Done to adapt to project needs and increase efficiency.
1.4 Make an Efficient Transition to Agile Execution
It is a good idea to have exit criteria from the Stage One.
It is a list of artifacts and activities that you must do before starting project execution.
For example, you may want to have a certain amount of User Stories fully defined. Alternatively, you need all the designs.
You may want to plan several sprints ahead. Or do the whole release planning.
Anything that will improve the productivity of the next phase should go here.
Stage 2: Agile Execution of a Project
Adapt Scrum Roles to Project Needs
In Agile Project Management, there is a crucial change in the Product Owner role.
On a bigger project, it is hard to dedicate one person responsible for project requirements and scope.
Therefore, there is a proxy there. Quite often, it will be just you. Or a Business Analyst.
The idea is:
You do Scope and Stakeholder Management outside of Scrum Framework. You work with many different of Stakeholders, collect requirements, and resolve conflicts between them.
Then…
You transform them into User Stories and put them in the backlog.
You may also need to work closely with Stakeholders to identify relative priority between different requirements and expectations.
It is a typical model of work in Agile Project Management. Depending on its configuration. Artifacts and events may differ.
What else?
The role of the Project Team should be aligned with Scrum prescriptions. I suggest you protect the Scrum Team concept as much as possible.
Update Artefacts to Fit into Framework
Product Backlog, Sprint Backlog, and the Increment stay the same.
As discussed before, the Product Backlog may be refined beforehand.
Here is what you may adjust here:
Keep a list of Must Have, Should Have, and Nice to Have items.
You may have a strict deadline. You may have critical requirements that you must deliver.
Backlog can be updated. But you need to track the progress towards the project goal.
You may approach it the other way:
You can limit the amount of Story Points for a project. It is up to the Product Owner to decide how to spend this capacity.
That is not all…
Keep Scrum Events Intact
Major Scrum or Kanban events stay intact.
You, as a Scrum Master, still need to facilitate the work of your team.
Perform Sprint Planning in the usual way. As a Project Manager, you do want to track progress on “Must Have” User Stories on each iteration.
Based on the progress, you may need to update the expectations of stakeholders.
During Sprint Demo, it is still OK to get feedback and updates from Stakeholders.
It is Agile Project Management, after all.
In this case, it is good to ensure that you have a buffer of time during Sprints or during a release cycle. It helps you accommodate change requests.
You must make this clear to all stakeholders.
Retrospectives are also a good practice. Don’t skip on that.
However, you may want to make them once per release cycle.
It heavily depends on how good your team is.
How is it done in Kanban?
As for me, Kanban is a better framework for Agile Project Management.
As before, you do high-level planning. You need to break down the project scope into equal pieces. Preferably into tangible deliverables.
Work Breakdown Structure is a perfect tool for that. You can also use it to communicate project progress to other stakeholders.
Then, you need a Milestone Chart.
It will show approximate dates then you will deliver your intermediate deliveries to stakeholders.
It may not be at equal intervals. There are no iterations in Kanban. However, it helps you to use available resources and people more efficiently.
For example, you don’t need to keep your product or service ready to ship all the time.
Whenever you get a change request, break it down into the same equal pieces of work. Use the lead time to update milestones. Or update the priority of the deliverables.
Switching From Scrum to Kanban
You don’t have to stick strictly to one Agile Framework.
Frameworks have their pros and cons.
So, doing a bulk of the scope where requirements are not super clear is better with Scrum.
You get feedback from stakeholders regularly. It gives you an opportunity to set the rhythm for all of them.
Kanban may be helpful for testing, fixing defects, finishing up small tasks, or making final changes.
It also works well when one team works on different products or deliverables. That way, you can rapidly allocate resources to the priority area.
Stage 3: Finishing Project and Transition to the Next One
The product, service, or result is ready. You can ship it to the market. Or hand off it to the other team.
Doing this in an Agile way usually is not efficient. Your project team will not be involved in the process. At least the majority of them.
You need them on standby. But the majority of stakeholders will be engaged in moving your deliverables further.
Usually, they don’t have time or capacity to start a new project right away.
Your team has nothing to do.
Usually, this is not the case:
How to Keep the Scrum/Kanban Teams Busy
There is always some place for improvement. Some User Stories were left out of scope. Some technical debt is to be worked out.
Let me clarify one thing.
Agile Project Management works best when for product development. It means that you have a product or service in a sequence of projects or releases.
The more knowledge you have about the development of your product, the more efficient your project team is.
However.
If you have a one-time endeavor. If you don’t plan to continue improving your product or service. Then, you don’t need to worry about maintaining backlog, collecting feedback for future improvements, etc.
Also, you don’t plan to deliver increments to the market or users continuously.
You just need to plan the dates when you release your project team. In most of the cases, you would be better off with a plan-driven approach.
Agile Project Management Software
When selecting a software application for Agile Project Management, you need to focus on the Agile part.
Select a tool that supports Scrum or Kanban first of all.
Additionally, you will benefit from an integrated document collaboration tool.
So, the main apps that I usually suggest are:
With the addition of Confluence, Google Docs, Dropbox, etc.
The rest of the project planning should not be complicated too much.
Activities that go before and after Agile implementation can be tracked in tools like:
- OmniPlan
- MS Project
- Marlin Project
- Excel
Conclusion
Scrum and Kanban are not about doing things faster or better. They are about adaptivity.
Agile Project Management IS about doing things faster and better in a given environment.
It is up to you whether you choose to follow the underlying principles of Agile or plan-driven approaches.
It is up to you to balance the needs of a project to increase the chance of success.
Don’t let dogmatic minds prevent you from finishing project on time and within budget. Use all available tools and techniques.