How to Keep Team Morale High During Difficult Times

Problem

When I joined a company, I started working with a Scrum Team that previously had a few different product managers, and for some time, had none. Therefore, the team morale was a little bit low in the sense that they lacked consistent product leadership. On top of that, their performance was not remarkable according to standard Scrum metrics. The steady team ratio was low because they would continuously change direction on their proposal and pull in new work.

Our Scrum Master would measure us against these metrics and report our performance accordingly. The team morale was lower than it could have been as a result of that. The ratio was vital because it allowed other product managers to commit to delivering work at a particular time. That was important for other teams, who were depending on that work.

Actions taken

It took some time, but as I boarded onto the team, I tried to facilitate the engineering definition of work much sooner than the team was accustomed to. So, whenever we were aware of a new task, I wanted to bring it to the team as quickly as possible. It helped us define the work and get started much earlier than we otherwise would have. I increased our runway between when we started the work and delivering it.

Moving forward, I modified how I engage with our stakeholders, which included both our internal and external customers. This was to better align with how the team was accustomed to working rather than force the team to work in a way they were not accustomed to. We communicated this to our Scrum Master, and we were able to drive a cultural change, where the importance of the specific metric was considered less important.

Finally, we transitioned from Scrum to Kanban. The process seemed to go smoothly, and I looked at some of the factors that have helped potential further improvements. Our team eNPS score rose from the mid-60s to nearly 100. The team was much happier in this dimension, and our business was also pleased as they were getting the work they needed more efficiently.

Lessons learned

• The process for engineering teams should not be forcing them to work in a way they prefer not to work in or in an inefficient manner. Instead of working for the process, we can make the process work for the team.
• Scrum and Kanban are templates that we can follow, but we should have the ability to flex them. This would ensure that the teams are self-organizing because that is the number one principle in Scrum.
• If you notice a gap between what your team is delivering and the business’s needs, consider the possibility of making changes at the team level. It may also be possible that you may not be communicating correctly to reflect how the team is the best working.
• The eNPS should be celebrated. For me, it was a big motivator. Even though I am not the engineering manager, I did influence what the team worked on as the product manager.