Best Practices Are Just Practices

[aaronjensen]

https://github.com/aaronjensen/software-development/blob/master/best-practices.md

[laribee]

Another way to look at practices is Cynefin. In clearer domains (simple, categorizable problems/situations), practices can be considered "best" or more universal. In more complex domains, you'll need to develop novel practices or be vigilant for their emergence through experimentation.

[sbellware]

@laribee And also... deviation-from-norm can also suggest that the foundation that the norm is built upon isn't properly generalized and stable, and that special purpose procedures have infected general purpose procedures.

We work in rather complex domains: corporate legal process and finance processes and regulations. We've created industry award-winning software products within a year of kick-off, and we've made legacy providers react to us, rather than the other way around. It's because we have the "right" norms and practices that the team stays tight and lean, and doesn't have the deviations that require novelties. Where there are exceptions, they're rare, and their rarity is a result of the stability of foundations.

I've found that in organizations that are larger than they should ideally have been, deviation-from-norm is the norm. It usually happens when the culture is aligned on schedule rather than learning, and usually the schedule is arbitrary and not the result of real market synchronization targets (ie: management system incentives contradict stability).

I think that it's reasonable to ask of the Cynefin method whether it's the result of unmanaged and historically-neglected complexity, rather than essential complexity. Most of the cases that I've personally seen addressed with Cynefin are a result of neglected mistakes in the implementation, rather than inherent complexity in the domain. I see it as a result of a product and systems staff approach that minimizes education and learning, and confines it into staccato batches like annual or semi-annual Big Bang workshops - ie: Kaizen Events (plural), rather than Kaizen - rather than infecting every moment with guidance and teaching, and making sure that leadership is endowed with exceptional ability.

Cynefin appears, to me at least, to be one of those kinds of elaborations that I look at with some distrust. It seems to be a vector for status consulting lock-in, rather than long-term, deep problem solving. It seems to be favored in situations where the product organization has so much historical, unresolved implementation complexity that it can't afford to attack the problem by establishing a non-negotiable learning culture. It seems to favor the short-term quick returns that favor consultants than the kinds of results that are far beyond quarterly results.

I lean more toward the Art Smalley (Toyota) problem-solving tradition. It's not as elaborate of a framework, and doesn't have much of a wow-factor from a consulting engagement perspective, but it can get the job done without requiring as much energy investment into the methodology office itself - as long as the right pre-conditions are met.

In our work, we expect the customer to change their culture, and sometimes even their organizational structure - and we implement that change - so that we can proceed with a fraction of the people compared to what's typical. We presently do this inside a $1B multi-national market leader, and we ultimately get away with it because the outcomes can't be denied. Arguably, these are special conditions because they're both long-term as well as short-term, but they're ultimately conditions that suit even the stability of our consulting business.

I think Cynefin is a good option for organizations that have been relatively chaotic for long enough that transformation of the foundations are out-of-reach. IE: A way to cope with accidental implementation complexity than a re-orientation of absolutely everything to radically minimize it.

In the end, the end goal can be achieved without the lab-coat anthropological study of "complexity" that seems to come hand-in-hand with looking at things through the Cynefin lens - especially if the underlying method is incompatible with the excess complexity of integrating poorly-designed legacy systems. But I understand that the excess complexity scenarios are the vast majority of scenarios in the wild. The other minority of scenarios are the ones where health is understood from the start, and sustained in perpetuity, and where palliatives don't factor as prominently.

That's usually where we do our work these days. Arguably a special case scenario, but one that has been constructed from the ground-up to work in a way where elaborations like Cynefin, et al, are largely a footnote. Without a more elaborate method, there's little-to-no resources spent on managing the method. It may sound overly-simplistic, but in practice, it's just simple rather than simplistic - but not overly-so. And it's a completely different consulting business model predicated on (very) long-term engagement with a team that handles many products simultaneously and has none of the status quo software problems of the typical team.

What we do, and arguably what Aaron is alluding to, are mindsets for teams that are decidedly Post-Technical Debt, or that want to be. But first we have to convince the world that the Earth isn't a flat plain of unavoidable shoals of technical debt that the ship will inevitably run aground on. And since we can't really expect to do that, we'll document at the highest level what we do as a beacon for anyone looking to go on the journey.

Our work is now unapologetically dismissive of Agile and its surroundings, and for better or for worse, Cynefin gets ensnared in that disregard, along with anything that conflates "Agile" and "Lean", like Lean Agile and Agile Lean. We've found that it only distracts from the principles and fundamentals that predicate all the particular named methodologies. When we have to refer to it by name, the name is, "Continuity". But we aren't likely to publish it or talk about it by name until we muster out of the productive end of the industry to become those "gentleman programmers" who can afford to focus entirely on theoretics once they've stopped producing products and moved on the meta-products. We're too busy winning awards and keeping our competition on the back foot :)

In short, if the conditions are right (and it's never accident), it's easier than Cynefin.

[laribee]

Classic.

[doughtnerd]

I definitely agree with the points made in this article. It matters more to do what "works" than to follow any particular practice just because it's "best". However, there's a point "Uncle Bob" has made in various interviews and in his books that I agree with. These "best practices" can be extremely helpful for less experienced engineers insomuch as it serves as a template or guideline for them to follow until they achieve a higher level of mastery. A similar philosophy is that of shuhari or "the stages of mastery".

Reflecting on the beginning of my career, I sought "best practices" as best as I could because I had no foundations to question the practices. As I've advanced through my career I've done what I can to understand "why" certain practices are "best" and it what situations. Though I have many years to go before I reach "ri", it has been helpful to at least experiment with "best" practices over the years and gain more experience in what "works".

[aaronjensen]

I'm not necessarily trying to speak to the most junior developers. I'm trying to speak to the slightly less junior developers that never graduated that stage. That should have realized that these things solve particular problems and that those problems can be addressed in other ways. Instead, they've bought into the orthodoxy and have decided to not think for themselves. Those are who I hope some day sees some of this stuff and starts to wonder why they still do sprints, or why they pay someone to have the title "Scrum Master".