Communication, one of the agile pillars
We think we are doing well but we are not
Nowadays everyone is agile, "yes we are doing agile, so therefore we are agile"...
Let's do a deep dive on that:
"Why do you think you are agile?"
"Well we do all the ceremonies scrum expects us to do, most of the times, dailies are close to 20' or 15' mins, we work in teams that can self organize and the teams deliver demos to business teams regularly in 2 weeks iterations".
"And when does the user see the product?"
"Well not until this set of features is finished",
"And when is that?"
"In 9 months".
Organizations learned how to keep the appearances of agile, and many think that, by doing what they are doing, they are on the right track. There's a lot of implementations that at the top, are still using waterfall, but with agile terms.
Resistance to change isn't new in IT, and there's quite a jump out of the comfort zone people need to do.
And it's a jump away from the artifacts that traditional managers usually think would be useful, since those actually go against the change embracement we say we support, like detailed designs, fully defined features in Gantt charts, etc.
To make the change happen it's possible that you might need to find help in the management, but you have to work hard in undoing the hallow agile apparent victories that they've achieved so far, along with the change resistance, in order to make some positive step forward.
In this brief entry I'll try to review the communication perspective to help you get there.
That's how easy it is to fall in the pitfall as well, of believing that as managers, (even when we may fail) we usually know what's best. That might be true, but if you are trying to get an agile organization, you need to get the team to reach that conclusion.
Giving the answer as something to be acknowledged and followed through, will conduct the teams to a dependency of your work, that at a certain point you will realize it is a bottleneck risk. You might even be growing this same thinking in the dev team below you, teaching them the culture that a single guy with all the knowledge is something that makes sense, and that they all should aspire to be "That guy".
To have the teams thinking solving things for you (so that you can take the bigger issues they might have), you need the teams to communicate to you what they are going to do with the problem. Yes, you can add your knowledge to those discussions, if you think you might save time of everyone, but try to get them to know how you created your trail of thought. Maybe they find stuff you didn't, after all you are in a management position, not a developer as in a trenches defects/issues solver. Foster their self-organization by helping achieve without delivering solved stuff. Let them learn how to squeeze their brains out to get to a solution, and the fact that them, coming with a solution, is something expected.
Promote team thinking, by exemplifying the right team thinking behaviors. Reassuring the one that absorbs all the problems in the team showing it to everyone as something to be expected, will replicate your culture problem within your teams with "that guy". The rest of the devs will start relying in that guy for everything.
Teams will start accepting that "The risk of failing is not worth the effort". Getting people to communicate openly with their manager is something really hard, because by the way a manager applauds or berates behaviors is what their subordinates understand they will see the world, so mistakes might not be good to communicate if they are that way. Also, as we said before, the manager might have the pressing need to solve stuff by himself, and more than understandable, it's how the human mind works: if you are being told a problem in your face, and you have the tools to solve it, Why wouldn't you?
The thing is that getting the manager to solve that problem will only help you on a short term. Most likely, it won't be long before things start happening again when the manager is not looking at that problem. As a manager you need to get the teams to trust you, and to do that, you have three things to consider:
1. If someone came with a communication problem, ask first if they've confronted this issue themselves, what they've tried, what they expect from the communication they are doing with you.
2. Do not go for the actual problem to solve it, get the team to think on a solution, and get the team to define what they need to do.
3. Do not only applaud the victories, go to those that had a failure to say, "Ok this didn't work, did you learn from this? what did you learn? What will you try next?" This will tell them that you are interested in the improvement, not in the expectation of absolute unforgiving perfection. Saying "We cannot fail" is the same as saying "We shouldn't try".
Try to adjust your speech to promote the behaviors you want in your company.
I've seen a team being considered the most effective one, since the delivery was always aligned to what was agreed on planning session on a regular base, but behind the curtain you might find a team that sometimes skips retros, for sure skips innovation days, and every now and then do extra hours, just to keep the trust placed on them. We are building "that guy" there.
There are lots of positions that are impacted by the agile mindshift, but still some consider they are outside of that change: "Let IT do the projects we are asking them to do, to do it through whatever they want, I've been told that agile is the next best thing for them."
Heads up dude, this relatively new "way of doing things" requires your involvement in the process early on. No longer you'll find that you can leave a detailed plan/product and come back 8 months later to see if that's done or otherwise put pressure on the teams that are not delivering, well "no longer" if you are interested in the project's success, that is.
The manager saying to the team -"The Product team is really concerned about the performance and therefore so am I, what is happening, team?"
These are clues that the communication is finding an intermediary that won't add but delays (at best), and noise (at worst) to the subject. If you have something that didn't work well, get whoever feels that way to express that openly to the team, most likely on a retrospective session. You might feel that you are saving people time, but you are only doing a telephone game. If something might save time if you don't involve the whole team, get the team to define if they want a team representative to participate and respond as the team would.
Communication goes both ways, get the team to define who they need to talk to when they need to, and try to be there to help them achieve their goals.
Teams should be used to get the communications needed ad-hoc, and whenever needed, the team should request and make them. Even propose and host them. A team once told me just 2 hours after the retrospective meeting, that some issues started happening right then and there, and asked what should we do with it. I told the team, "what do you think is most efficient?", one guy replied "I would like to have a second retro about this, but I don't know if this would be disruptive with scrum". It doesn't matter if you are breaking scrum, if the whole team defines that it is the best course of action. Just make sure it is what the team feels the best usage of their time.
Same goes with blockers within the team. As a scrum team member, don't wait for a daily to communicate them, if you are blocked more than a determined amount of time in which you think that progressing on your own won't add value, tell your scrum team of your blocker through any common sharing place.
Your managers are key to make the agile shift happen, so make sure you work close to them to help them do the mindshift forward happen on them first.
Nowadays everyone is agile, "yes we are doing agile, so therefore we are agile"...
Let's do a deep dive on that:
"Why do you think you are agile?"
"Well we do all the ceremonies scrum expects us to do, most of the times, dailies are close to 20' or 15' mins, we work in teams that can self organize and the teams deliver demos to business teams regularly in 2 weeks iterations".
"And when does the user see the product?"
"Well not until this set of features is finished",
"And when is that?"
"In 9 months".
Organizations learned how to keep the appearances of agile, and many think that, by doing what they are doing, they are on the right track. There's a lot of implementations that at the top, are still using waterfall, but with agile terms.
Resistance to change isn't new in IT, and there's quite a jump out of the comfort zone people need to do.
And it's a jump away from the artifacts that traditional managers usually think would be useful, since those actually go against the change embracement we say we support, like detailed designs, fully defined features in Gantt charts, etc.
To make the change happen it's possible that you might need to find help in the management, but you have to work hard in undoing the hallow agile apparent victories that they've achieved so far, along with the change resistance, in order to make some positive step forward.
In this brief entry I'll try to review the communication perspective to help you get there.
Communication top down
It's really alluring for a manager who had quite some experience in the field, to take direct action. Say a teams is struggling with a particular problem, and need to come up with a solution: The manager then tells them what needs to be done and get them to do it.That's how easy it is to fall in the pitfall as well, of believing that as managers, (even when we may fail) we usually know what's best. That might be true, but if you are trying to get an agile organization, you need to get the team to reach that conclusion.
Giving the answer as something to be acknowledged and followed through, will conduct the teams to a dependency of your work, that at a certain point you will realize it is a bottleneck risk. You might even be growing this same thinking in the dev team below you, teaching them the culture that a single guy with all the knowledge is something that makes sense, and that they all should aspire to be "That guy".
To have the teams thinking solving things for you (so that you can take the bigger issues they might have), you need the teams to communicate to you what they are going to do with the problem. Yes, you can add your knowledge to those discussions, if you think you might save time of everyone, but try to get them to know how you created your trail of thought. Maybe they find stuff you didn't, after all you are in a management position, not a developer as in a trenches defects/issues solver. Foster their self-organization by helping achieve without delivering solved stuff. Let them learn how to squeeze their brains out to get to a solution, and the fact that them, coming with a solution, is something expected.
Promote team thinking, by exemplifying the right team thinking behaviors. Reassuring the one that absorbs all the problems in the team showing it to everyone as something to be expected, will replicate your culture problem within your teams with "that guy". The rest of the devs will start relying in that guy for everything.
Openness
"Tell me who did this and we'll talk to him", almost like a mobster. "Whoever did that needs to understand that this is not the way". Transforming the failures into actual problems and doing a witch hunt on what has happened, won't get you moving forward under an agile organization, even if you are trying to get an example on what not to do. It will get people fearful of making mistakes, therefore, stuck without interest in taking time to innovate, afraid to be pointed out as unproductive or being without willingness to make any change.Teams will start accepting that "The risk of failing is not worth the effort". Getting people to communicate openly with their manager is something really hard, because by the way a manager applauds or berates behaviors is what their subordinates understand they will see the world, so mistakes might not be good to communicate if they are that way. Also, as we said before, the manager might have the pressing need to solve stuff by himself, and more than understandable, it's how the human mind works: if you are being told a problem in your face, and you have the tools to solve it, Why wouldn't you?
The thing is that getting the manager to solve that problem will only help you on a short term. Most likely, it won't be long before things start happening again when the manager is not looking at that problem. As a manager you need to get the teams to trust you, and to do that, you have three things to consider:
1. If someone came with a communication problem, ask first if they've confronted this issue themselves, what they've tried, what they expect from the communication they are doing with you.
2. Do not go for the actual problem to solve it, get the team to think on a solution, and get the team to define what they need to do.
3. Do not only applaud the victories, go to those that had a failure to say, "Ok this didn't work, did you learn from this? what did you learn? What will you try next?" This will tell them that you are interested in the improvement, not in the expectation of absolute unforgiving perfection. Saying "We cannot fail" is the same as saying "We shouldn't try".
Try to adjust your speech to promote the behaviors you want in your company.
I've seen a team being considered the most effective one, since the delivery was always aligned to what was agreed on planning session on a regular base, but behind the curtain you might find a team that sometimes skips retros, for sure skips innovation days, and every now and then do extra hours, just to keep the trust placed on them. We are building "that guy" there.
Us vs them
Communication outside of IT being done in an agile way, with business and leadership levels is as crucial as the team's internal communication if not even more. Assuming that the IT teams can be agile, while the rest of the organization keeps working the way they were before that, might be a mistake.There are lots of positions that are impacted by the agile mindshift, but still some consider they are outside of that change: "Let IT do the projects we are asking them to do, to do it through whatever they want, I've been told that agile is the next best thing for them."
Heads up dude, this relatively new "way of doing things" requires your involvement in the process early on. No longer you'll find that you can leave a detailed plan/product and come back 8 months later to see if that's done or otherwise put pressure on the teams that are not delivering, well "no longer" if you are interested in the project's success, that is.
Remove bottlenecks and intermediaries
-"I will talk to the team X about this and will let you know what they want to do."The manager saying to the team -"The Product team is really concerned about the performance and therefore so am I, what is happening, team?"
These are clues that the communication is finding an intermediary that won't add but delays (at best), and noise (at worst) to the subject. If you have something that didn't work well, get whoever feels that way to express that openly to the team, most likely on a retrospective session. You might feel that you are saving people time, but you are only doing a telephone game. If something might save time if you don't involve the whole team, get the team to define if they want a team representative to participate and respond as the team would.
Self organizing communication
Instead of pointing "one guy" out of each team who earned your trust to do stuff for the team, or as "a designated one" who should get and distribute the communications; get the team to receive all communications sent to them, use tech at your disposal such as slack to communicate those kind of things at a group chat.Communication goes both ways, get the team to define who they need to talk to when they need to, and try to be there to help them achieve their goals.
Teams should be used to get the communications needed ad-hoc, and whenever needed, the team should request and make them. Even propose and host them. A team once told me just 2 hours after the retrospective meeting, that some issues started happening right then and there, and asked what should we do with it. I told the team, "what do you think is most efficient?", one guy replied "I would like to have a second retro about this, but I don't know if this would be disruptive with scrum". It doesn't matter if you are breaking scrum, if the whole team defines that it is the best course of action. Just make sure it is what the team feels the best usage of their time.
Same goes with blockers within the team. As a scrum team member, don't wait for a daily to communicate them, if you are blocked more than a determined amount of time in which you think that progressing on your own won't add value, tell your scrum team of your blocker through any common sharing place.
Break the glass ceiling
In organizations going through an agile transformation, we still see that there is sometimes teams external to the agile team that are hiding through a wall of tickets, making dependencies insufferable. This is not something that the teams can solve by themselves, and their self organization will need help from the manager to get this wall breached, by explaining what we are trying to do and let them go past the process to find a new process if necessary to make things progress at their intended pace.Your managers are key to make the agile shift happen, so make sure you work close to them to help them do the mindshift forward happen on them first.
Comments
Post a Comment