Hidden Frameworks Ensure Companies Will Never Do Real Scrum
The unspoken working modes are the ones defining (limiting) how people really work.
The unspoken working modes are the ones defining (limiting) how people really work.
Many companies I know claim to be Agile and work with Scrum. Yet, they measure performance based on output and arbitrary deadlines. A faulty perception of Agile and Scrum holds many teams back from reaching their true potential. Since I started my career as a Product Owner, I have attended hundreds of interviews, and I’m often shocked when I ask a simple question, “How do the teams work?” Generally, I get something like this:
“We work with Scrum, and we play by the book. Every second week we deliver something. We are rigorous with our Scrum Events; every team member has to attend them. We also have an experienced Scrum Master who is responsible for three Scrum teams, and our Product Owner works closely with our stakeholders to understand what they want.”
Whenever I hear anything similar to that, I recognize it as a trap. Such companies perceive Scrum as a delivery framework, and yet they claim to be Agile. Beyond being clueless about Scrum, many companies have hidden frameworks, which define how they work in reality.
Let me share the hidden frameworks I’ve encountered and what I learned about them.
Career Driven Framework
Some years ago, a company invited me for an interview for a Head of Product position. The process was supposed to have five rounds, and I was on the third one. During the interview, I asked the hiring manager how do people get promoted, and the conversation went like the following:
Hiring Manager: “Product Owners get promoted once they manage to match the quarterly plan three times in a row. Our roadmaps are strict, and we promote those who take it seriously.”
David: “What if the Scrum Team realizes that a requested feature won’t deliver the expected value and decide to abort the implementation?”
Hiring Manager: “They cannot make this decision on their own. Once the roadmap is set, the team has to follow it. The managing board invests a lot of time deciding where to invest during the next year. They focus on the strategy while the teams focus on the execution.”
After this answer, I removed my application. I could imagine Product Owners identifying issues on the way but being unwilling to address them as it would impact their careers. Following a plan would eventually lead to promotions even though it would prevent teams from embracing learning.
If you want to know how people collaborate, you’ve got to understand how they get promoted. Does the company measure individual or team results? Is matching a deadline more important than doing the right thing?
The Framework applied for career development often gets in the way of doing Scrum properly.
I faced another similar situation in an interview for a Product Owner position. It was the second round out of three, and I got skeptical when the hiring manager said, “Our teams are well balanced. We always have at least two senior devs, one junior, and one intermediate.” I decided to understand in depth what he meant by that, and our conversation went like the following:
David: “I am interested to know how you evaluate the seniority level of devs?”
Hiring Manager: “It’s simple. Our senior devs have to deliver double than our junior ones, and intermediate devs must deliver at least 50% more than a junior dev. After each Sprint, we measure the performance of each dev, and we evaluate whether they are matching our expectations or not.”
David: “For me, it seems like a competition instead of a team. I wonder if the junior devs manage to get the help needed considering the more senior members to have a higher delivery expectation.”
Hiring Manager: “That’s also simple. The team is self-managing; they are free to figure out how to address this situation. In general, it works well.”
I was astonished by this answer. I could not imagine working in such a team. Without a doubt, the team wouldn’t be able to do Scrum because the company fostered competition instead of collaboration.
The career framework frequently dictates how teams work, and it will often discourage them from doing real Scrum.
Calendar Driven Framework
Another dangerous framework is what I call the Calendar Driven Framework. I often got trapped in a situation where I barely had time to identify opportunities to deliver value sooner. This problem is more prominent for Product Owners, but it also happens with Developers. To help you understand what I mean, I will share one of my weekly calendars (excluding Scrum Events) at one of the places I worked for:
One on One: alignment with my business director, who was my direct Manager. I generally left the room with a series of items to do.
Product Management: alignment with the other Product Owners. Mainly, it was a status report meeting. Everyone reported what the Scrum Team was doing. The meeting was tedious and lengthy.
Operations Sync: understand the issues faced with the operational teams. I left this meeting with a series of complaints and problems to deal with.
Customer Service: alignment on the frequent complaints made by our clients. This meeting was helpful to understand what annoyed our actual end-users and helped me understand the impact of our activities.
Business Partner: understand what our potential clients wanted to sign a contract with us. The Business Partners mainly wanted estimates from me and commitment on delivery.
These are only some frequent meetings examples, but in summary, I let the external world drive my actions. I took a passenger seat and focused on managing activities instead of identifying opportunities to deliver real value.
By allowing the others to define how my day unfolded, I missed the mark of what a Product Owner is.
The same trap can happen with Developers. Using the same company as before, Developers had the following meetings apart from Scrum:
One-on-one with Tech Lead: every week, Developers sat with the Tech Lead to discuss career development and operational aspects. Often, the Tech Lead pushed Developers to do something behind the curtains, even though it was unrelated to the Sprint Goal.
Monthly with CTO: once a month, each Developer had a chance of exchanging with the CTO. This meeting was tricky, as the CTO often requested something from Developers that was not even in a roadmap, but Developers didn’t want to disagree with the CTO.
Dev Sync: every second week, forty developers sat together for three hours to share best practices and benefit from the other’s experience. The problem is that they could barely gain insights from each other as they worked on entirely different products.
Although we claimed to do Scrum, Product Owners focused on dealing with stakeholders’ wishes, while Developers had to deal with many requests nobody else knew. We thought we were doing Scrum, but in reality, we were driven by our calendars.
What is in the calendar ultimately defines what people do at work.
Doing Scrum Goes Beyond Saying We Do It
The challenge isn’t only doing Scrum right but identifying what blocks us from doing it. I’ve shared two anti-patterns I’ve faced, but many other hidden frameworks kill Scrum. Here are some more:
Short-term focus: the team focuses on delivering more every quarter. Output is all that matters, and dealing with tech debt is forbidden.
Opinion Driven Framework: the higher the paycheck, the more important to follow the opinion. Everything is based on opinion instead of evidence. Investing time validating an idea is unwelcome. What matters is implementing what the highly opinionated people want.
Sales Driven Framework: delivering what salesforce needs to get new contracts is more important than solving real end-users problems.
There’s a massive gap between saying we do Scrum and actually doing it. Companies may say they work with Scrum, but in reality, the hidden frameworks impede them from doing it.
An Agile transformation requires more than implementing a delivery framework. Before implementing Scrum or any other Agile framework, companies must understand what drives their work and address core issues.
People won’t focus on collaboration if they are measured by individual achievement.
Product Owners won’t focus on doing what is right if they get promoted by matching arbitrary deadlines.
Scrum Teams will have no chance of succeeding if all team members have their side agenda to follow.
Did you like this post? What about becoming a Medium member to benefit from unlimed reading? By doing that, you can support writers like me and thousands of others 😊
