This week I did:
What’s interesting about planning and prioritising work across products is what you do and don’t know at the time. It’s like having lots of boxes that are all identical on the outside, and uniquely different on the inside. You have to arrange them based on what’s on the inside, but you can’t see that yet.
We’re in Cynefin’s complicated domain here. Those boxes are our known unknowns. Which means we should use lean thinking and methods. Lean is better than agile here. Agile is the right choice for complex domains, but that’s not where we are. Fast feedback loops and course correction aren’t so necessary, not because they aren’t good things, but because the consequence of going in the wrong direction is low.
So, we’ve got to come up with a set of rules that are general enough to be applied when some of the boxes are opened. And still apply later when more boxes are opened. I’m thinking about how to recontextualise devops five ideals for this. The ideal of simplicity and locality tells us that each of those boxes needs to be independent and small enough that it can be opened and understood on it’s own. Focus, flow and joy could be in the work being true to it’s core value so that those working on it feel satisfied that it’s meaningful, impactful work. Hopefully I’ll make some time to explore these more soon, and I need to think about how ‘sense – analyse – respond’ works in this context too.
Completed 40 tasks this week, which averages 8 a day. That’s the lowest number of any full week since I started tracking this way. I was focused on product strategies, which were bigger more important tasks, but it meant I didn’t achieve any of the other things I set out to last week.
Failed to consistently write daynotes too.
My content discovery system seems to be working well. I’m reading more things, but reading them more lightly. Whereas previously, if I found something I wanted to read I’d share it to me website so I don’t lose it, now I know I’m not going to lose it so I don’t pay as much attention to it. Interesting unexpected consequence. Of course it could also just be the result of not-so-normal week. One to keep an eye on.
Agile Is the Steering Wheel, Not the Gas Pedal
Nice metaphor. And interesting point about the steering wheel being in the car, where the team driving the car can change course. Also makes me think about the roadmap metaphor and having multiple routes to the same place that the team can choose.
The influence of mobile technology on user cognition and memory
Might be doing some work on improving our website for mobile users so I’ve started collected interesting articles that make me think about mobile in different ways. The thing that caught my attention in this article was about the time spent on mobiles versus desktop devices. That’s obvious really. Our phones are with us 16 hours a day, whereas desktops, even if you use it for work, is probably only in front of you for 7 hours a day. So, time drives mobile traffic over desktop traffic. That’s different from availability being the driver. It isn’t just that more people have mobiles than desktops, it’s that they also use them more of the time.
And I thought about:
Simple rules in complex systems
The go-to example is starlings murmurating. They follow simple rules to avoid flying into each other. But, as I wandered past a football match, I wondered if the same applies. One team had three phrases they all kept using:
- “Give him options” – means support a team member who is being pressured by the other team.
- “Pressure them” – means act offensively towards the other team.
- “Unlucky” – recognises a team mate taking a risk and trying something even though it didn’t work.
Those three phases are enough to coordinate a group of people around a shared goal, within a fairly closed system with fixed rules.
I listened to two podcasts, both vaguely about networks. It made me wonder about workplace networks and how people are connected. What would a network map for your organisation look like if it showed the five people each person spent the most time with? Would it give you a better idea of how information flows? Would it give a more realistic picture of the organisation?
What if projects started with a reading list?
Before goals or scope or any of the practicalities of running a project, what if people spent time reading about the subject of the project? We talk about learning, but we expect it to come from and after the project. What if learning was built into the project, partly to get everyone some shared knowledge for the project and partly just to support professional development? Might try it some time.