During the past 10 years, I've worked with a lot of companies to help them transition to an agile culture, especially those with software development teams. I've trained their teams, worked with them as they've gone through their first iterations and have supported them through the years by continually helping them change their culture by reminding them and pointing them back to the agile values and principles. And through it all, there is one common issue that continually comes up, and that is that most teams are overburdened by too many projects. So, let's take a look at how we fix that.
After 32 years in the technology industry, I've made some observations of common behaviors that exist within technology teams, especially with the developers, but nonetheless it carries over to all of the associated roles. For the most part, I've noticed the vast majority of people in the technology field are people pleasers, they have a tendency to take on more work than they can handle and they have a really hard time saying a very important word..."No".
By far, the most difficult Scrum role for organizations to maintain long-term engagement with, is the Product Owner. Based on my experience, they tend to work at a strategic level where they have budgetary control over projects, are juggling multiple initiatives and really don't have time for the day-to-day activities and communications required by the team to successfully implement what they've been asked to do. In the absence of the Product Owner, products (and teams) tend to wander with no clear direction or prioritization.
I always ask the teams, "How many of you have worked in an environment where you have multiple Priority 1 projects?". Inevitably, the vast majority of the room responds with chuckles, nodding of the heads and a sea of enthusiastically raised hands. Just as a Product Backlog is used to provide clarity and prioritization to the features of a project, this same prioritization must be applied at the macro (i.e. portfolio) level as well. This is where it becomes incumbent upon the Product Owners to also learn how to say "No".
The first thing you need to do to fix a problem, is to admit you have one. This requires courage, honesty, candor and a willingness to genuinely change the circumstances. I've encountered clients that have been carrying requirements forward for years (one requirement was literally a decade old and the people who requested it, had since retired from the company). This is a perfect example of why prioritization is so critical to the long-term health of software systems.
For those of you who've watched Old School with Will Ferrell, there is a scene where he and his wife are talking to a therapist and in order to get to the root of their issues, the therapist makes a reference to "the trust tree". Well, Ferrell's character takes the liberty of going into some very uncomfortable branches of the trust tree, that makes everyone, including the audience, blush. I use this scene reference in my class because it brings up an important point. For the long-term health of the company, the people and the software you're building, sometimes you have to build up the courage, prepare yourself to tell the truth and lead with a resounding "No". I guarantee that the first time you say it, it will be hard to get out, but it gets easier with practice.
Comments