Do you plan on running Agile Projects in your organization? Then make sure to do it the right way. Quickly taking a Scrum Master course, and still running Agile projects with a Waterfall attitude, is the route to failure. Setting up Agile projects in a Waterfall environment requires a shift in attitude of the team and a different management style. If you get this right, it’s absolutely possible to run Agile and Waterfall projects in parallel.
I have come to learn that there are three levels of expertise. Two types of experts are harmless. The third expertise level is dangerous.
My plumber agrees. He meets the same three expertise levels when fixing heating systems.
The first type of experts are the people with no expertise at all. These are the people who don’t know anything about heating systems and don’t dare touching it. Instead, they wisely decide to call an expert.
Another level of expertise are the domain experts. They know exactly what they are doing, and what they should (or shouldn’t) be touching. They also have the right tools and measurement instruments to e.g. measure fuel utilization efficiency or CO emissions.
These two expertise levels are the harmless ones. The third and dangerous experts are the people that know only a bit of the heating system. The ones that have read about it.
They know just enough to start fiddling around with the heater settings. They feel they are expert enough to take the heater apart. But they don’t have the right expertise, or equipment, to configure the right parameters. These experts are the ones that didn’t realize you have to replace the seal instead of putting the old one back in. These experts are the ones that end up with that one remaining bolt and decide it wasn’t needed anyway.
At best they still call an expert to do it right. Worst case they break things.
I was cast back to that discussion with my plumber recently. I was telling a team of project managers that they will become extinct, now that a lot of projects were moving to an Agile track.
To my surprise the project managers were not concerned. They happily announced: “It’s ok. We’re safe, because we all passed a Scrum Master course”.
Ten minutes later one project manager explained he had urged his customer to provide all detailed User Requirements upfront. He wanted to create all User Stories in his Agile project already, so he could better plan the project. Another project manager chimed in and explained she assigned User Stories to her team members every morning to make sure the scrum team delivered in line with her planning.
See, this is the dangerous expertise level. Taking a Scrum Master training does not make you an Agile expert.
At best you realize you need an Agile expert to guide you. Worst case you will break your Agile projects.
It took me a while to explain that a project manager cannot easily become an Agile Scrum Master (*) and keep behaving the old way. As a matter of fact, managing different types of projects (Change, Agile, Waterfall) requires a totally different attitude from the team, from the project manager, and from senior management. A project manager is accountable in Waterfall projects, but not in Agile or Change projects. In Agile projects the Product Owner and Scrum Team are accountable. In Change projects the Operations (or DevOps) organization is accountable. It requires a shift in responsibility, and trust (**).
The difference in management style is part of the Chagwa theory, and I will go into more detail in my next blogs. If you want to learn more about this, I invite you to my next trainings on the Chagwa theory in April and September. The training explains why it is so difficult to combine Agile and Waterfall, and how they can still be run in parallel. The training also explains the different way of thinking and management style.
Subscribing to the training can be done at The Bayard Partnership Academy with the following link. I’m available for in company trainings as well. Do not hesitate to contact me if you want more information for yourself or your organization.
(*) A Scrum Master is a member of the scrum team, typically the developer with more Agile experience. It can also be someone who supports multiple Agile teams. “Supports”, and not “manages”! The Scrum Master works with the Product Owner for solving impediments or setting User Story priorities for the next sprint.
There can be a need for a project manager to oversee multiple Agile projects. In that case, the project manager then works with the Product Owners and Scrum Masters. The project manager never interferes with the scrum teams, and should never touch the User Stories.
(**) If you are a Project Manager in an organization that is moving to Agile, consider becoming an Organizational Change Manager or Product Owner instead. An excellent course on Change Management is given by Harley Lovegrove. You can find the course with the following link.