Weeknotes 327

This week I did:

Continuous improvement

We started an experiment in taking a continuous improvement approach with a live product. I’m a believer in continuous improvement because the underpinning theory (always go to the source) makes a lot of sense to me. The continuous improvement approach we’re taking is based on Goldratt’s theory of constraints. It says that, whatever your goal, you have only one biggest barrier preventing you from achieving it. You have other barriers too, but only one of them is the biggest. Identifying and removing that barrier will have the greatest impact on achieving the goal. Then your second biggest barrier becomes the biggest. In my head, I see the barriers as a pareto distribution where quite quickly you reach a point of removing barriers only giving marginal returns, and where the efforts to reach the goal at as good as they can be. So, although continuous improvement achieves goals by removing barriers, it also identifies that optimal end state where the product has reached maximum value.

Be more fox

This week’s irregular ideas was about not tying ourselves to a single big idea about how the world works. Instead, we might do better to have lots of smaller, different ideas and more flexible worldviews.

The platform charity conundrum

A few thoughts on the challenges of charities using self-reinforcing loops in platform business models. If the loop is always self-reinforcing, then it depends on the problem the charity is tackling getting worse not better, which would mean the charity is failing, hence the conundrum. Since writing this two thoughts have occurred. One mentioned by Nick about how impact (solving the problem) is represented in the model, and another about how the role of the charity (as an organisation) is to turn a positive self-reinforcing loop into a negative self-reinforcing loop.

A system-shifting approach to new product development

I’ve been gradually thinking about how to take some of the system-shifting product management thinking into more practical tools, and this New Product Development process is a step towards creating a process that isn’t user-centred or linear and involves more actors and affects systems to create change.

#NaBloPoMo

I’ve manged to write a blog post every day so far (which is only four days, so not saying much). I’ve previously thought that I want my blog posts to be like well researched mini essays, and NaBloPoMo gives me an excuse to write posts that are more about exploring ideas, work in progress, not well polished. I’m also trying to take on some of the advice I’ve read recently about changing my definition of done (because a reader will never know what it was anyway) and writing more like I talk (or in my case, more like I think).

And I read:

Designing good digital stuff

Read a few things around designing good digital stuff.

Maturity models

I’ve been reading and thinking about maturity models, and how to resolve the problem of maturity models always being an output that doesn’t correlate to organisational outcomes.

Sign Language in Virtual Reality

I read this and this about sign language in virtual reality.

And thought about:

Teams don’t have a brain (but they might have a Brian)

If the team is the unit of delivery, self-contained, autonomous, empowered even, but it doesn’t have a brain, how does it coordinate, remember, decide, act? These things happen because individuals have brains, and they do things like document information, make decisions, do work. Does a team behaviour less like a unit and more like a murmuration of starlings responding to signals from others in the team? If so, what might be the behaviours that the team should be aware of and respond to?

Curiosity

Thought a bit about the second part of my mini exploration into how to ask better questions. If one type of question is aimed at gathering information and the second type is about encouraging thinking, then perhaps the overarching guiding principle is that good questions are about curiosity. They express the asker’s curiosity and encourage the answerer’s curiosity. A question phrased as a statement can be a good question if it’s doing the work of encouraging curiosity. And a statement phrased as a question isn’t encouraging curiosity, it’s shutting it down.

Birds vs elephants

Maybe Twitter is seeing an extinction level event. And some people in my Twitter bubble are setting up Mastodon accounts that they may or may not use. Always good to hedge your bets. And perhaps an opportunity for us all to make more intentional choices.

For me, the interesting question is about the future of social media platforms, and especially really large social media platforms. From a user’s experience point-of-view, RLSMP’s always feel like niche bubbles (Product Twitter, Charity Twitter, etc.) but there’s always an underlying effect of social interaction at scale, which human beings aren’t equipped to understand. So, maybe the next evolution will be to small, loosely coupled, groups (I hesitate to use the term “communities”) where the group is more able to control unwanted behaviour. One of things I’ve learned about online communities (from being a moderator of a few) is that activity equals leadership. The most active participants are the ones that set the tone for the community, create the culture of what’s acceptable, and generally keep the community alive. All communities need these people, without them the communities stagnate and die off, but well-functioning communities also have a way of getting the right (most acceptable to the community) people into those positions.

What user stories are really about

User stories do not have to follow the format, “As a [persona], I [want to], [so that].”

User stories do not have to be used to assign work to developers.

User stories do not have to have “story points” or be used to estimate how long work will take.

User stories are so much more…

A user story is a ‘boundary object’, a conceptual object that has can be interpreted differently by different people but which have enough immutable content to maintain the integrity of what it is communicating. They allow “coordination without consensus”, meaning that not everyone has to agree on how to define and interpret the information the boundary objects holds in order to make use of it how they need to.

The concept of boundary objects was introduced by Susan Leigh Star and James R. Griesemer in a 1989. They describe boundary objects as:

Boundary objects are objects which are both plastic enough to adapt to local needs and constraints of the several parties employing them, yet robust enough to maintain a common identity across sites. They are weakly structured in common use, and become strongly structured in individual-site use. They may be abstract or concrete. They have different meanings in different social worlds but their structure is common enough to more than one world to make them recognizable, a means of translation. The creation and management of boundary objects is key in developing and maintaining coherence across intersecting social worlds.

User stories are a way for people with different domains of knowledge to share a common understanding in a way that makes sense for their specialised knowledge domain and has . A good user story makes sense to a content designer thinking about content and to a developer thinking about code. The story is talking about one thing only, but different people with different perspective can understand the story in a way that makes sense to them.

Writing good user stories isn’t about following a prescribed format, it is about creating boundary objects that work across domains and give people the knowledge they need.

Lightweight digital governance

About lightweight digital governance

What is lightweight digital governance?

Governance is about collective responsibility.

Lightweight governance assumes competency and sets out to create the best conditions for people to get things right.

Lightweight digital governance is about using modern, agile, digital, ways of thinking and doing to create the best conditions for collective responsibility to flourish.

When those conditions exist, things are improved, how they are improved improves, and those improving them see the improvements.

What’s the difference between lightweight and heavyweight governance?

Heavyweight governance focuses on having decision-making controls and checkpoints separated from those doing the work.

Lightweight governance focuses on ensuring people have all the skills and knowledge they need to make the right decisions about their work.

A lightweight digital governance model

Lightweight digital governance

One part of the governance model ensures the thing being governed aligns with strategy, sets the standards, designs the procedures and provides the training.

The other part of the model implements the standards and procedures, does the necessary work, checks it for quality, releases and monitors it to feedback on how well those standards and procedures meet the needs, whether there are gaps in the training, and new things need to be governed.

The model is:

  • Cyclical – the cycle can be monthly, quarterly, annually, etc., depending on the needs of what is being governed, but it relies on a feedback loop for its success. This helps the governance to improve as it improves what is being governed.
  • Separates activities – but doesn’t separate the people or their responsibilities. Those involved in implementing a standard can be involved in using it and providing feedback to improve it.

An example

Governing a charity’s website.

Those involved decide that in order to govern the website effectively that need to take collective responsibility for accessibility, branding, performance, security.

A traditional heavyweight governance model might make different teams responsible for each of those things, but lightweight governance recognises that creates a coordination burden that leads to more trouble than it’s worth, so it’s better that one team with all the skills it needs take on that responsibility.

The team sets the standards for the website, e.g., WCAG 2.1 for accessibility, password length for security, and they write the procedures for checking readability scores or vulnerability testing, and they create training in how to use the procedures to achieve the standards.

They then create content on the website, develop new functionality, etc., applying what they learned in the training, and feeding-back on how that’s working so it can be improved.

The more quickly things move through the cycle, the more quickly they are improved, so critical changes should move quickly and less important change can move slowly.