Many thanks to Gurpreet Singh for allowing us to re-post this article about what he calls "Wet Scrum". He will be in Australia in mid-September as a session leader at LAST Conference.
By Gurpreet Singh
Many companies tag themselves "Agile." Agile is the latest Methodology to execute software development projects. Agile has a variety: like Scrum, eXtreme Programming (XP), Rational Unified Process (RUP), etc. Scrum is the most commonly followed these days. Generally, organizations use a blended version to suit their needs, which are confined within their environmental constraints (EEF/OPA, or enterprise environmental factors/organizational process assets).
So, why are companies moving to Agile?
Let's recap the Agile Manifesto to answer this question:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
Agile empowers the client with the flexibility to change, as the entire process is iterative and the client is kept in the loop with each sprint's progress. Also, the team plans and commits for work for each sprint and works together to complete the commitment.
This way, it is a win-win scenario for each side:
- The client is updated in real time about the status of the project/product, and the client has the freedom to change the requirements.
- The team is like a small military Alpha unit (five to nine members) working in short progressions (sprints).
The hard truth
Hmm . . . this was the theory. Life, though, is not about black and white; there are grey areas everywhere.
It is easier to "do Agile" than to "be Agile." Agile demands a certain discipline to get the right results.
- Do you timebox your meetings?
- Are you a silent listener during the meetings?
- Is the product owner or ScrumMaster the only person who talks?
- Is the PO/SM "pushing" the work to you?
- Does your PO commit during the sprint planning without seeking team input?
- Are you forced to give XYZ points to ABC story?
- Are you not "open" in the retrospectives for fear that what you say will backfire?
- Are you forced to take on new stories during the sprint that will negatively affect the already committed deliverables?
- Do you never discuss blockers in the daily Scrum meeting, despite the fact they exist?
- Do you expect/wish that the PO/SM would micromanage so you only have to "work"?
- Do you believe the carrot-and-stick method of management is essential?
These scenarios are just few highlights; the possible list is endless. They show that you are "doing Agile" (for the sake of doing it), but you are not "being Agile," as you don't know the real importance of Agile practices and deliverables.
You may be an Agile puppet run by someone else following Waterfall. This kind of Scrum is notoriously known as "Water-Scrum-Fall."
I would like to coin a new term for this method: "Wet Scrum."
Scrum gets "wet" by following the practices of Waterfall. People use Scrum selectively, depending upon context and ease. However, it is very difficult (nearly impossible) to achieve the spirit of Agile by doing this.
How Wet Scrum Works!
Clients need the following:
- More human touch
- Manageable work organized in short sprints rather than trying to manage the entire project/product as one entity
- Real-time updates about work completed
- The power to change the requirements
- High-quality results
These deliverables are produced by Scrum, in theory. However, no way of working can ensure the success of a project or product unless the team is disciplined and focused on making it a success. (We will discuss this point further at a later stage.)
Clients are fascinated about using Scrum to address the needs listed above. This creates pressure on the senior management of XYZ Company to shift to Scrum. And this creates a cascading pressure on middle management, junior management, and finally on our teams to be Agile. The team doesn't necessarily have an awareness of the Agile values, but they need to be Agile, as this is a clear mandate of senior management and the voice of the client. They start holding daily Scrum, sprint planning, and retrospective meetings without a clear vision of the end goals or their purpose. The burn-downs literally burn down these Wet Scrum teams. Sizing seems alien to them. They aren't sure about the roles of the product owner and the ScrumMaster. They believe they are self-organized, but they need some manager to manage their work.
In a nutshell, they are "Agile" as being demanded by the client (or management); however, they are miles away from being Agile. This is a sad state and is cruel for the team. Gradually, the team will feel that the meetings are senseless. For example, if they are regularly taking on more stories during the sprints, the sprint planning meetings lose their purpose and become a waste of time. Similarly, if the daily stand-ups last for 30 minutes, this is a clear waste of the time for the entire team (30 minutes times X number of team members daily).
In the long run, the team will start burning out. They will lose focus and motivation, and the product will fall from creative mode to survival mode.
And . . . everybody will blame Agile (read: Scrum) for this failure. However, if the people involved do not want to make the product/project a successful one, it will be a sure failure no matter which method you use.
Competition is high, so companies try everything to make new customers and to sustain the old ones as long as possible. This includes shifting to newer formats such as Scrum, Kanban, etc. However, this kills the creativity, innovation, vision, human spirit, and motivation of the people who actually create the product or execute the project.
Agile was born to empower people and their communication, and this is lost in Wet Scrum.
Wake up now! - See more at: https://www.scrumalliance.org/community/articles/2013/december/wet-scrum