Scrum is a motivating work environment that improves productivity, but…
Scrum needs active participation and involvement! As a manager, this participation is about taking the time to learn about what Scrum is really all about and changing how you operate.
Some managers have a hard time resisting the urge to assign tasks and direct the team; it takes effort, discipline and a willingness to let go and even allow others to call you on your command-and-control behavior. Instead of changing, some managers continue to direct and assign work to individuals, disrupting teams and causing the process to fail.
Other managers go through the exercise of empowering a team and stepping completely back. But they do this with their fingers crossed. They wave goodbye to the ship (team) from the dock and hope that they return with a hold full of treasure – with the plan of “holding them accountable” if they don’t and reverting back to their comfort zone of highly directed teams.
I'm sure other scenarios come mind.
What these scenarios miss is the part in the middle: the part about management changing into a collaborative, supportive management model. The team needs to get the work done, and it’s your job as a manager to help the team reach its goals.
This will involve a variety of activities, including things that as a manager you most likely already do today, such as initiating – and expediting when required – the purchase of hardware and software that teams require. Other support will prove to be more difficult, like driving organizational change. The development organization might be going agile, but the surrounding organization needs to understand the changes that impact them from an interaction and expectations standpoint. Managers can help provide this understanding.
One area we delved into involved performance management. Our first change in this area was to articulate that for those on agile teams, the team was of greater importance. We didn’t want conflicting messages in play with our people by emphasizing individual goals over the self-organizing team that they were a part of. Today, we’re still at work refining our performance management process to support agile teams.
Sometimes, managers themselves can pick up on issues that are hindering teams – in real time, not after the fact. One advantage of Scrum is that it reduces bureaucracy, providing time for management to increase its real-time involvement. For example, a couple of us managers sat in on a regular sprint review and after the actual review was concluded, we noticed that there was an undercurrent of trouble.
We had purchased and incorporated an expensive piece of technology that was a key to the success of the project that this team was working on. We picked up on one-off comments about performance problems and stability concerns after a sprint review, but the team collectively seemed to be ignoring the comments. There was an elephant in the room that no one was talking about.
We recognized this and began asking some questions, teasing out the problem. There were genuine concerns that appeared rooted in reality, but the team had no specifics. The Product Owner remarked that he had spoken to the vendor on behalf of the team on a couple of occasions and the fault was found to be in our code, not the vendor’s product. Now the cards were on the table. A trust issue existed between the Product Owner and the team, and there were some very real, unaddressed problems lurking either with our code or the vendor’s product.
As we talked with the team, we finally posed the following to them: “Do you want to take some time now and determine what the specifics are, or do you want to continue to walk down a path that is clearly frustrating to you? As stakeholders, we’re concerned that if we let this go another four to five months, we could end up ‘finishing’ the project, but being in a position of having software that is not production-ready.”
The team readily agreed with this and determined that they wanted to get at the heart of what was wrong, no matter what the outcome. We made immediate adjustments to the planned work, allocating one week to identify the problems. By the end of that week, the team had discovered more than one area where the vendor’s product was lacking, complete with automated tests that demonstrated that performance degraded under certain conditions. And the stability issues were isolated to a background process that ran periodically.
We discussed these issues to the vendor, who agreed to correct the issues. And the team was delighted because they not only understood precisely where the problems resided, they understood how they could work around them in the interim.
There will be other changes will come your way. Our experience is that the more time teams spend being truly collaborative, they develop a greater desire to move away from cubicles.
In fact, a couple of our teams have gravitated towards fully open spaces. Everyone has a desk large enough to pair at, and the teams have turned out the overhead fluorescent lights in favor of using desk lamps in combination with free-standing lamps that provide a fairly low level of indirect light. They’ve also grabbed a couple of couches from elsewhere in the office and even asked me for an artificial tree that I had in my office. We went with this and even arranged for a generous application of white-board paint on the walls.
The net effect is that these areas are distinctly removed from being a Dilbert-like, cubicle work environment. Each one has a feeling of being a relaxed, friendly, collaborative work space. And these two teams happen to be very hard-working, productive teams that as a manager I’m only too happy to support.
Scrum will also surface heretofore hidden problems within your organization that will need to be addressed. For example, teamwork becomes paramount, and if you have people that cannot and will not play well with others, Scrum won’t fix problems like this for you. Management needs to step in and correct the problem.
Management doesn’t disappear with self-organizing teams. When we first adopted Scrum there were those who chanted, “We don’t need managers!” But the reality is that agile teams won’t thrive without support. They do, however, need the right kind of support.