Agile project management according to DSDM Atern is more a guideline than a strict method. The strength of it is that it provides tools to deliver a product – usually, but not limited to software – incrementally and iteratively, without exceeding costs and compromising quality, all within a fixed time to meet the end date of the project. Because of this, I think it can be combined very well with a lean approach within each stage and timebox, to make sure that the deliverables still meet the wish of the customer. Even pull-based delivery is possible.
Agile and Lean
Although Agile and Lean are two different methods – the first a project management method and rather a framework, the second a process management method and rather rigid – they can be very complementary to each other because of the partial similar baselines and approach.
- Both methods are based on adding true value for the customer, even if this means adapting to changes during the project, while the more traditional approaches are based on delivering what was agreed at the start of the project.
- In both methods, team members are highly responsible for their own actions. Management is merely facilitating rather than managing on microlevel.
- Quality is not to be compromised in the agile approach. Continuous improvement is of tremendous importance in the lean approach.<
- Agile delivery is incremental and iterative. The lean approach can be very helpful to check quickly how every delivery can be realized in the most effective way without compromising quality, delivery time or costs.
- Agile project management recognizes changed requirements of the end product, due to evolved insights of the business. With a lean approach, a change can be quickly implemented.
Two different lean approaches
It helps that an agile project approach facilitates changes, while the more traditional approaches do not. Also, it helps to know that lean has basically two different approaches to achieve the goal:
- Usage of a set of tools to identify and eliminate waste (muda).
This may be fit for the project team, for they are usually assembled during the pre-project phase and it is not always likely that they will work together after the post-project phase. Also, the team needs to focus on a timely delivery of a (partial) solution in the operational phase. This approach is tools-based and can create quick wins, which makes it useful in iterative and incremental delivery situations.
- Focus on continuous flow (mura), and by doing so, eliminate waste and prevent overburden (muri).
This will be the better choice for the project manager. The goal does not change, after all, and the project manager has the overview to adopt this approach. Creating a continuous flow of iterations (heijunka, production leveling) and capturing this in the planning (the timeboxes) will prevent overburden and waste which might not be exposed in the first approach. This approach is much more holistic, which helps to make the team, the solution and the general approach sustainable and ‘alive’.
Combining an agile approach of and supported by the lean approach throughout the project, the lifecycle of a project, each step as described below should be questioned over and over again:
- What is the added value of the (partial) product / service (deliverable) for our customer (quality check… every time, all the time).
- What are the steps to create this added value. And which steps can be eliminated.
- How can I assure that this next step fits seamlessly into the previous step. How can I create a flow from one increment to another.
- At what point can I offer the solution to my customer (or at least, to the test team). When is the product fit for use.
- Continuous improvement from step one. Over time, tools and insights can change and so can your (future) customer’s demands.
Agile Life Cycle
- Pre-Project: here, you will agree on all the necessary parts of the project. Deliverables (your product or service), the definition of ‘Quality’, the definition of ‘Done’, MoSCoW, planning, resources, risks, follow up actions after final deployment for example. Here, it is assumed that before thinking about initiating a project, an investigation regarding the added value to the customer has been executed already.
For each action as below, whether singular or iterative, the lean approach will be of tremendous help to make sure everyone is still talking about the same subject. Ask yourself the questions. Every time.
Multiple action (for each deliverable, partial or complete)
- Feasibility and Foundations: for each partial deliverable of the project, you will need to investigate the feasibility and what the basic needs are to start development or production in means of terms. At this stage, the lean approach can be of tremendous help already.
- Exploration: at this stage, you will need to deeply explore the business needs in order to translate them into a viable solution.
- Engineering: the actual translation of the business needs. Here, the partial solution will actually be developed, created and tested. Make sure that you – the team – continuously delivers a (partial) solution timely and according to the quality agreed.
- Deployment: when the partial solution is finished, it has to be connected with the other parts. In the beginning, that is. Later in the project, the solution must be added to the previous deployed (and tested) parts. When a solution is fit for testing by users, as well as the test team, you should start this, too. Also, in this phase, manuals are written and made available and trainings are provided.
- Post-Project: after the solution has been delivered, the quality is set and the finances are signed for, your work hasn’t been done yet. A follow up might be required and changes in the solution may be necessary.
My personal conclusion
Even though the lean method is quite rigid by itself, it can be used by modern project management methods because of the similarities and applicability in short iterations. It does not overload the team members with extra work; during the daily stand up meetings, the lean approach can be repeated in a short and informal way. The same counts for larger team meetings and meetings with the business owner, provided the agile project management method is adopted.
The traditional approaches, based on ‘waterfall delivery’, can make use of the lean approach as well for each stage. However, there may occur issues with one of the pillars of the lean approach: continuous improvement. With waterfall delivery, it is hard to improve when a stage is already signed for and going back is not an option. Because of the lack of continuous improvement, quality can be compromised while costs can rise.
I do not say that the traditional approaches are unusable in themselves. When the end product and main conditions are rigid because of their nature, I think that traditional project management methods are still favorable over agile project management methods. Of course, this may change over time, but that time has not yet come.
For now, I can only say that I think Agile and Lean are a really happy couple.