Traditional Managers Disguised as Agile Practitioners are Killing Your Product
New Roles. Same Mentality.
Once upon a time, a software development model called ‘Waterfall’ — father of all evils, as some say… — advocated a granular breakdown of project activities to culminate in one gargantuan, tremendous, larger-than-life software rollout.
My first contact with Waterfall-ish methods happened more than a decade ago, as a Software Developer in a large Public Sector project.
We released full-blown software packages every 4–5 months, with dozens of new features and hundreds (literally!) of bug fixes.
Common those days, before you click “Ok” to rollout, you had to say 3 Hail Marys, kiss the crucifix, and jump on your right foot, hoping any available God to bless that rollout.
God forbid(!) if something went wrong or a rollback was needed… We would spend the next weeks smashing our heads against the wall.
Following this model, project Sponsors and Stakeholders tried to squeeze as much as possible into the scope without checking if it 1) solves a real need or 2) is valuable for the end-user (Note: I don’t mix end-users with stakeholders due to the fact the 1st ones are very simplistic people: they want basic stuff to get the job done).
On top, complexity was (is!) the arch-enemy of clarity: when the system’s complexity increases, we have a higher chance of getting superfluous, ambiguous and incomplete requirements.
So you can imagine the amount of back-and-forth we (Dev Team) had to get something valuable from their mouths.
Now fast-forward to 2021: Agile is widely spread, iterative planning is the way to go and software teams are multidisciplinary & value-driven. Software is now released in small chunks with fast feedback from end-users.
But guess who is still frozen in time? Sponsors and stakeholders (S&S). They still have hidden agendas being driven by useless metrics, frame larger-than-life requirement sets under the argument that ‘everything is top priority’ and hope to get things done with just a few bucks.
Their sense of achievement is delivering projects within scope, budget and time, completely detached from market and costumers reality. They serve navigation at plain sight for the sake of the output, not the outcome. With more and more companies forgetting project mentality and entering product-driven strategies, S&S is a real threat to the aforementioned initiatives.
When the corporate world understood the need to enable the traditional business models with digital literacy, we witnessed several companies throwing money into consultants & coaches, hoping to receive the so-called ‘Agile Transformation’.
They saw it only as a new company-wide project, with a start and end date. They ignore the fact that a transformation does not have an end-date; it’s a never-ending effort a company shall subscribe to stay relevant in their business domain.
Our good old S&S saw Agile transformation as a threat. “If they can do more with fewer people, where do I fit in?” they asked. This question reflects what they mostly do throughout their careers: to control.
The majority, middle managers, kept their titles, bossing others around and creating conditions to stay ‘in power’ for eternity. Introducing servant leadership and frameworks like Scrum would completely kill their spotlight.
But fortunately, the majority of the company Boards recycled S&S and brought well-equipped people to fulfill… Stop! I’m joking. This is not how the story went. What really happened was: Company boards looked into their workforce and just reshuffled the roles:
- The old Project Manager is now a ScrumMaster;
- The old Line Manager is now a Product Owner;
- The old HR specialist is now an Agile Coach;
- and so on…
The cherry on top, these people got 16h Scrum Training, some signed for a Scrum Alliance certification and… voilá!! New Scrum team coming out of the oven.
Now enter the day-to-day activities of these teams:
- The ScrumMaster is more focused on deadlines than on enabling the team;
- The Product Owner is bossing the team around, with unrealistic deadlines and fussy requirements;
- The Dev Team is constantly under pressure and demotivated with the current working model;
It feels like a great place to work, right…?
This leads us to another buzzword of our Agile lexicon: Minimum Viable Product (MVP).
Enter the MVP
In 2001, Frank Robinson introduced a Minimum Viable Product (MVP) concept. The original concept advocates:
“We define MVP as that unique product that maximizes return on risk for both the vendor and the customer.” (…)
“The MVP solves a variety of problems, especially on a product’s first release. Products without required features fail at sunrise but products with too many features cut return and increase risk for both vendor and customer.”
Let us focus on the wording here:
“A product that is good enough to solve the core problems (…)”
“(…) products with too many features cut return and increase the risk for both vendor and customer.”
Preserving customer-centricity as a driver, an MVP shall have the minimum amount of features to tackle core needs on a given domain. Meaning, you only add to the MVP scope what is highly valuable to produce but with low effort.
This implies a solid Product Strategy to manage prioritization, dependencies and low-level detail on business needs.
When enough is enough?
Now, let’s bring back our S&S recently empowered with new Scrum roles. What do you think will happen when these people, still working under traditional methods and with personal hidden agendas, are in charge of building a digital product?
What happens when they fail to address complexity with an iterative approach and deliver everything in one take? What happens during MVP scope definition when they see an opening to squeeze another big feature still, even though it’s not critical for product success?
This is one of the big problems I see in today’s corporate world: traditional management disguised as Agile practitioners, serving their own needs rather than company goals.
The solution? Change your company culture. Encourage innovation. Build safety nets for failure & feedback. Reward outcomes and not outputs. And most of all: explain the difference between a Leader and a Manager.