My Projects Have to be Waterfall, What Can I do?
People often say to me, “My projects have to be waterfall. Is there anything from the lean and agile movement that I can begin to use, to improve delivery, without changing how my projects are delivered?”
My answer is always the same, “Yes!”
There are a number of things that can be implemented by a manager or project manager within their domain of control that will immediately improve their ability to deliver without impacting the project from the perspective of an external observer. I have three favorites:
- Improving teaming
- Periodic Retrospectives
- Mapping the value stream
In this article we will look at number 2: Periodic Retrospectives. A retrospective is similar to a Lesson’s learned exercise but different in some key areas. Traditional Lessons Learned sessions are useless for thee key reasons:
- Items are Team / Project / Technology specific
- They are held at the end of the project
- If items are not team, technology or project specific, they are so vague they are useless.
Let’s look at each of these in turn.
Items on the Lessons Learned are Team/Project/Technology Specific
The majority of the items that come up on a lessons learned session are specific to the project/team or technology for that project. Typical items that come up in a traditional lessons learned are things like, “The ice-a-nator vendor didn’t understand our requirements” or “The XYZ and ABC systems were not compatible and we didn’t know that during planning.” These are not really helpful because, the same team will not be on the next project, the project itself and the issues of the specific context will not be the same on the next project, and the technology will be different on the next project. So, I find that any project, team or technology specific items are not useful in a lessons learned context.
They are held at the end of the project.
Traditional lessons learned are held when the project is completed. Presumably to learn from what went on during the project and not make these same mistakes on future projects. The problem with this approach is most people can’t remember what happened 2 weeks ago much less what happened six months or 2 years ago. Trying to dredge up useful lessons learned over that period of time is nearly impossible. Additionally as we noted above, if the items are specific to the project, but the project is over, there is nothing to do with the information, no one can learn from it, nothing can be done with the information to improve future projects. Two strikes on this one.
If items are not team, technology or project specific they are so vague as to be useless.
In order to deal with the above two issues people will often generalize the information to make it universally applicable to future projects. If we attempt to generalize the lessons learned to make them applicable to other projects they get so generic as to be useless. I hear things like, “Communication was a problem”, “Stakeholders should be more involved”, “Budgets should have been more controlled.” And things like that. While these statements may be true, they are useless because they make no recommendation of root cause or corrective action. How could they? Nearly every real problem that could/ should be addressed to improve production, is a tangled web of interdependent project, team and technology specific issues that interplay creating the issue. Every project has its own unique web of issues making general solutions very rare indeed.
So What can be learned from a Lean/Agile approach?
There is a fundamental difference between traditional lessons learned and the lean/agile approach, in how, when and why they are done. Traditional lessons learned are done to help future projects to not make the same mistakes made on the project. Lean and agile lessons learned (typically called retrospective or Kaizen events) are intended to make immediate improvements on the current project. Call them what you like they are frequently held events to improve the process of the current project by small steps over time.
Changing the purpose and frequency of the lessons learned sessions resolves the three issues that plague the traditional lessons learned. Let’s look at the impact it has on the problems of a typical lessons learned.
Items on the Lessons Learned are Team/Project/Technology Specific
The items identified are still specific to the team, project or technology, but that is ok because the team project and technology are currently in flight and the team in the retrospective/Kaizen has the knowledge and context to do something about the items identified.
They are held at the end of the project.
Lean/Agile sessions are not held at the end of the project, they are held frequently (every 2 – 4 weeks) throughout the project. This results in three key outcomes. 1) It is much easier to remember what went well and what needed improvement, to make changes over a short time period than a long one. 2) The sessions are held mid-project so the items can be acted upon by the team that identified them, in the context that they have relevance. 3) Another session will be held in a couple of weeks, which allows the team to inspect the results of the actions they took to rectify a problem and adapt a new solution if the last one didn’t fix the problem.
If items are not team, technology or project specific they are so vague as to be useless.
In a Retrospective / Kaizen event items are not generalized so much that they are useless. The meeting is not over until the problems, root causes and solutions are made very clear and are given specific actions that are planned into the project to improve the working of the group. Finally they are checked at the next retrospective / Kaizen to see if the action was taken and if it had the intended results.
Anyone can improve their teams ability to deliver by learning how lean and agile teams do lesson’s learned and starting to use them to incrementally improve over time, even if their project is managed with a traditional approach.
Don’t forget to leave your comments below.