Sunday Quote 📑
Have you heard of The Unicorn Project? It’s the follow-up to the great Phoenix Project. As I said in my 2021 book review:
"what Kim did for Ops & DevOps in the Phoenix project, he has continued for product development in this work"
Both of these books use narrative to demonstrate the move to agile ways of working and devops transformations within an auto-parts selling business.
These five ideals are very helpful for looking at ways to enhance a technology practice.
Here’s where I’m going to "think out loud" again. As I read these, I realized they’d make a better framing for how I’ve been approaching some challenges my team faces at work. I’ve been communicating with my manager using the perspective of "accountability without authority or responsibility", and while that’s true, the Unicorn Project ideals might be an even better lens by which to view the problems.
Let me work through them to see what we are doing or could do in each area.
Locality and Simplicity
To solve these, we need to create local ownership and reduce waste & complexity. Instead of there->here->there work, we can improve this in one of the following ways:
- here->here->there: meaning that my team sets the direction, rather than receiving it, but the other team still manages the result
- there->here->here: meaning that my team still receives the direction, but has more capability to finish the work on their own
- there->there->there or here->here->here: meaning that one team has full ownership for direction, results, and problems for an area of work
Focus, Flow, and Joy
Altogether, those equate to very little time for focus or deep work. That results in less satisfaction and joy as people feel like they are constantly juggling instead of achieving momentum through wins.
We’ve got a few irons in the fire on this, too:
- "No Meeting Wednesdays": we instituted this recently, and while not perfect (due to stakeholder meetings and increased interruptions from people who know we are "free"), it helps there be the chance for blocks of time for focus
- "Ways of Working" agile alignment: I’ve been proposing that we get all our work visible under one mechanism, so that we can better manage priority, work-in-progress, etc. It would also help to have requests come in a common way, reducing interruptions. We’ve got buy-in now to get some agile coaches working with our broader org on a group transformation.
- Using collaborative tools: Many interruptions can go away if we have standard means to keep one another up-to-date or make decisions. I’m helping push adoption of these ways. (Kanban boards instead of status meetings and inquiries, asynchronous work out of the same document rather than a meeting for committee-editing, decision-records and next-actions captured in writing, etc.)
Improvement of Daily Work
Instead, I try to make up for some of this deficit by spending a lot of my time on this, looking for ways to help the team. Creating clarity. Creating or sharing resources that make things easier. Promoting the internal sharing of best practices, wins, and lessons-learned. Cutting waste. Eliminating blockers. Etc.
It wouldn’t be appropriate to say much here (as it could affect psychological safety!), but I will say that I seek to promote psychological safety by being transparent, authentic, and non-defensive. I look to give opportunities for people to stretch themselves in a safe manner. I aim to make sensitive constructive comments in private and heap praise in public.
The first is the most important: the end costumer of the product or service. Do we know what they need, and is our work ultimately serving them? Or are we creating waste and doing pet projects?
The second is the internal customer, or stakeholder. This one is easy to overlook, especially if a team isn’t used to thinking about having customers, which is an all-too-common occurrence in the technology world.
To help with this, what I do is to advocate for customer and stakeholder perspectives up front and every step along the way, both in my team and for the teams where we are the internal customer.
- Who will use the product or service?
- What do they need?
- How does that inform our requirements?
- Is somebody getting their perspective and feedback?
- Do you need to get their buy-in for the solution?
- Is there an easy way for them to give you feedback and see that you are doing something about it?
If your org has a product-owner type role, this helps a great deal!
I hope taking a look at these 5 ideals was helpful for you. If you’ve used them to examine some ways of working, tell me about it!
Originally posted at Hey World