Paul Tevis 
“I don’t want to distract the team. They don’t need to worry about this.” That’s what my boss – the head of engineering at a rapidly growing startup – told me when I asked him how he would share information from top management about our revised expansion plans. His job, he said, was to protect the engineers from things like this and to let them focus on building the product.
“What’s the secret to backlog refinement?”
Eighteen pairs of eyes turned to look at me, waiting for my answer to this product manager’s question. I’d spent the last two days with the group working through the challenges they faced using Scrum in their company. We discovered that most of their delivery problems stemmed from the teams not understanding what was needed. They’d identified with the story I’d told about the team that hated Sprint Planning and hit the reset button on their process. They knew they weren’t doing refinement and could see the effect. They wanted to know how to make it work for them.
The team was angry. Every two weeks, they would find themselves five hours into their sprint planning meeting with no end in sight. Every two weeks, it was the same: Their product manager showed up with a pile of requests the team hadn’t seen before – estimated by someone elsewhere in the organization – and wanted to know precisely how many the team could finish in the next iteration. Everyone hated sprint planning. It was stressful, wasteful, and unproductive. Something had to change.
The team was struggling. They were working on an industrial motion control product, porting a legacy code base to a new hardware platform. Parts of the code were decades old, and many of the original developers no longer worked at the company. They kept getting stuck trying to figure out how the code worked and what they needed to do to make it work in the new system. Neither the engineers nor the product manager had visibility into what was taking so long or how to help.
Last October, I helped the Agile Alliance Board of Directors with their quarterly meeting. They asked me to write up one of the ways we worked with some difficulties that came up.
You’re a mid-level manager in a rapidly growing company. Your boss tells you that a new initiative the company has been considering for the last year has finally gotten the go-ahead from the executive team. This initiative is similar to others your company has taken on in the previous few years, but it is different in a few key ways. There’s no playbook for work like this; success will require trying new things and learning from what happens. Your job is to pull together a team that will perform at a high level in challenging circumstances. What do you do?
Managers everywhere struggle to lead teams. These teams don’t produce the desired results, leaving everyone frustrated. A common cause of this problem is managers falling into the trap of thinking that leadership is about them. When this happens, a change in perspective can help them regain effectiveness.
Many managers struggle to give effective feedback. They spend hours carefully crafting their message only to have it fail to land. What they neglect to notice is that feedback is at least as much about the relationship as it is about the message. One of the keys to a strong working relationship – one that enables difficult conversations – is a sense of shared purpose.
We’re excited to share that the “we” at Helping Improve is no longer just Jake & Paul. Allison Pollard has joined us as the third member of the Helping Improve team.
A high-performing team meets or exceeds its clients’ expectations, becomes more effective over time, and helps all members learn and grow. A high-performing team is not merely highly productive; it is anti-fragile. Teams reach high performance through a complex process of development. How can you tell if it is moving along that path or needs a corrective nudge? By monitoring three key team processes.