Sympathy for the Manager
Trying to help too much can lay your team to waste
The manager is one of the roles that is not inherently addressed in the Scrum Guide. Whether she is a team manager, a department manager, or a Director; there is no guidance on what this person should do during the Scrum adoption. Other than being the champion! This person is critical to the team and the organization.
Managers are usually under immense pressure to “show results” of many items at any given time. Managers are at the forefront and sometimes even the definers of the culture in their space. They are usually are the ones that try to help the organization by bringing the likes of us Scrum Masters in, so that things can get better.
Unfortunately, the fact is that the Manager has direct authority over the team. The “sign the check” power that comes with that makes being prescriptive almost inevitable. Coupled with pressure and competing priorities that change on an almost constant basis the team can see this role as one of many “bad guys” that don’t get it. They could see that the manager will keep pushing them in different directions.
I understand this pressure, I have seen it in every project and team I have worked with across the US. Of course, every instance is different. Every organization responds to these challenges in a unique way. The people within the Manager roles usually really care about their people. But the people are so beat up, in some cases they cannot see their managers as anything other than an obstacle. In a few cases, the managers emerged as protectors, but team directions always changed.
In almost every case, I was told — “just wait Harry, they will ask us to stop and do something else”. And in almost every case, the team was right! The managers simply could not stop the momentum or need for information from a higher level. Nor the push by a much more important stakeholder for “their” project. Or in some cases, even the manager’s own pet projects…
What is a Scrum Master to do in these cases? Even when you understand what is happening, most of the time the “Scrum is for them, not us” mentality is in play. This limits the ability to impact the deeper culture. Even when you can challenge the mindset, the waves of uncertainty from above take a while to calm down. And the pressure never goes away.
A Manager must serve their team, but they are also expected to report above AND take care of those requests. The Scrum Master and the Manager must learn to work together to help one another out. If they hope to be able to help the team be successful in what they are trying to achieve.
The First Coaching Adventure
I will never forget my first real coaching opportunity. A company brought me in because they were suffering from a “Scrum Collapse”. See, when they started as a small and nimble startup, the two founders embraced agility. So much so, that Scrum allowed them to succeed and go to market earlier and better than most competitors! Well, success brings its own problems, but they continued being strong. They helped one another out and keeping vision and focus.
Then the first merger happened — followed quickly by the second and then a third. After all the changes, the company was successful; but the team now had no access to the users. The stakeholders had multiplied to such a point, it was nearly impossible to keep track. Because of this, the company decided to look for outside help from a Scrum Master to see what could be done.
When I got there, the person that interviewed and hired me was one of the two founders. He liked what I had to say and believed I could help the team. The first problem, which he explained to me in detail, is that he had fallen into the trap of being the only available leader for the team. We have all heard about wearing many hats. My friend had gotten into a situation where he was something like 5 roles — some which were at odds with one another. He knew this and was keenly aware of it — but could not come off this trap.
He was trying his best to be the Scrum Master, the Product Owner, and the team Manager. Also, he was Project Manager within the external organization, one of the Product’s Sponsors and an executive to his branch. Balancing a timeline with goals, defining product objectives and working with the backlog was hard enough. Add endless meetings on just about everything to that and it had him beat! He needed help, and he needed it so his team would again be able to be proud of their work as they were in the beginning.
Many managers find themselves in my buddy’s predicament. They have too many things to do, and not enough people, authority, time, and space to get them all done. I have not worked with one manager who only wore one hat in my time of being a Scrum Master. Some have proved to be very helpful and appreciative, and some have just been grateful for the momentary success. In this case, after a careful deliberation and assessment of what the team was doing, we came up with a plan.
What I did was simple — I was new to Scrum, but I knew how to do a couple of things well. I figured a “back to basics” approach would likely be successful. I would emphasize the definition of people to take on the Scrum roles in the new environment. In this way, I started the many patterns that define my career and my approach since then. I asked for volunteers for those leadership roles and had a refresher course on all things Scrum. I wanted to LISTEN rather than teach. This was important because remember, these guys had used Scrum the right way in the not too distant past! Of course, one hat was immediately taken off my buddy — I was now the SM for the two teams.
The next role that needed definition was the Product Owner (PO). We had many important stakeholders to choose from! This company had gone from one product to three main product lines. As such, with each merger came more oversight. And no one stakeholder wanted to hold the reins, but they all expected to be served.
This led to a training idea that had to happen. Because the stakeholders were not originally part of the team, the “essentials for Product Owners” class was born. The stakeholder teams were invited, and we had a great time. The raw information on how the team worked was greatly appreciated. Many had not heard of “Agile Practices” yet, much less Scrum! There were about 16 people in attendance, of which about 8 could fulfill the PO role.
With their new knowledge, some exercises (games) and a review of the current backlogs, the request for POs was made. This was a delicate issue for all the different parts of the larger organization. Over a few days the conclusion was to have volunteers for the “right sized” POs to guide each of the projects.
If you are keeping count, that is two less hats PO and SM were being fulfilled by active and engaged people. People who cared about the team and the product and wanted to work together to help the team be successful! This left my friend with the hat he really wanted to keep — Manager for the team. The team responded well, we started seeing repeatable success with Scrum again. The mood lightened significantly and now that we had the right roles in place, everyone felt more at ease!
Unfortunately, this story has a sad ending. Because of all the roles my friend had to hold for such a long time, my buddy had a team with deeply hurt feelings. I am not sure how well he fared with the team afterwards. I know he and the team appreciated my work. But I knew that the team could not appreciate him — because to them, he had become the “punishment” guy. This did not happen overnight, and it would likely take just as much time to undo those hurts. But at least, the team was a TEAM again, and was back on track to do great things.
How can we help one another?
This was not the only time I worked with a great Manager. A few come to mind, though they are rare to find! Most are too busy to help, too busy to notice. And much more often I get the “this is great, let’s work weekends to do this faster” or “good, this worked. Let’s split the team up so we can make more teams like this”. Both are common, both are attempts to make things better — and both usually fall flat on their faces. I have had teams where managers have changed many times, or where the manager was so protective, the team had no incentive to deliver!
I wish I were smart enough to write a piece on how to be a better manager! As is, all I can do is share this story with the thought that a Manager can help your team be successful. Or they can get in the way at every step while you try to make changes. As a Scrum Master my advice is to talk to your manager and see what challenges she is seeing. What is important to him. What can you team up to do together to not only help the team, but help one another? Defining your role and your expectations early, and reviewing this conversation later on is essential to success.
And, even if I am not smart enough, I have a friend that is! Jurgen Appelo took the time to write the excellent book Management 3.0. In his book, you can see what it is to be a great agile Manager and he has a platform to help you with this! This is not the only source, of course — but you as a manager must try to understand not the mechanics of Scrum, but the goals of agility. If you as a manager can meet your Scrum Master halfway, the team has much more than a fighting chance to get it right.
Do you want to write for Serious Scrum or seriously discuss Scrum?
