Did you know, there’s a second page of Manifesto for Agile Software Development? You’d be surprised what’s in there – and how unlikely it is for your business to follow the principles listed there.Read more
For years, I have lived in a belief that complex problems require complex solutions. If we’d like to hugely improve our business with agile, we should use some complicated framework, with multitude of tools, approaches, and processes designed to address every possible scenario. It backfired on me several times. The wake up call was almost three years ago, during Agile Portugal 2015 conference.
You might know it or not – 2015 was year of agile at scale. If you wanted to be treated seriously as a speaker, consultant, or coach, you just had to share your experience with it. Everyone was into scaling. Because, clearly, we all knew how to do it right on a team level… Obviously, having quite a background at large scale agile, I joined the bandwagon. My speech in Porto covered exactly this topic.
Then, during a break following my presentation, reality hit me with a sledgehammer.
You all talk about agile at scale, which is great, but we’re startup of ten people and want to do it. How?
If I remember correctly, my answer actually made sense. Something along the lines of starting small, using the least processes and formalities possible, just the kind of basics that make sense. Regardless, I was dumbfounded enough to quit corporate job two years later and joining a very small company to see how it really works.
But there’s more to it.
Just at the end of 2017, I was contracted to run series of trainings on basics of agile to over one hundred employees of a large state-owned conglomerate of very traditional sector. As if it wasn’t challenging enough, majority of the participants had little to none exposure to IT terminology, processes, and industry. Trying to grasp and convey the essence of what agile is was quite tricky.
To make things worse, I’m not really sure if they stand a chance to actually make it with the transformation. Reading between the lines, it was clear that management buy-in was dubious at best. Agile was yet another great idea they had, following (and perhaps preceding) series of other spectacular transformations.
Yet, I wanted them to benefit from my trainings regardless of what future could bring. Then, out of the sudden, I had my eureka moment. I found the Holy Grail of the least you could do to get all the benefits in the world. And it was hiding in plain sight, disguised as one of Scrum ceremonies.
(I seriously dislike the official, semi-religious terminology of Scrum. Artifacts, ceremonies, masters…)
Retrospectives, in their simplest possible form, are Minimum Viable Agile.
It’s that simple. Get your team for half an hour and ask them the most basic and most profound of questions: If we had a second chance to live through these last two weeks again, what would we do differently?
Hell, you don’t need to wait few weeks. You can ask this question every morning. The benefits will astonish you.
First, as human beings, we hardly ever reflect on our lives. Not to mention, on a regular basis. We only do this when things either radically change (think: you’re about to have a baby), or when they go really, really wrong. If neither of these conditions is fulfilled, we just fly ahead with staggering mindlessness. Nothing weird about that, we’re just humans, perfect in our imperfection. It is worthy to shed some light on whether we’re going the right direction or not.
Second, no currency is worth more than our time. Not only you cannot buy more of it – it comes in extremely limited supply. Given you’ve reached this sentence of this post, you’re about four minutes closer to your death than you were at the beginning of it. It’s one of the most uncomfortable facts people are ever faced with. You will have no chance of reliving yesterday. If you did something stupid, or pointless, or in an inefficient way – you will not have a chance to change it.
You do have a shot of making it differently today. Otherwise, tomorrow you will be even closer to your demise, with yet another wasted day. That’s your choice.
Third and the most important reason for starting with Minimum Viable Agile – it will get you somewhere else. Yes, there are thousands of prophets saying you must use Scrum, Kanban, or whatever else. Each of them has numerous examples of how, to a different extent, these things worked in the past. They are perfectly right about that! These approaches, in that particular conditions, in these particular businesses, gave very specific results. That’s a fact.
However, extrapolating these past experiences into your business can be nothing but a false prophecy. No company is out of the box, so applying off-the-shelf framework can only work to an extent.
By regularly inspecting and adopting the way you work, day by day, you can create your own agile. Tailored and customized to your specific needs, to the way your people work, to the very DNA of your business.
All it takes is to start small.
So, if you had second chance to relive yesterday, what would you do differently?
In recent months, I ran dozen trainings on Agile aimed at (mostly) non-IT crew of a very large and old company. It was extremely challenging to my comfort zone, especially as it meant the whole course to be rebuilt from scratch. I had to stay as far as possible from IT-related terminology, examples, and practical applications of the philosophy I shared. While the whole experience gave me a lot of thinking – and while you’ll be able to see quite a lot of it in upcoming posts – let’s focus on one area that almost every group asked me about.
What books could you recommend?
It really troubled me at first. Not only I wanted to stay outside boundaries of geeky world of deliveries, releases, and features. I wanted to convey philosophy, not specific methods – especially given most of these people, in their workplace, are unlikely to drastically change the processes they are involved in. That unique challenge resulted in following list of three books that I recommend to everyone.
Coincidentally, two of those three books are those I give away as gifts regularly.
Why? Because to me, almost everything about Agile is to accept reality as it is. Which is contrary to how most old-school approaches seem to operate. We all suck at precise estimations. Agile addresses it in variety of ways. No rock-solid plan ever survives first contact with reality. Likewise, there’s something Agile could do about it. Transparency and understanding of what’s really important is crucial to every business successful operation. Again, plenty of mechanisms and approaches are spread across things called Agile.
Make no mistake, Ryan Holiday’s book makes no reference to the new black of IT. It’s all about seeing the world the way ancient stoics did – as it is – and making smarter choices, instead of habitual ones.
Does that ring a bell to all you Agile aficionados?
I buy this book in bulks to give to people who could benefit from it.
It is, indisputably, the single best book I have ever read. I doubt it could ever be moved from the first place. Written in 1946, it chronicles Frankl’s experience as a concentration camp inmate in WW2 Germany. Being already a renowned psychologist, he observed how sense of meaning and freedom of choice (present despite nightmarish reality) affected longevity of prisoners.
Book is, at one time, extremely sad and uplifting. First time I read it, it watered my eyes, yet left me with positive outlook on life. It turned out, that even when things go inhumanly wrong – we can always do something about it.
When read in combination with the first book, it prioritizes our problems properly. In essence, it makes most of them not worth our while.
When putting Agile philosophy into practice, it’s good to know what’s truly important and remember that we always have a choice.
Heck, it’s good to know these two to live a good life.
Compared to the two first choices, this one seems odd. It’s neither philosophical, nor life changing. Why is it on the list then? Because most employees worldwide have negligible to none experience as business owners. And bringing operations closer to business is one of the cornerstones of Agile as a whole.
This book bridges that gap. In simple words, with great examples, and practical recommendations, it explains basics of entrepreneurship, from mindset to practice. Entertaining and worthwhile read.
A word of advice
Each of these books can make you want to quit your job. Whether it’s good idea or not – that depends. It’s always worth consideration and analysis though.