I have many people in my Scrum Master class who quickly see and understand why Scrum works – empowering developers, QA, and the business to focus and commit on delivering a few of the most important work items in a short, time-boxed cycle. The team-based approach with visibility, openness, respect of everyone-plays, and regular pauses to learn have an amazing effect every time I see it.
The problem lies, at times, with everyone outside the team – those overseeing all the work requests, often the Project Management Office (PMO) or those stakeholders asking for the work, such as executives and other senior management.
They still want what they want, and often still have fiduciary duty – the PMO to stakeholders, and the stakeholders to internal and external customers, partners and the marketplace.
Jim was frustrated because, again, his Product Owner said that the team had to handle an emergency request. Bill in Sales said that he had to have the request handled or there would be no way he’d win the deal over Kemper Devices for the multi-million deal with this healthcare client. When the Product Owner balked, Bill said he had an executive override for this one. So, once again, Jim’s Scrum team would have to throw out their plan from the Sprint Planning meeting.
Jim’s team got the feature out, with some issues that they said they’d have to address in the future, hopefully. When I asked later about the multi-million deal, he said that he wasn’t sure what happened with it. Same for the Product Owner.
Personally, I understand the situation and don’t fault people for doing what works for then, especially if it just means a meeting or two in order to skip waiting for weeks or months. As a salesperson, if my bonus is based on closing deals, of course I’ll do everything I can to win those deals. And justified or not, aligned with the company vision and strategy or not, on our consensus roadmap or not.
It’s the same for knowledge silos in development. I’ve had engineers who were the only ones who knew the inner workings of key areas of a mission-critical system. It was the “hope they don’t get hit by a bus” scenario. Yet, Eddie Expert wasn’t at fault for any knowledge-hoarding or technical turf war issues. His manager, and HR, rewarded him for his specialized knowledge and being an singular expert instead of a team-player generalist.
In the same way we addressed the knowledge silos, we can address the priority problems.
First, we agree on clear goals for the team. We win or lose if the team’s goals are met. So, when it comes to what Eddie Expert is going to work on, it’s not _his_ pet tech, it’s whatever is needed to reach the team goals. When it comes up that someone needs help or access in his pet tech area, he’s invented to share, help and do whatever needed to help reach the team goals (which are clear, short-term, tracked and celebrated when reached). If Eddie tries to hold back knowledge, there will be team peer pressure on him to NOT work in his own self-interest, but the team’s.
Same for project and program priorities from stakeholders and executives. We need clear priorities for the team that are decided in very visible, collaborative ways. If there are 7 people asking for something from my team, I need to bring them in the same room and have them agree on priorities. And if a Chief Tiebreaker executive is needed, then have them there, as well. If we allow requests and priorities to be voiced in isolation (and worse, launched as yet another separate project with shared resources), then we’re limiting the dialog, visibility, clarity and buy-in that will later serve us all well when someone comes up with their own self-serving request.
What is covered in the Certified Scrum Master class only touches on this, but the Certified Scrum Product Owner training gives more tools that can do this. Additional Program Portfolio Management and Product Management information and different funding approach is coved in the Scaled Agile Framework (SAFe) workshop, especially useful for larger environments (5+ teams).
