The company where I work in is undergoing a process change. More specifically, it's branded as an "Agile transformation", which in my eyes is a rather necessary step, as we are dealing with the pains of growing from a small startup to a larger organization, and the informal channels that were so great before are now creating chaos and making it that much harder to get work done. In order to do this properly, we have brought some external coaches to help us figure out the right process for us. It started pretty well: The VP of engineering has stated our goal in a town-hall meeting, and introduced the consultants who were to start working soon. At least to me, the message was pretty clear, and it was nice to focus our attention on our working process.
Then, at least from my perspective it went downhill. However, before I go on to identify the mistakes I saw I want to clarify my point of view - I am an individual contributor in the company, one of about 70 (If I have my numbers right). I'm not part of the leadership team and did not attend many of the meetings, so I'm assuming I don't see many of the constraints.
With this disclaimer out in the open, the list of botches is short but seemingly fatal.
After the first announcement came more than a month of silence. We've seen the consultants wander around in the corridors or sitting with upper management in meetings, but nothing was transmitted down. We were left in the dark about the prep work they were probably doing. This long period of time meant that momentum was lost after a good pitch and it also gave people time to speculate, to worry and to build a negative image of the consultants. After all, when you see someone every office day, you expect to have at least a rough idea about what they do. If you can't get that, assuming this person does nothing is the default. This dark period was long enough that I went to the PM (who had a strong part in coordinating this transition) when they plan to start working, which I only did after someone in my team asked me whether such conduct is normal.
They were, probably, gathering information and building a strategy for the organization, which leads me to the second botch: They talked almost exclusively to management. I know that they asked for some names of non-managers to talk to, but have no idea whether they followed up with any of them. I know that my name was given to them and that I was not approached . Talking to non managers in the information gathering phase is critical, as it enables you to have a more complete picture of the organizational state, as well as make sure people feel their voice is heard.
It's not very surprising that the next fail point was the solution presentation.
On the face of it, it was done as it should - they have set time with each team to present the new way we plan to work, giving each team time to ask questions, to understand how it should impact their work and focus on the points most relevant to them. However, the result was adding injury to insult. The meeting was based on a template presentation that looked like it was taken from scrum-101, dwelling on explaining the basic scrum terms and process and ignoring the elephant in the room: The problem all teams are feeling very painfully is the communication disconnect between various teams and groups. Any decent solution would at least acknowledge this problem, even if it was only to say "after completing this first step, here's our current thoughts of what we are hoping to do, and that's why it is not the first step. Another problem in the meeting was that it all felt like a shallow sprinkle of scrum on the structural and procedural problems we have,trying no to rock the boat (I'm guessing) and hoping for a miracle. Under the very wide umbrella of "this is the first step, let's roll with it and improve on what we get" we are keeping the silo-structured teams, putting the team leads into both scrum-master and product owner roles and did not even hint about how will the backlog be populated or prioritized, not to mention how do we plan to help teams start working together on the smallest value unit that can arrive to production - which we call "Epic", just to confuse people who have some previous scrum experience. Add to that a consultant that is not well versed in the relevant literature to the domain (when I mentioned that having the same person act as scrum master and product owner is usually considered as problematic and asked for the reason behind this choice, I got a response of "I'm not familiar with such articles", which meant I had to spend a whole 30 seconds of google to find 3 such examples) and you might understand that different teams came out of this meeting with either with a feeling of "ok, so nothing is going to change" or just disappointed and feeling that the whole charade is not addressing any of the important issues.
Whatever credit the consultants might have had before this meeting was now thoroughly obliterated.
Despite that, I'm optimistic about the process we are undergoing. Even if the consultants won't be able to recover from this poor start, and even if they will make every other possible mistake, Just by bringing them in the organization has created a space to talk about the process, to introspect and see the pain points that teams are experiencing, and ultimately, we have some very bright people with diverse experience working together and those two facts alone will lead the organization to a better place.
So, to sum the points you might want to remember in your next consultancy gig:
1. Collect information from all levels of the org. Meeting with 12 teams to a 2 hours round table each will take you roughly a week. You probably need less than that.
2. Transparency isn't enough - be vocal about your work. People, not only those that write you the check, should have the feeling that you are working and have an idea what about.
3.Understand the problems people feel, and address them even if you believe the problem is something else. In the latter case, share your understanding and test it.
4. Tailor your out-of-the-box content to your audience.
No comments:
Post a Comment