The Unicorn Project from IT Revolution, brings together a number of interesting ideas. In the coming weeks, we are setting up a series of meetups to discuss these ideas from the book and how people look to apply them to their own projects.
One of the central themes of the book is around 5 ideals. These are:
Locality and Simplicity
Focus, Flow and Joy
Improvement of Daily Work
Psychological Safety
Customer First
Ahead of each of the meetups I plan on writing a blog on the topics we plan on discussing. So first up, I’m diving into the first two ideals and how they might be applied. Let’s go!
Locality and Simplicity
This ideal flows nicely from my topic last week on visibility for your digital transformation. Mapping out your value flow allows you to see the complexity and identify bottlenecks. This is not a one-time event, we need to be looking at how the changes we make are impacting flow all the time. However, to do this consistently across the entire system becomes more difficult as the system grows.
Any change to a system inherently impacts the complexity. This was described in the book using another key concept, the idea of complexity debt. This is something that I think captures the impact far better than technical debt alone.
Creating the capability for local changes and working with simplicity in mind, we don’t always need to see the entire picture. Enabling the team to address issues immediately allows them to be constantly working to improve the system as they go. While having that holistic view allows us to identify where we should focus, this is often difficult in larger organizations where multiple teams or areas are required to execute a change. Simplifying this and standardizing the system reduces the number of decisions a team needs to make.
To enable teams to be able to solve problems locally, within their team, we require that simplicity. We need simplicity in our architecture to decouple components so that a single team can deliver value independently of all other teams. The more we can achieve this and reduce the number of teams involved, the faster we can deliver.
Most recently, I’ve seen this principle applied successfully in a two-pronged approach to help a bank improve its delivery practices. The first was to create opinionated pipelines built off in house developed APIs and the second was to enable the software delivery team through a focus on flow. Both approaches worked, providing different options to different parts of the bank and accelerating the transformation overall.
Focus, Flow and Joy
Much has been written about flow, one of the most famous books on the subject being Flow by Mihaly Csikszentmihalyi who coined the term.
Its importance to delivery teams is clear. Anybody who has ever been caught up in the moment of writing code and experiencing the outcome of your creation may have experienced those moments. Even writing this blog post creates those moments.
To get there, we require focus. Something that is rapidly eroded by context switching caused by meetings, new requests, operational support, organizational events etc.
So what can we do to help provide the necessary focus to delivery teams?
Well there are many ways, but some of my favourites are:
Start by making work visible, so everybody is aware of the priorities, then focus on reducing work in progress.
Simplify how you categorize the work, make it small, medium or large to be be done now, next or later.
Reduce meetings, only meeting when really necessary
These practices, and others, are commonly found in the adoption of Agile practices.
Conclusion
Hopefully, that gives you some ideas about how to apply the first two ideals in your environment. Starting with a powerful, outcomes focused, roadmap can take you a long way towards these goals. I’ll be covering more ideas out of the book over the coming week. I look forward to hearing your thoughts on these ideas and how you will apply them.