What to reply to a waterfall-minded Head of Section
Dear community,
I am in a situation where I might need your advice.
In our organization, it was decided to slowly adapt agile principles, which I very fully support.
I am in charge of a certain process. This process also contains several manual tasks which could potentially be automatized and I am trying to convince my Head of Section that this would be money worth spent.
His response was “Probably, this process will still be in place for the next five years. So I need to know how many FTEs are needed for this manual process. Then I want to know which tasks have to be implemented for the automatization, how many PDs are needed for that, in which order they could be finalized by which date. I will then apply a certain amount for every PD, discount this according to the execution date and then I will see whether there is a benefit in the automatization in comparison to the manual process.”
Now, this is anything but agile and we all know that it is almost impossible to create such a plan with the required accuracy.
What should an agile-minded person reply to the Head of Section in this case?
Thank you very much for your support!
It would be nice to know what FTE & PD means. .-)
One thing I can suggest is to use evidence based management to gather metric data and how you work now, research the purchase & implementation costs for the automation tools required to replace the manual actions, and then determine how long it will take to recoup those costs once in place.
That information as part of your business case along with a forecast for future productivity of your scrum teams if those tools were to be incorporated, should hopefully be enough to convince your head of section. If not, you could always present your findings to upper management if you are the scrum master, or get the scrum master to do this as this is part of their service to the organisation.
Instead of "telling them" or "explaining why they are wrong" I tend to take them on a journey. A journey of questions based in curiosity and a will to know. I often start by trying to reach a concensus on very basic things. Like how getting feedback early is a good thing (if they have arguments against I'm willing to listen... normally they don't), then how more time between releases causes more time to elapse between feedback cycles, how inspecting and adapting to what we learn is a good thing etc.
Once they are on board with that I ask about their current setup, what problems they might have, what if anything in it supports or works against what we just agreed was good things.
When they have already agreed to the basics it tends to be harder to argue against the actual work and changes needed to implement agile practices.
Sure, they can blame old legacy processes etc. But they must all of a sudden sign off on k owing what they are doing isn't optimal but still to continue doing it. Here is where corporate survival instincts begin to kick in and they don't want to be the ones who the old car into the ditch and they start to open up to what we could to to make things better.
But the "point" here is, try to get them on board with the basic ideas, and demystifying everything first before pointing out things that needs to change. Doing it the other way can create a very defensive response from many people.
In our organization, it was decided to slowly adapt agile principles, which I very fully support.
Who decided this? If it wasn't your "Head of Section" who was it...and why aren't they communicating and reinforcing a sense of urgency for change?
A change in the way work is done doesn't happen without sponsorship by, and communication from, the C-suite. Remember that agile, scrum and other methodologies really all originated from product management best practices. So where is product in your conversation? Are you in a product organization or does your company run projects?
Try thinking about it from his/her side. They likely see automating the work as a risk (potential ROI loss). You see it as a reward (potential ROI gain).
Try to map out both sides of the story whilst remembering that your viewpoints and accountabilities are different.
Whilst I agree that people aren't impediments, the sponsor of the transformation needs to be helping drive a cultural change - where are they in this discussion? If that involves them telling the HoS to get onboard then so be it. There is a fine line between allowing a team to be self-managing and not being afraid to take direct action if needed.
You need a clear conversation with your head of section regarding who is the owner of the process.
Are you there to be a proxy, a development team member, or the product owner.
1. If the Head of Section is the Product Owner for the business process, then you need to understand from them how to define value. So how do you determine the difference between the value of the business process, and the cost of the business process?
How finely grained do you need to model that business process?
A customer journey map will give you the pain points, opportunities to improve, and cost per activity for both the current and the idealised business process. From an Agility perspective - "how much time do I spend documenting this?" is the question (or to rephase, what is the least amount of documentation you need, to be able to set priorities?)
2. If you're meant to be the product owner of this process and your section head is somebody that the owners of several business processes all report to - you need a different conversation about what product ownership means.