Clarity In The Steamy Channel…

Getting a team to transit from their old working ways and embrace a new “unorthodox” way of working is never easy and requires patience. The team I have been working with has proved to be the exact opposite of what I expected. While I was initially optimistic that things would sail with less opposition from the team, it has actually turned out to be a daunting task. Moreover, the leadership is curious to see if there is anything coming out of “the many meetings” and has continuously urged me to train the team but reduce the frequency of the meetings. I find it contradictory that the team should be “trained” but at the same time they should be allowed to “work” in a domain where there is almost zero collaboration. Withut causing unnecessary extra pressure, I decided to spend time to understand the dynamics of the team. I did not want to come in with past experience from other teams, ut decided to first and formost understand the challenges that the team was facing. What problems did they have and why was I involved. The latter part was particularly important for m to hear it from the horsens mouth. Firstly, at the team level, and secondly from the leadership level. This was crucial in finding out where the disconnect came from and how this could be bridged. Over the last one month, I came to learn several important issues that the team was unknowingly struggling with. I narrowed down on what I considered was the most significant ones, in terms of productivity and harmonization of team efforts.

Disoriented Management or Absurd Company Culture?

I knew from the beginning that to have success on this mission, I had to win the management’s support. While talking to the project owner it occurred to me that he was not actually keen on having the status qúo change, but yet wanted to see improvement in the team. On the other hand, the project sponsor was laid back and trusted the project owner with the decisions he made. This was unsettling, to know that power was vested in one center and I had to spend more time working from his perspectives, even when I knew that they were counter productive. It was indeed an absurd company culture that was causing quire resentment especially at the team level but no one dared raise issues about it. The team did not feel psychologically safe to address these issues. But I knew that it was a safe approach if the management was to be convinced that there was need for change.

Secondly, decisions were frequently being made and changed without involving the team. It made the management appear undecided and unsure of the direction they wanted to take. Agile advocates for adaptation to uncertainity but it also highlights the importance of inclusivity and dolving decision making. It was quite odd to see that team members would need permission to make tactical decisions which affected their productivity level. Developing a tool to be used by the team, would require managements permission to spend time on that, and even then it would need to be scrutinized closely, planned at a detailed level and then strict time estimations were then provided. Phew!!! That was hard for the team but looked like they had resigned to fate.

I have now had two meetings with the business sponsor, business owner and the scrum master to raise this concern. Using this approach, I intend to introduce inclusivity in decision making. I do acknowledge that there will always be strategic decisions and tactical decisions, and my desire is that these two levels should co-exist harmoniously where the actors in each domain feel included. The meetings have been positive so far, and I have been facilitating it with the knowledge that there is need to improve psychological safety and empower the scrum master to not only feel like a participant but an active representer of the team. We have joint meetings on Fridays just before midday, and it is one of the meetings I always look forward to.

Lack of visualization

The second problem that I noticed was that the projects and tasks that the team worked on was not visualized on a common platform where the team and the management could have a common focus on. Borrowing from Lean’s principle on mapping value streams to actual actions needed to satisfy the stakeholders, it was apparent that lack of visualization was a problem. I soon started to understand why the management changed thei minds frequently and the team was informed in the last minute. It also began to make sense, on the couple of times that the team members would unknowingly be working on duplicate tasks or get derailed on side tasks that did not add any value to the customers. The scrum master was mostly working using spread sheets to keep track of what they were working on, but this was not visualized to the team. After a weekly meeting, the scrum master would update the spreadsheet to mirror the progress the team had made. What was puzzling was that the scrum master then had to meet the project owner and discuss the progress based on the reportings made in the spreadsheeet. My curiosity got me thinking, how much misinformation could be taking place by having the “middle-man” in the process. To increase the complexity of the process, the project owner would then use a copy of the spreadsheet to communicate to the project sponsor. It became apparent that this process introduced other underslying challenges; Missing expectations management between the team and the leadership occassioned by the absence of a common alignment, poor understanding of what the different team members were working on and lack of commitment due to absence of a common goal in between the sprints. Goals were defined for each quarter but then that was it. There was no further breakdown.

I raised these observations with the scrum master and why it was important to have a web platform that could visualize what the team was working on. Her major reservation at this point was that management would now be willing to spend on a platform that they felt was nott improving any value. Secondly, she also felt that it might take a long time to know how the platform was working. After much talk the last three weeks, we finally decided last week to start with JIRA, which I recommended due to its simplicity and also because they could get a free version for limited users. We have created users in the platform and the team is now able to see what each other is working on. there is a sense of curiosity and eagerness in the team. For the first time, they are feeling a sense of unity is starting to creep in, creating impact in their working approach and I am happy to see that we are slowly turning the wheel towards the right direction. Albeit for now. Will it be a success? I bet so. the enthusiasm in the team can be smelled miles away.

Have you had similar challenges? How did you approach them with your team? I would like to hear from you, please share your comments