Talk abut the ins and outs of software engineering, the practices and principles involved with “doing things properly” and folks will look at you as if you’re their parents. “It’s SO unfair!”.
– Bob
It’s not that we don’t know how to design, build and deliver software solutions reliably, predictably and on time. It’s just that those involved don’t want the bother of doing things properly. It’s much easier and more comfortable to just futz around. There’s always sufficient budget to not have to worry about the economics of software production. And lives are cheap.
I meet Messrs Dunning and Kruger in organisations and individuals almost every day.
In case you missed it:
Better just to say “What do you need?“.
Is suicide a sane response to an insane world?
“The most important, and indeed the truly unique, contribution of management in the 20th century was the fifty-fold increase in the productivity of the MANUAL WORKER in manufacturing. The most important contribution management needs to make in the 21st century is similarly to increase the productivity of KNOWLEDGE WORK and the KNOWLEDGE WORKER.”
~ Peter F. Drucker
And in case you missed the original post:
It’s been pretty clear to me for some time (years) now that people don’t see the connection between assumptions and beliefs, and the frustrations they encounter ever day. And between assumptions and beliefs, and organisational productivity and success.
We have many words for much the same thing:
No matter what we call it, what we believe colours how we see the world, and constrains our actions. More so that anything else, in fact.
Similarly, it’s clear to me that the notion of shared assumptions and beliefs also passes people by. Despite its crucial role in all aspects of organisational, group and community behaviour and achievement. Again, we have many words for much the same thing:
Does this blindness bother me? Not so much. Like any good therapist, what my clients believe is their own business (sic). And like any good therapist, it’s not my place to dwell on the mechanism of their pain. Just to help them through they pain and out the other side.
Does this blindness bother my clients? Only insofar as they find themselves continually frustrated in what they’re trying to achieve (whatever that may be).
Does this blindness bother you? It’s all very well fobbing off the responsibility onto others, but how blind are you? Does progress lie in your hands (or mind)? What frustrations do you have that are a product of your assumptions and beliefs?
– Bob
In case you missed it:
“People too smart to get involved in management are doomed to work in organisations run by people who aren’t.”
~ Plato (adapted)
Daily stand-ups rapidly become tedious to the point of irrelevance. They rarely address core issues, participants generally preferring to gloss over issues so they can get back to “the real work”, e.g. coding, as soon as possible each morning.
Here’s how the Scrum Institute describes the Daily Scrum (Standup):
The Daily Scrum Meeting is a maximum of 15 minutes. These meetings take place every working day at the same time in the same place.
It’s best to conduct Daily Scrum Meetings with direct access to the Sprint Backlog and Sprint Burndown Chart. So the Scrum Team can direct the Daily Scrum Meeting based on the facts and progress which are visible to everyone in the team.
Daily Scrum Meeting aims to support the self-organization of the Scrum Team and identify impediments systematically.
All members of the Scrum Team, the Scrum Master and the Scrum Product Owner need to join Daily Scrums. Other stakeholders can also join these meetings, but only as a view-only audience.
Daily Scrum Meetings are structured in the following way. Every member of the Scrum Team answers three questions.
Question #1: What activities have I performed since the last Daily Scrum Meeting?
Question #2: What activities am I planning to perform until the next Daily Scrum Meeting? What is my action plan?
Question #3: Did I encounter or am I expecting any impediment which may slow down or block the progress of my work?
Q: What are the biggest impediments to a team’s progress?
A: The collective assumptions and beliefs of the organisation as a whole (and, marginally, of the team itself).
How often are these impediments discussed or even surfaced at the Daily Scrum/standup? Almost never. Or never.
How much do they impact the progress of the team? Lots. Really, lots.
So, for Question #3 (above), who’s going to raise the organisation’s – and team’s – collective assumptions and beliefs impeding or blocking the team’s progress? And who’s going to address these impediments/blockers on behalf of the team?
– Bob
Marshall, R. W. (2018). Hearts over Diamonds: Serving Business and Society Through Organisational Psychotherapy. Falling Blossoms (LeanPub)
Marshall, R. W. (2021). Memeology: Surfacing and Reflecting On The Organisation’s Collective Assumptions And Beliefs. Falling Blossoms (LeanPub)
Marshall, R. W. (2021). Quintessence: An Acme for Highly Effective Software Development Organisations. Falling Blossoms (LeanPub)
Even “good Agile” isn’t much good.
How many assumptions do you make in a day? Hundreds, probably. Maybe even thousands. And how often do those assumptions limit your choices, constrain your relationships, and detract from finding joy?
How would you like to make fewer assumptions, or at least, suffer less from the assumptions you do make?
Here’s a tip: Just bloody ask.
Assume that you’ve annoyed someone? Just ask them. Simply showing interest in their state of mind and status of your mutual relationship goes a long way to addressing the issue.
Assume that someone doesn’t want what you’re offering? Just ask them.
Assume that the collaboration you need to get something done isn’t going to happen? Just ask.
Assume that everyone wants to go to Abilene, and it’s only when tyou get there you find no one did? Just ask first.
For all kinds of assumptions, until you ask, you won’t know. And when you finally ask, you’ll likely be pleasantly surprised.
– Bob
How would you go about explaining the factors that contribute to a highly effective software development team, group, organisation?
In Quintessence (currently 24% complete), I’ve done it for you! But do you agree with it?
I invite you to take a look (extensive free sample now available).
– Bob
SAFe: The One Ring of our day.
“…One Ring to Rule them all and in the darkness bind them…”
Are you bored with mundane retrospectives? I know I am. And so are the teams I work with.
By way of example, let’s take a quick look at the Scrum version of retrospectives.
Scrum describes Sprint Retrospectives thusly:
The purpose of the Sprint Retrospective is to plan ways to increase quality and effectiveness.
The Scrum Team inspects how the last Sprint went with regards to individuals, interactions, processes, tools, and their Definition of Done. Inspected elements often vary with the domain of work. Assumptions that led them astray are identified and their origins explored. The Scrum Team discusses what went well during the Sprint, what problems it encountered, and how those problems were (or were not) solved.
The Scrum Team identifies the most helpful changes to improve its effectiveness. The most impactful improvements are addressed as soon as possible. They may even be added to the Sprint Backlog for the next Sprint.
…
During the Sprint Retrospective, the team discusses:
Even thought the above description mentions assumptions, the bullet list makes no such provision. And I’ve never seen an IRL retrospective that raised the question of assumptions.
So here’s a new kind of retrospective you might like to experiment with – the OP Retrospective.
The concept – and existence – of the Collective Mindset (a.k.a. Organisational Psyche) is foundational to Organisational Psychotherapy. It is the thing with which every OP therapist interacts.
Organisation Psychotherapy asserts that culture is no more, and no less, than a read-only manifestation of an organisation’s collective mindset – of its collective assumptions and beliefs. Read-only because culture cannot be manipulated directed, but only via changes to those underlying collective assumptions and beliefs.
Are development teams affected by the organisation’s culture? By their own team culture? By the organisation’s collective assumptions and beliefs? By their own team-local assumptions and beliefs? Are they in a position to shift either?
I’’d say “Yes”.
Given the influence of collective assumptions and beliefs on communication, productivity, teamwork, joy in work, and a host of other individual, team, and organisational concerns, shifting assumptions can lead the team to a more effective place.
But by what means? There’s no specific ceremony in e.g. Scrum to surface and reflect on collective assumptions and beliefs (culture). Maybe our retrospectives can, from time to time, serve this purpose?
If we wanted to use a retrospective (or a part of one) to explore cultural issues, how might we go about that?
I’d suggest my self-help Organisational Psychotherapy book “Memeology” might be one place to start. It’s stuffed full of questions that a team or group can ask themselves to explore cultural assumptions.
Here’s one example meme (meme #15, “Who Matters” – excerpted from the free sample version of the book:
Senior managers, stakeholders, team members, the Big Team, customers, users – call them what you will, they’re the people that we’re doing the work for. They’re the people to whom we deliver the fruits of our efforts. They’re the people whose reactions – and emotional responses – decide the success or failure of our endeavours. They’re the people whose needs matter to us.
By way of example, here’s a partial list of the groups and individuals that are candidates for inclusion on a list of who matters:
Who matters?
How do we presently go about deciding who matters (and who doesn’t)?
How well (or poorly) does our approach to deciding who matters serve us?
How often do we fail to focus on key groups?
Can we safely exclude some people and / or groups from consideration?
What have we learned or come to realise, maybe for the first time, in our conversation here today on “who matters”?
How far apart or together are we now on the subject of who matters? Has airing the subject eased our concerns?
Is it time for action on who matters? And if so, how might we go about setting some action(s) in train?
Kleiner, A. (2003). Who Really Matters. Currency.
– Bob
In case you missed it:
“Those who are able to see beyond the shadows and lies of their culture will never be understood let alone believed by the masses.”
~ Plato
Adapting Plato’s wisdom to the Antimatter Principle frame:
Those who are able to see beyond the shadows and lies of their community’s collective assumptions and beliefs will never be understood let alone believed by their fellows.
– Bob
In case you missed it:
In case you missed it:
Producing Software Is Not The Purpose Of Software Development
Think Different