Watergile
Hello fellow Scrum community,
I consistently encounter what I am assuming is one of our most common obstacles, an organization's resistance to change from waterfall to scrum. I've searched this forum but I have not seen it discussed in a little while, what are some of your techniques for helping an organization that says they wish to practice scrum but maintains Waterfall methods. I have heard it comically called "WaterGile"
As an example, my current position brought me in at the beginning, no backlog exists just yet. When I arrived they had been in "sprint 0" for about a month. There are several issues where waterfall is still being practiced:
1) They seem to want to "scope" the project requirements and seek to stay in in Sprint 0 for 60 days to do this
2) They want to dictate to the scrum team the technical solutions. There are many meetings excluding the scrum team and then the team is "Voluntold" to build a particular solution.
3) There are engineering managers directly involved with "guiding" the work that don't seem to want to let the team self organize because they don't feel they have the domain knowledge to do it.
I've tried asking some questions around what the perceived benefits of these old habits are, and the responses seem to trend towards "our data is very complicated and must be completely set up and scoped out before widgets that pull this data can be built".
When do you decide an organization wants to simply hold the traditional scrum events but they don't truly want to practice scrum?
Thanks!
"I've tried asking some questions around what the perceived benefits of these old habits are, and the responses seem to trend towards "our data is very complicated and must be completely set up and scoped out before widgets that pull this data can be built".
--> Interesting. Why do they want to use agile - for only building out the widgets? I am assuming the testing will also follow a phased approach?
Yes, testing seems to be taking a phased approach meaning it is not happening iteratively and is saved for the end of the sprint. I've seen this somewhat repeatedly through many organizations just beginning with scrum. There is some psychological fear around releasing small pieces to testing early and often so they may discover defects early on. We are still following the phases of: Requirements, Development, Test, and business approval. It could be argued they are not using scrum for any portion of this at all, although we hold the scrum events for development.
> ...what are some of your techniques for helping
> an organization that says they wish to practice scrum
> but maintains Waterfall methods
The first thing to ascertain is *who* wants the organization to practice Scrum, and what benefits they hope will be accrued by doing so. Enterprise transformation is typically constrained by the degree of sponsorship for change, as it means challenging received wisdom and organizational norms.
The first thing to ascertain is *who* wants the organization to practice Scrum, and what benefits they hope will be accrued by doing so
The genesis of the scrum practice here came from part of the vision for the year to move away from teams assembling around Projects towards teams assembling around Products.The same team stays with the product, the perceived benefit being they become domain experts, their time to ramp up and complete work is faster.
Short answer: The company leadership wants annual planning around growing their product lines to meet overall product goals (software as a service). As a response to this change, the engineering management is championing scrum to actually get the work done. Which is a fantastic idea! This is a great application of scrum.
Those that we work with to derive where our products are heading (product managers, product owners) aren't accustomed to this and haven't received a lot of training (this is why I'm here). Shifting this group away from thinking about getting "x project" done by October and into a small tangible sprint goal that will deliver value to the business is my uphill climb at the moment. This is often delivered with technical constraints "We want you to use X technology". At the other end of it, when developers are met with these large project-like features they want to spend a goodly amount of time scoping requirements.
We all know that if we approach this iteratively, and start getting fingers on keyboards, we don't need requirements because we have the application to reflect on together. Then we can inspect, adapt, and proceed.
Where sponsorship comes from engineering and the higher-ups, but not from business, you can try building an agile delivery capability which begs the question "why isn't this being used".
This is hard and uncertain without business pull, but there are things that will clearly need to be taken care of. The first is a technical ability to deliver production quality increments at least monthly. Are environments and technical quality assurance geared up for this, or is IT itself still waterfall? If business asked for delivery every 2 or 3 weeks, could IT actually do so? Then there are the roles...is there a cross functional Development Team in place? Is the Definition of Done clear? How transparent is work in progress?
If basic agile technical hygienes are in place, waste can then be exposed and challenged, including that associated with big-batch planning. It's then up to the sponsors to do something about it.
If business asked for delivery every 2 or 3 weeks, could IT actually do so? Then there are the roles...is there a cross functional Development Team in place?
Salient point here ^, except I think in the inverse in our case. IT is more than capable of delivering every 2 or 3 weeks. It's the business that needs to narrow the focus and provide sprint goals that are achievable in this time. I'm going to chew on this. I think that's my lynchpin in this at the moment, coaching product owner and sponsors to look more narrowly for small increments that they can get excited about. No more waiting 6 months before you get the goods.
If basic agile technical hygienes are in place, waste can then be exposed and challenged, including that associated with big-batch planning. It's then up to the sponsors to do something about it.
Truth.
Thanks for your time.
Regarding Agile/Scrum transformation, I always reflect on the wisdom of Craig Larman and his 4 Laws of Organizational Behavior to provide me with perspective and guidance:
http://www.craiglarman.com/wiki/index.php?title=Larman%27s_Laws_of_Orga…
Is this another example of an organization using Agile and Scrum as buzzwords? Even if not, the transformation takes time and if it does not come from the top it has to be truly support by the top. Timothy's reference is spot on and I've referenced it in corporations as well. It's important to lay some groundwork in Agile mentality, Scrum practices, product vision and back log, etc. Since there is no Sprint Zero, then use the time frame to ramp up those basics.
In the end if the organization doesn't buy-in and support true Agile and Scrum, then the headaches will continue. ScrumWaterFail