The first generation of developers to experience Scrum Agile has moved on. The crop of developers encountering Agile for the first time are either in lagging companies with outdated SDLC methods, or are brand new coders who have only worked on personal projects, and had no need for a planning mechanism.
When Scrum was introduced, and the Agile Manifesto soon after, distribution and deployment of software provided a toleration of long development cycles. The Gantt chart, cutting edge in 1915, and the PERT planning of 1950’s still worked. As agility adoption proved the efficacy of Operations Management science in world of uncertainty and complexity, with refactorable work product, developers were delighted because they had something to compare it to.
Those development teams that are still not Agile are often called “waterfall”, simple because we’ve differentiated the pre-Agile and Agile eras by the old Gantt chart versus diagrams with looping arrows. But we have to be careful to recognize that a team is not necessarily Waterfall just because they are not Agile.
If you inspect many of the non-Agile teams now, you’re not likely to find Business Analysts with thoroughly documented requirements, Microsoft Project plans filled with fully detailed Gantt charts, and PMP certified Project Managers busily finding ways to crash the critical path with available resources from a slack branch. What you’re more likely to find is no methodology at all. The wild, wild west. Cowboy coders doing things their own way with, at best, some cultural norms.
This brings us to two different views that are common when Scrum Agile is introduced to existing teams. The “Relief” and the “Daunting”. For teams that are truly practicing a well defined SDLC methodology, they will see Agile as a relief. A reduction in documentation, contract negotiation, long range estimates pulled from thing air. For those cowboy coders who have evolved in their wide open prairie of no rules, Agile feels restrictive and constricting.
“So many meetings!”
“I’m spending all my time updating Jira instead of writing code”
“Why do I have to answer so many questions about this feature request?”
“I can’t pay two people to write the same piece of software!”
“I can’t spare my people for constantly testing your software every day!”
Herein lies the warning sign. If a team reacts to Agile with relief, you can predict they are likely to translate that halo effect into an appreciation of the framework itself. This positive feedback loop means they’re more likely to willingly learn and understand the concepts that make Scrum work. The more they “buy in”, the more success they will have applying the additional Scrum patterns.
If a team’s initial response to Scrum is that it’s restrictive, prescriptive, and high-overhead, consider this the tip of the iceberg floating above the water.
You are in for a rough ride. If a team is not relieved by the reduction in documentation and overheard, but sees Scrum as an increase in non-value added work, you can bet they haven’t been doing any of these non-functional practices. Technical Debt will be buried below the waterline. Documentation will be non-existent. Pairing was likely never practiced, and as a consequence, the skills profile of team members will vary wildly. You’ll find “experts” in different areas, with a great amount of pride about their fiefdom. Expertly controlled fiefdoms mean integration problems lurk underneath. Do you expect anyone has been writing automated unit tests? Not likely. Therefore the team assumes every feature is a monolithic algorithm that takes a month to produce (while they hide in a cave, the code hidden under a bushel).
In a case like this, the best approach is to put all the political capital on the line immediately, and find out if people have the willpower and the desire to practice Agile principles, and a Scrum framework.
“But we’re so far behind, we can’t take the time to do training now!”
Without a thorough understanding of what Scrum Agile is, what makes it work, a hearty desire for the outcomes promised, and an amount of faith to try it, the incremental “learn as we go” approach with an iceberg team is doomed to failure. There’s a specific certification exam questions about adapting the Scrum terminology to make the organization comfortable… and the inevitable trade-off is that the clean-break from past practices won’t be obvious and memorable. The weight of inertia and “how we’ve always done it” will grind the change to a halt.
Heed the warning signs if a team shows alarm at the “increase” in administration from an introduction to Scrum. Take the opportunity to have a meaningful gut-check about what the organization truly wants, and make sure you have buy in, and commitment to get past short term pains. Without the buy-in, every little pain will lead the team to wish for a return to the past. When the massive iceberg of Technical Debt begins to break into chunks and float into view, Scrum will be blamed as the cause (not the tool that made it visible).
Scrum is radical. It delivers radical results. A team deserves to know what they are in for, and a voice to commit or bow out.
Top comments (0)