The watermelon syndrome

CASE STUDY

Imagine a project where release dates are always shifted, that has severe quality issues, and where developers are almost always required to work overtime. In this project, the Program Manager feels it is completely okay to raise his voice in status meetings; where these status meetings happen often and resemble to police interrogations. This Program Manager is backed up by a Product Owner, who has corporate experience but no technical background nor any willingness to learn. Another key figure in the game is the Scrum Master, who is only SM in name, usually doing the PO’s job, pleasing the Program Manager, or playing bad cop to developers. This is a project, which is otherwise crucial to stakeholders and holds a very important place in the company portfolio.

I arrived in this project as second Scrum Master. I was hired to change things and get them back on track. What I did not know that they have never been on track before. That, although upper management thought the project is following agile methodology, at least on paper, it was not at all agile. For example, there were no taskboards, no regular standups, no regular retrospectives, no estimation of tasks, no proper backlog, etc. When I arrived, there was no one who could have been able to estimate the amount of work still needed to be done. This was particularly interesting after the first status meeting, when I saw the PO presenting all sorts of status reports including specifics like, Epic One – 78% done, Epic Two – 47% done, etc. When I asked him how he came up with these numbers, considering that velocity was not tracked, tasks were not estimated, the backlog was incomplete, etc., he just said, he did not know, he was just presenting what “management wanted to see”.

WHY DOES IT CALLED WATERMELON? WHAT ARE THE SYMPTOMS?

It is a situation where everyone who is close to development (developers, testers, SM, PO, etc.) are aware of problems, we can say they are inside of a watermelon where everything is red. However, from outside it all looks green (on reports) to upper management.

This works until a certain point… a point, where the whole project collapses. It is the time when everyone is stressed, managers are angry, release dates are shifted, developers are working overtime, developers are micromanaged, etc.; in other words, the project is losing money. The watermelon syndrome often happens with software projects transitioning from traditional/waterfall method to agile.

The main affecting factors are managers who want the “benefits” of both words, that is, agile and traditional project management. Misunderstanding the adaptability of agile, thinking that it means everything can be changed at any time and it will not cost the project additional money or time. This also manifests as managers communicating that scope, time, and budget are all fixed and cannot be changed. They want developers to work more and reports showing that everything is on track and will be finished on time. When pressure sets in, people tend to avoid further conflict and faking reports seems to be a good temporary solution. Unfortunately, it starts a downward spiral that most projects cannot correct on their own.

WHY DOES IT HAPPEN?

Lack of knowledge, lack of experience, lack of professional guidance (agile coach). Old habits remaining in practice or creeping back after a semi-successful/semi-finished agile transition.

HOW TO AVOID THE “WATERMELON SYNDROME” BEHAVIOR AS A PO/MANAGER?

• accept that unforeseen problems and impediments do occur
• accept that the above will affect plans, thus all plans must be changed
• always listen to your team and consider their opinion regarding time estimation
• it is better to know that something cannot be finished on time rather than releasing a product with lots of bugs
• priority is essential, forget the “everything is equally important” behavior
• do not request meaningless reports, instead, focus on agile KPIs
• trust that the people around you are able do their job -> no micromanagement, no witch-hunts, and please, no public humiliation
• have an open mind and willingness to learn
• accept that while traditional/oldschool project management seems to be more effective in a short period of time, it can induce false reports and hiding problems
• out of the factors: time, budget, scope, and quality at least one will suffer if you insist that everything is equally important

HOW TO AVOID THIS BEHAVIOR AS A SCRUM MASTER?

• provide transparency -> useful KPIs instead of meaningless reports
• never compromise regarding product quality
• never sugarcoat or hide problems; or let others do so
• never let the team feel unnecessary pressure from upper management
• educate upper management

By Nikoletta Tatar