Uncovering better ways…
I can tell you everything you need to know about agile in three words.
The first sentence of the Agile Manifesto says it all. It says, “We are uncovering better ways…”. Those are the three most important words in the whole manifesto, or anything written about agile since. They tell us the essence of what it means to be agile.
Just three words:
- Uncovering – means finding out as we go, not thinking we can know it all upfront.
- Better – let’s us know we are always looking for improvements.
- Ways – tells us it’s a practice, it needs to be worked at repeatedly to make it successful.
Uncovering better ways… of doing anything… but especially…
Uncovering better ways to lead…
…is still emerging, and there’s lots to learn, but it probably means considering things like:
- Embracing change and uncertainty, not portraying false certainty.
- Involving people in creating vision and direction, not telling people what to do.
- Cultivating emotional intelligence, self-awareness and vulnerability, not ignoring the soft skills.
- Being a trusted thought-partner, not a teller of single truths.
- Practicing nonviolent communication, not giving orders.
- Bringing positive energy, not problems from above.
- Removing obstacles, not ignoring them.
- Creating the conditions for good work to happen, not focusing on process.
- Empowering and trusting other’s expertise, not thinking you know best.
- Using radical candor, not leaving issues unresolved.
- Encouraging intelligent failure, not blaming people for making mistakes.
- Coaching, supporting and challenging people, not leaving them to figure things out for themselves.
- Role modelling desired behaviour, not expecting others to be the ones to change.
Uncovering better ways to be a team…
…is best done by the people in the team and could include things like:
- Working together as one team, not working in silos and handing over work from one team to another.
- Having shared goals, not individual performance objectives and rewards.
- Knowing the user and their needs, not doing what stakeholders say.
- Reducing cognitive load, not being overwhelmed.
- Developing relationships, not letting things get in between us.
- Respecting different opinions, not following the loudest voice.
- Embracing diversity, not hiring for fit.
- Fostering psychological safety, not exerting power over others.
- Protecting wellbeing, not promoting heroics of putting the work first.
Uncovering better ways to organise work…
…has lots of potential and might include things like:
- Optimising for the flow of value, not for just getting work done.
- Limiting work in progress, not slowly working on many different things.
- Visualising work, not hiding it.
- Creating fast feedback loops, not planning everything upfront.
- Aiming for excellence, not letting quality slip.
- Pulling work to ourselves, not pushing it to others.
- Learning, not assuming we know all we need to.
All ways are continuous, things can always be better, and the uncovering is never finished.
Weeknotes 412
This week I did:
Convergence
Quite a few things felt like they are starting to come together this week.
- Did quite a bit of work on socialising our new workflow process, especially talking through the problems we’re trying to tackle with it and how the different artefacts fit in. I know it’s a very product-y thing to focus on making sure we understand the problems before trying solutions, and although I sure what we’ve designed isn’t perfect, I can confidently connect each part of the process to a problem. That feels important rather than dropping in a standardised process that isn’t context aware.
- Had a few interesting discussions about user journeys, service boundaries, aligned measures of success and the analytics required to support understanding. It’s a big, joined-up piece of thinking with no easy answers.
- Started to understand some complicated supplier relationships.
- Welcomed a new team member who’ll be helping us change how we scope work to make it more collaborative.
- Thought about our long-term roadmap, how to visualise it, and what kind of thinking needs to go behind it so it doesn’t come across as a sequential timeline.
- And last minute question that came up on Friday – should we do some team sessions on agile to get everyone to the same understanding? I think team discussion is great, but when it’s about how people understand something vague like agile it can easily go nowhere. And training that tells people one person’s definition of agile doesn’t help them unlearn. Lots more thinking to be done.
The numbers
Completed 41 tasks.
Wrote 13 pages of notes.
Spoke to 33 people.
Had 16 hours of meetings.
I read:
Demanding predictable solutions for uncertain and complex problems
I nodded all the way through Audree’s post about the tension between the output-orientated worldview that tries to create predictability and the outcome-focused worldview that doesn’t accept things can be predicted.
Maybe it’s a chicken and egg problem. Those asking for outputs might not have confidence that those who are being asked are able to achieve outcomes. And those asking to be given the space to achieve outcomes have no way of demonstrating they can do it. There’s a lot of trust and understanding required, which doesn’t exist in the early stages of a new relationship, especially if those involved have mutually exclusive views. Something’s got to give.
Sociotechnical systems theory
I started learning about sociotechnical systems theory, an approach to complex organizational work design that recognizes the interaction between people and technology in workplaces. The interesting thing is that when it was introduced in the fifties, it was pioneering for its shift towards considering teams as the primary unit of analysis and not the individual. The theory says that the ability of individual team members to perform their function is not the only predictor of group effectiveness, and that team cohesion and leadership at the level of the team, referred to as “responsible autonomy” (Trist & Bamforth,1951) matters more. The idea of self-organising empowered teams has been around since 1951! Who knew?
Let it flow
I started reading John Knight’s doctoral dissertation about unifying agile and service design work. This is where the intellectual action is right now; figuring out how disciplines, principles and frameworks fit together, not in creating new frameworks.
Product management in one thread
Shreyas Doshi, well-respected thought leader, posted this definition of product management:
“Role: Define the product & coordinate actions across the org to enable its success. Success: User adoption, Business impact. Skills: Common sense, immense empathy, influential communication. Traits: Low ego, deep care, high agency. Simple, but not easy.”
I appreciate the posts I don’t agree with more than those I do because they make me think about my opinion. This definition isn’t exactly wrong, but it is completely uninspiring. I wonder if the context of this view is the backlash of Marty Cagan’s view of a product manager and trying to recognise the realities of many product roles in many companies. Anyway, I don’t believe there could be a single definition of the product management role, it’s still too new and changing with the digital times to know what it is yet.
And I thought about:
Measuring an uncertain world
I spent far too much time thinking about OKR’s and what environment they need to be effective (thanks, brain. Maybe try letting go a bit more). I realised that OKR’s can only be effective in a stochastic worldview where you are trying to achieve uncertain outcomes. If an organisation has a deterministic worldview with measurable targets to reach, OKR’s aren’t the right tool for understanding progress towards those goals. I feel some relief at resolving that particular brain itch. Might write about it one day.
Sprinting to infinity
To me, the point of sprints is to create fast feedback loops. Do a small piece of work and put it in front of a user to find out if it’s solving their problem before you invest more time in it. But increasingly I hear people talking about working in sprints as having value itself, even without the feedback loop. So, I wonder, what is that value? Is it in breaking the work down to bring it within the cognitive load of humans? Is it in appearing to be more agile? I genuinely interested in figuring out the value of practices like sprints.