Frameworks vs Rules

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 a 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 among 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 a 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.

And…

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

Drive for Teams

I recently re-read Daniel Pink’s book, “Drive: The Surprising Truth About What Motivates Us.” I read it when it was first published and I was still managing technical teams. Super brief summary: The central idea of the book is that people are mostly driven by intrinsic motivation based on three aspects:

  • Autonomy — The desire to be self directed.
  • Mastery — The urge to improve skills.
  • Purpose — The desire to engage with work that has meaning and purpose.

I find this holds true for individuals. However, when applied to teams optimizing for these three aspects can be problematic. If an individual on a team seeks to maximize autonomy, they are likely to come into conflict with the objectives of the team. For example, a software team that is tasked with developing a component that is expected to interact with several other components developed by other teams. If a single developer, in the interests of maximizing their individual autonomy, has decided to develop the component according to standards, design principles, and tools that are different from those of teammates and other teams (essentially, a local optimization,) then the result is likely to be sub-optimal overall.

Some individual autonomy must necessarily be sacrificed in the interests of effective collaboration. It’s possible, even desirable, that individual pursuits of mastery and purpose can be maintained. However, it may be necessary for an individual to focus on mundane tasks and the objectives of the team for periods of time. Finding ways to maintain a healthy balance between the intrinsic motivators and the purpose of the team is no small task and, when found, requires constant attention to maintain.

Perhaps it is possible to attach the team’s or organization’s purpose to the interests of the individual. Or sort for hiring people who have a personal purpose that is in-line with the organization’s purpose.

Image by M. Maggs from Pixabay