Too Busy To Improve
Improvements seldom emerge without deliberate effort. If people are too busy to make those investments, the best we can do is move the goal posts. We can re-label the old behaviors as the new, desired behaviors and blissfully ignore the outcomes remaining unchanged.
Please read Hakan Forss’s insightful blog with colorful visuals to learn more.
Print them.
Decorate your office as a persistent reminder.
Department Of Defense's Agile BS Guide
The US Government does not have a reputation for being agile (quick to respond to changing conditions effectively).
Many companies aren’t either, but many in the private sector have changed the names of their processes to be Agile.
This model, formed by our Department Of Defense, is a simple litmus test to call out Agile BS.
It highlights those who may be saying one thing and doing another.
The Three Ways
Based on Theory of Constraints and Lean Manugactoring, the 3 Ways has been central to the DevOps movement.
The focus ensures that improvements are supported to be sustainable.
For example, it doesn’t help us to know what errors are happening in production if we can’t reliably deliver a solution.
We don’t want to tweak a step in the process without knowing if it makes the overall process better or worse.
The current state of DevOps has a growing body of concepts and tools.
The 3 Ways helps us focus on the right areas at the right time.
Jez Humble, Gene Kim - Continuous Delivery, DevOps Handbook, the Phoenix Project
SWOT Analysis
A mainstay in MBA study, the SWOT Analysis categorizes infleuntial aspects to a company as Stregnths, Weaknesses, Opportunities or Threats. It allows one to explore that which is helpful or harmful. You can look inteneral and extrenal. Exploring SWOT allows one to objectively balance their view or an organization with honesty. They can use their Stregnths to make the most of Opportunities and bolster Weaknesses to defend Threats.
Scatter Gather model (aka Divide And Conquer)
Rumsfeld Model
(aka Johari's Window)
Matrix of Known and Unknown information. 1) Known-Knowns - The things we know we know. Things we will speak of with confidence and conviction. 2) Known-Unknowns - That which we know we don’t know. Questions we need to find answers for. 3) Unknown-Unknowns - The things we don’t know we don’t know. Often the surprise which creates misery. Requires intentional, open-ended questions to surface. Others may assume you know and you will need to be explicit to uncover invalid assumptions. 4) Unknown-knowns - Things we didn’t know we know (i.e. how good of a salsa dancer we are, or we may have some info others need)
This model is useful to confirm what is known and what needs to be known. What is fact, what is opinion? What is assumed? How can you surface the informaiton you need?
The Responsibility Process
Based off of Dr. Avery’s field studies, this process (much like the psychological stages of grief) models how people respond when things go wrong.
This can be used to understand how others are responding to an event, but even better to recognize how you are.
Dunning-Krueger Effect
A little bit of knowledge may be reflected with high levels of confidence amongst novices. As more is known, confidence may drop until enough knowledge, context and experience validate’s an expert’s confidence.
While not to be taken as a universal law, it may be worth questioning a person’s confidence with their actual ability.
This quick check can help us the potential for perception and reality to drift.
Like the “The Responsibility Process”, this is applicable to ourselves as well.
Dreyfus Model of Skill Acquisition
AKA: Genesis of the expertise
We go throught a journey when learning.
Early on, the concepts and relationships seem reasonable. We can logically understand.
Your understanding of a given topic is reflected in your abillity to do the thing, talk about the thing and then evenaually teach the thing so someone else can explain or do it.
The approach and words we use reflects both where we are on our jouurney and where we perceive others to be. Attempting to teach someone is a great way to identify what you may need to learn more to be effective.
Stuart and Hubert Dreyfus - 1980
DISC Personality Model
(aka Meyers Briggs Model)
Understanding our values and how we operate is as important as recognizing the same in others. Often we project our own values onto others and are met with conflict.
This is one of many personality profiles this can help highlight people’s values and motivations.
The discussions a personality profile drives can be more valuable than the assessment itself.
William Moulton Marston - 1928 (Emotions of Normal People - Book)
Cost Benefit Analysis
How can we quantifiably justify an expendituer for an improved return?
Instrumented in the Flood Control Act of 1939, this model established policy requiring that “the benefits to whomever they accrue [be] in excess of the estimated costs.”.
Combined with other models, this is an important aspect to consider when making a decision regarding the distribution of funds.
Build vs Buy models stem from CBA.
Opportunity Cost also should be introduced into the decision making process as Time may impact current and future benefits.
The relationship betwen Cost and Value is critical. It is often difficult to validate as we leverage the data which is often most easy to collect. (aka availability bias).
Jules Dupuit, Alfred Marshall 1939
Cargo Cult
The scenario where people go through the motions without knowing the purpose of them or the nuances which would impact the outcomes.
i.e. “We do the thing because it’s the thing and we’ve always done that thing. It’s how you Agile!”
Origin for the phrase comes from WWII when remote islands were converted into military bases. After the war the natives created airplanes made out of bamboo to appease the gods to return the shipments of food.
Build vs Buy
It’s difficult to know what to say Yes to or No to.
This quick check helps pressure-test an opportunity.
Could we build this? Quite possibly yes. Should we? Perhaps no.
Westrum Cultural Model
The culture of an organization reflects how effective the organization can deliver and how happy the people in the organization are. Top performing organizations have Generative cultures and embrace psychological safety. Lower performing organizations spend more energy avoiding accountability and blame.
It is helpful to understand the organization’s relationship with safety and it can be used to predict how organizations or parts of them will behave when signs of trouble arise.
This model was heavily referenced in the research (using rigorous statistical methods) presented in the book “Accelerate - The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations”.
Test Driven Development (TDD) - Red/Green/Refactor
A staple of modern software development practices. The software’s design is formed when tests are first written as the purpose of the code is declared.
The test determines your context and expected result. The test fails upon first run and shows up as the color Red in the automated test runner.
After the code is written to implement the desired functionality, the test runner turns Green.
As the functionality has been proven, the developer can refactor the code to adhere to an improved pattern, maintaining proven functionality.
Reference:
SATIR Model of change
Summary: Psychologist Virginia Satir’s work with families in the 1950’s maps the 5 stages of the change process. When the status quo isn’t acceptable, new behaviors are introduced. Performance is likely to drop during the transition period. Likewise, anxiety may rise. After new behaviors take root, their benefits become apparent and the improvements represent the new status quo. It is useful to recognize where a system is in their process to better understand how people are reacting.
Resistance to change is a basic human response. It must be acknowledged, respected and nurtured.
Rube Goldberg
Not necessary a model, but a helpful visual reference. Artist Rube Goldberg created unnecessarily complex processes to complete a simple task. Systems are often influenced by Conway’s Law and Industrial-Revolution-era mindsets (Fredrick Taylor’s Scientific management). Prioritizing local-optimization can lead to many pieces which don’t work well as a whole.
“Things are the way they are because they got that way” - Gerry Weinberg This is another example of how many small decisions might be cohesive.
Conways Law
An organization’s structure influences communication paths which influences an application’s architecture. If a company organizes around functional specialities, solutions will require a copious consumption of communication, collaboration, and coordination cost.
Understanding the model we exist in provides us an opportunity for a Reverse Conway manuever. This is where we work backwards with the end goal in mind.
Instead of relying on different individuals with specialities, cross-functional/inter-disclipinary teams are leveraged.
External expertise is utilized when needed, not as a defaultm team (i.e. DB, UI/UX, Javascript teams).
This about this when work is easy to start, but difficult to complete due to team depencies. Does one unit of value need to be prioritized repeatedly for different teams? Do teams need to decide which teams that they support will receiver faster or slower solutions?
Reference: Melvin E. Conway - 1968 http://www.melconway.com/research/committees.html
“Team Topologies” by Matthew Skelton and Manuel Pais https://teamtopologies.com/
