Overcoming Management's Perceived Disempowerment During Agile Transformations
Since my career delivered me to the world of agile, I have mainly worked with organisations that were in the process of an agile transformation. This is a very different environment to any other. When an organisation makes any kind of large scale cultural change it is almost inevitable that it will face problems from almost everyone who wasn't involved (or felt they were involved) in the decision to transition. When we as a community talk about agile, we typically talk about the empowerment of this or that group. In this post I'm going to explore what empowering a team means from a middle management level, which in my experience is often the level where agile transformations can fail spectacularly.
I've only seen an agile transformation be driven by middle management once. All other times I've seen it come either from the trenches or top management, and as such I recognise that not everyone will be able to relate directly to the below. However, I suspect that even those who have seen transformations driven from some of middle management will be able to recognise the themes I touch on here. I discuss these in no particular order other than to try to maintain some flow between the themes. I think all these are weighted differently within different organisations and at different points of a transition.
The first question I try to answer when learning about the current state of an organisation's transition is: Who was consulted prior to the decision being made? As we know in the world of agile, before asking a team to make a commitment we ensure that everyone is heard, everyone's concerns are addressed, and only when everyone feels willing to commit to a given task / situation / experiment can the team be fully committed to ensuring that they succeed. The irony here being that agile can only be born out of a non-agile environment, and therefore one of our crucial tenants is rarely followed in the very introduction of our philosophy. If an organisation brings in a coach early enough (they never do) then there is hope that everyone can feel heard, has had a chance to understand what is meant, and then commit fully to the transformation. If they haven't done so then addressing the fears of those who weren't consulted is a good place to start.
Those who are well embedded into a system are comfortable with that system's paradigm and the language that surrounds it. Going from PRINCE2 to agile (DSDM, Scrum, whatever) means that everything that person knows is now wrong. As much as I hear people try, there is no good mapping of one to the other. One cannot simply say that a Product Owner is a bit like a Project Manager. The difference of scope is not similar enough to convey in such a statement to the uninitiated. In order to really understand the new paradigm and language that the organisation is transitioning to, one has to study.
Although those of us with a technology background are used to relearning our jobs every six months to a year, this is not the norm outside of STEM (Science, Technology, Engineering, Mathematics) sectors. Regardless of the product a business produces, business people are not part of a STEM sector. I have friends who learned their paradigms decades ago, are comfortable with it, and are so ingrained with it that they can't even imagine that there could be any other way of doing it. They know that the job for life went away a generation or two ago, but they do still expect that they can do the same role for life even if it does mean moving company every now and again.
However, here we now are and the organisation has decided that agile will make them more money or cost them less money. This person who's been working in the same way all their life has now been told that their job has completely changed and they better get used to it or leave. So now they have been unexpectedly asked to relearn everything. Some of these people may not have studied anything new since they left education. Any study skills they may have had are likely to be dusty at best. Now they're older, with a mortgage, family responsibilities, and goodness knows what else going on in their lives.
If an organisation expects a person to learn they better give them as much support as possible. Do not expect them to study in their own time; they have no desire to do so, and maybe not even the time to do so (remember the spouse and kids). Do send them on training courses; not only will this help to get them up to speed, but it will show them that you are willing to invest in their professional development. One of the top reasons that people leave their job is due to a lack of training, so you get the extra benefit of employee retention. Do give them a support network. Perhaps you can't afford (or justify to higher up) an agile coach, but you may be able to get someone to come in for an hour or two. If you're lucky enough to live in a city where there is a large agile community, then try to organise a company expense paid evening out with a morning off in lieu. This last one definitely shouldn't be it all though, as conflicting with personal commitments could cause the employee to want to leave more instead of less.
Besides the external pressures of a transformation, we must not forget the psychological distress that can come from having a new job forced upon one. In most situations, it is our choice to change job or role, and it can be a decision that has been a long time coming. When one's manager says that they are now a product owner or a scrum master without warning then there is no time to adjust. We need to not only give people time and support so they can adjust to their new role, but also time to grieve for their old one.
At this point 1-2-1 meetings are crucial. This allows for top management to support and reassure the middle management, the middle management to voice their concerns or problems that they are beginning to see arise, and both sides to feedback the positive things that are happening as part of the transformation. As agilists we value face to face communication and frequent feedback loops. Let's use these values to help guide us through the rocky road of transition, and start as we mean to go on. This may be the hardest part of the transformation as it involves a person's self-identity.
Now that you have started the process, it is time to explain that your middle manager is now a servant leader. This should be where their self-identity now stems from. No longer are they to tell someone what they should do and be accountable for whether or not that person does it; instead they tell the person what needs to be done and help them to design and build a solution. The servant leader's ability is judged upon whether they managed to remove current or block potential impediments; whether they themselves were an impediment to the team; how well things are progressing both in output and personal and team growth; were goals met; was an incremental product delivered? There are many other metrics that can be used to test a servant leader's abilities.
As more and more companies start their agile transformations, the more we're going to see agile done badly. It is the duty of all us who have seen the agile light to help guide and mentor others so that they can successfully move into a world that we already know is better.
I've only seen an agile transformation be driven by middle management once. All other times I've seen it come either from the trenches or top management, and as such I recognise that not everyone will be able to relate directly to the below. However, I suspect that even those who have seen transformations driven from some of middle management will be able to recognise the themes I touch on here. I discuss these in no particular order other than to try to maintain some flow between the themes. I think all these are weighted differently within different organisations and at different points of a transition.
The first question I try to answer when learning about the current state of an organisation's transition is: Who was consulted prior to the decision being made? As we know in the world of agile, before asking a team to make a commitment we ensure that everyone is heard, everyone's concerns are addressed, and only when everyone feels willing to commit to a given task / situation / experiment can the team be fully committed to ensuring that they succeed. The irony here being that agile can only be born out of a non-agile environment, and therefore one of our crucial tenants is rarely followed in the very introduction of our philosophy. If an organisation brings in a coach early enough (they never do) then there is hope that everyone can feel heard, has had a chance to understand what is meant, and then commit fully to the transformation. If they haven't done so then addressing the fears of those who weren't consulted is a good place to start.
Those who are well embedded into a system are comfortable with that system's paradigm and the language that surrounds it. Going from PRINCE2 to agile (DSDM, Scrum, whatever) means that everything that person knows is now wrong. As much as I hear people try, there is no good mapping of one to the other. One cannot simply say that a Product Owner is a bit like a Project Manager. The difference of scope is not similar enough to convey in such a statement to the uninitiated. In order to really understand the new paradigm and language that the organisation is transitioning to, one has to study.
Although those of us with a technology background are used to relearning our jobs every six months to a year, this is not the norm outside of STEM (Science, Technology, Engineering, Mathematics) sectors. Regardless of the product a business produces, business people are not part of a STEM sector. I have friends who learned their paradigms decades ago, are comfortable with it, and are so ingrained with it that they can't even imagine that there could be any other way of doing it. They know that the job for life went away a generation or two ago, but they do still expect that they can do the same role for life even if it does mean moving company every now and again.
However, here we now are and the organisation has decided that agile will make them more money or cost them less money. This person who's been working in the same way all their life has now been told that their job has completely changed and they better get used to it or leave. So now they have been unexpectedly asked to relearn everything. Some of these people may not have studied anything new since they left education. Any study skills they may have had are likely to be dusty at best. Now they're older, with a mortgage, family responsibilities, and goodness knows what else going on in their lives.
If an organisation expects a person to learn they better give them as much support as possible. Do not expect them to study in their own time; they have no desire to do so, and maybe not even the time to do so (remember the spouse and kids). Do send them on training courses; not only will this help to get them up to speed, but it will show them that you are willing to invest in their professional development. One of the top reasons that people leave their job is due to a lack of training, so you get the extra benefit of employee retention. Do give them a support network. Perhaps you can't afford (or justify to higher up) an agile coach, but you may be able to get someone to come in for an hour or two. If you're lucky enough to live in a city where there is a large agile community, then try to organise a company expense paid evening out with a morning off in lieu. This last one definitely shouldn't be it all though, as conflicting with personal commitments could cause the employee to want to leave more instead of less.
Besides the external pressures of a transformation, we must not forget the psychological distress that can come from having a new job forced upon one. In most situations, it is our choice to change job or role, and it can be a decision that has been a long time coming. When one's manager says that they are now a product owner or a scrum master without warning then there is no time to adjust. We need to not only give people time and support so they can adjust to their new role, but also time to grieve for their old one.
At this point 1-2-1 meetings are crucial. This allows for top management to support and reassure the middle management, the middle management to voice their concerns or problems that they are beginning to see arise, and both sides to feedback the positive things that are happening as part of the transformation. As agilists we value face to face communication and frequent feedback loops. Let's use these values to help guide us through the rocky road of transition, and start as we mean to go on. This may be the hardest part of the transformation as it involves a person's self-identity.
Now that you have started the process, it is time to explain that your middle manager is now a servant leader. This should be where their self-identity now stems from. No longer are they to tell someone what they should do and be accountable for whether or not that person does it; instead they tell the person what needs to be done and help them to design and build a solution. The servant leader's ability is judged upon whether they managed to remove current or block potential impediments; whether they themselves were an impediment to the team; how well things are progressing both in output and personal and team growth; were goals met; was an incremental product delivered? There are many other metrics that can be used to test a servant leader's abilities.
As more and more companies start their agile transformations, the more we're going to see agile done badly. It is the duty of all us who have seen the agile light to help guide and mentor others so that they can successfully move into a world that we already know is better.
No comments :
Post a Comment