“Getting the job done is no excuse for not following the rules. Corollary: Following the rules will not get the job done,” said Somebody I Don’t Know.
When I was developing software under the draconian rules of CMMI there was the very clear message from the handlers (as we called them) to follow the rules or there will be consequences. So we did. Mostly. The problem was that amongst those of us in the trenches there wasn’t much of a feeling of actually getting work done. There was a lot of rework due to features being designed without our input. The design team would send us a design, we’d make noise that the design had problems but we’d have to build it anyway, we’d build the unworkable thing, demonstrate a flawed product to the design team, they’d redesign (without our input), re-document, and send us a new design.
And so we lurched forward. We followed the rules and weren’t getting the job done from the customer’s perspective. I’m sure the CMMI gods were happy, though.
This was before “Agile” was a thing. There were plenty of rapid application development ideas in the industry and in loose fashion we ended up implementing what we thought we could get away with. And that worked.
Our impromptu “water cooler” conversations in the mornings where we mostly complained but frequently suggested solutions for each other’s techno-pain would be easily recognized by any scrum master as the daily stand-up or daily scrum. The way we cut up (literally) copies of the official documentation and re-arranged the work to better match how we thought the work needed to be done looked a lot like a sprint backlog.
We were getting the job done, but not following the rules. As far as I know, none of us ever suffered adverse consequences. It’s hard to argue with success no matter the path taken to get there.
Imposing elaborate sets of rules to a fundamentally creative process will pretty much guarantee a slow boat to success. In the late 80’s and early 90’s that seemed to work well enough. But those days are long gone. It’s why the framework approach to many of the Agile methodologies are more successful in software and similarly creativity dependent projects. Frameworks leave room to adjust, adapt, experiment, and act.
Rules are important. Frameworks aren’t devoid of rules. Far from it. Tossing out bits and pieces of a framework shouldn’t be done just to get the job done. The rules that are part of a framework should be considered a minimal set essential to success. None of them should be discarded without careful deliberation. Unlike the rules to something like CMMI that are meant to control as many aspects of the project as possible and squeeze out any trace of uncertainty and risk, the rules in an Agile framework are meant to serve as important guides. Operating outside a framework for extended periods is likely to put a project at significant risk.
Well-established and proven frameworks, such as scrum, have extracted the essential rules from previous methodologies and experiences and organized them in useful ways. They don’t reject all the previous rules in a quest to re-invent the wheel. They build on what has been learned to improve the wheel. This is reflected in the words of the Stoic philosopher Seneca:
Won’t you be walking in your predecessors’ footsteps? I surely will use the older path, but if I find a shorter and smoother way, I’ll blaze a trail there. The ones who pioneered these paths aren’t our masters, but our guides. Truth stands open to everyone, it hasn’t been monopolized.Seneca, Moral Letters, 33.11
The Stoics recognize that our predecessors weren’t entirely wrong. But they are very likely incomplete. It is incumbent on us to improve upon and extend their work.
This illuminates the importance and value of a good scrum master. Like a good cowboy or cowgirl, part of their job is to ride the fences, looking for breaches to the framework. If found, either repair the fence with coaching or decide if the fence line needs to move to accommodate a need dictated by circumstances and conditions.
Image credit: Wikipedia