Today I’m siting at an internal presentation and we’re discussing how organisations adopt software development frameworks. We’re talking about how it can be useful to start with a framework and to follow it diligently until people feel comfortable. Once you reach that point you can take the “training wheels” of a prescriptive framework off and start changing and adopting to optimise for your particular needs. People suggest that starting with “Scrum by the book”, for example, gets you to a good place from which you can evolve.
Last week at Lean Agile Scotland, together with Seb, we gave a talk called “Your agile is dead” sharing our experience of building a small agile team. The main premise of our talk was that we first threw all the conventional practices out of the window and started from scratch. No planning, no stand-ups, no iterations, no visualisation of work! Sounds crazy, right? Well, we kept some components – a tight feedback loop with honest and thorough retrospectives and some basic engineering practices. We evolved and added more practices as we needed them and reached a pretty good state.
It was our twins’ birthday last weekend. They are turning five and we got them both new bicycles. They had some bicycles before but these are the first proper bikes. Interestingly, one of the bikes had the training wheels on but we didn’t put them on the other one. Sure it was a horrible few minutes trying to ride on a new bike with breaks, pedals, handlebars and no stabilisers (aka training wheels). As to the other bike, the experience was smooth straight away but the stabilisers are limiting and it’s going to be a good few weeks I suspect (or maybe months) before we can take them off the other bike.
What do stabilisers on a bike have to do with software development process then? I think of them a little bit like the support of a fully-formed framework. It can be easy to start with scrum and the ride is smooth but you will never take sharp corners or ride full speed down a hill. Your options are somewhat limited. And when you try to change the rules – it’s painful and sometimes things fall apart.
Does that mean we should put no support in place? Should we throw everyone in the deep end every time? Sure, some will swim, but some will sink.
What can you do to prepare for riding a real bike that doesn’t involve training wheels? You can start with a balance bike. You don’t need to worry about breaks or pedals or steering so much but you get to experience the balance. And balance, it turns out, is the key skill when it comes to riding a bike well.
When learning a new skill or introducing a brand new way of working look for transitions that ease people in but don’t rob them of experiencing the core principles. Make sure that you leave the most fundamental feedback loops in place.
For your cycling skills it is the feedback about how your position and speed affect your balance. Training wheels almost completely remove that feedback. In software development it’s perhaps the feedback about how your interactions as a team of individuals translate into working software. Iterate, reflect, retrospect, adapt. Put boundaries in such a way as not to impede future learning and improvements.
Do you remember the TV ad with a blue and green background and lots of cars falling from the sky? Probably not. Anyway, you shouldn’t mention it to our marketing director either. Three years ago however, this was the only image I associated with comparethemarket.com. This and some eccentric Russian meerkat called Aleksandr. I certainly didn’t think of it as a place for a job in IT and I wasn’t going to take a permanent position anyway. Reluctantly I agreed to a conversation over the phone and unexpectedly got hooked up.
Few interviews later I was ready to claim my own desk in the “Travel” team in a plush new building the company had just moved into a few weeks before I joined. Who knows, the old building might have been enough to put me off. After all the “IT” teams were sitting away from “the business” back there but now was the era of an “agile” revolution.
Revolution or not, a lot was changing at compare the market and I have managed to land right in the middle of the kerfuffle. This has given me an abundant opportunity to do what I love the most – an opportunity to learn.
Today is the time for me to move on to pastures new and reflect on the three years of learning that are behind me. I made a list. It’s a long list; a list of thing I got exposed to, things I dabbled with, experiments I run, mistakes I made, mistakes I avoided, mistakes others made. We’d be here all day so I hand-picked a few, just to give you a flavour.
Ever since I joined we had a strong recruitment drive. There simply never seemed to be enough people around, even though there are many great people here, so we were constantly on the lookout. We still are. This is how I got involved in recruitment. I think I must have done close to a hundred interviews and complained about oodles of poorly written CVs. Sooner or later I hope they will disappear as a recruitment tool and perhaps we’ll replace them with an approach like nujob, which we dabbled in.
I’m glad we acknowledged that finding good candidates requires investment in the local community. Taking the long-term view. So we have run events, we engaged with the local university and even local primary schools! You have to start them young you know. This is how I got to lecture at UCP about TDD and about systemic feedback loops and giving personal feedback. It was really encouraging to see the students get the skills they will use in the real world. This is also how I got to run Code Club at the local primary school. Probably one of the most rewarding experiences recently. To watch a bunch of 9 year olds going from shy interactions with their machines to confidently teaching younger children how to tell the heartless machine to do as they imagined – priceless.
Being part of a community means the local community and also the wider software development community. I was lucky enough to visit and present at quite a few conferences and we sponsored a few events too. Sharing what we learn and looking out for what others are up to is a great way to keep yourself honest. Seeing your colleagues pluck up the courage and speak for the first time in another one of those little gems that keeps your face muscles exercising.
At this point I could tell you about all the ideas, tools, techniques and technologies I got an opportunity to explore and use in anger: CQRS, Event Sourcing, node.js, mongo, RabbitMQ, HAETOS, microservices, ruby, rake, slack, you name. But even if I attempt at any such list it will be dwarfed by what pops up out there. Every. Single. Day. That’s technology, I guess that’s why we’re still here. What I have reasserted is that given deep enough understanding of the fundamentals and an unquenched curiosity we can remain unfazed in the face to the constant technological change (I hesitated to use the word “advance”).
They say opportunities are where you create them and indeed often you can create them in the most unexpected circumstances. Just keep your eyes peeled. One thing you don’t always influence though is the people you get to work with. I was really fortunate in who I have managed to engage with over the last three years. People way more experienced and opinionated, patient and forgiving, famous names in the community and only locally recognised experts. I’m grateful for all of them who were willing to challenge my idea, share better solutions and help me become a better person.
The meerkats, naturally, were ever present and even though we have created so many amusing adverts, this one still remains my personal favourite.
Today is my last day at compare the market. Thank you. I’m expecting new adventures to provide no fewer learning opportunities. After all I’m moving countries. This, however, is a story for another day.
“The Law of Learning Entropy” talk at LKCE14 in Hamburg, 11th November 2014
In my observations of many different software development teams I often get an impression that people see time as the most important commodity available. This is reflected in statements like:
- “This project is going to be late”;
- “We are incurring technical debt because we’re going too fast”;
- “If we spend more time planning we can be more confident about the outcomes”;
- “We have defects in production because we didn’t spent enough time testing”.
All these statements suggest that time (that is if we had more of it) could easily be exchanged for other qualities of our software development processes. More time for development can be changed for cleaner code; more time planning – for higher certainty; more time testing – for higher product quality. This is a natural and understandable approach. Many things that we directly experience in the world around us, particularly those that deal with construction or production, appear to have such properties.
In my experience these statements have very limited application to software in particular and more generally to product development. As Kevlin nicely puts it in this great podcast
“because you spend a lot of time pausing trying to understand stuff […] it turns out you actually have plenty of time”
This exposes the true underlying commodity that we should really focus on: learning.
Sure time is required for learning but time on its own is not sufficient. We must expose assumptions, run experiments to verify them and adapt based on the outcomes.
Every now and then my twitter stream comes up with an interesting statement or question that sparks some reflection. The latest one came from Paweł:
Should a senior manager veto decision of one of their team leads if they don't agree with it? Or should they do nothing and see results?
I’m going to treat is slightly broader, speaking of a team rather then just a team lead.
This is not only an interesting question but also one which, I bet, often gets asked, especially as teams gain autonomy in organisations. Let’s leave out, for the time being, the more fundamental issue, whether we need managers at all, and Bob has some tasty thoughts about this.
Let’s consider the two possible solutions to this conundrum.
Veto the decision.
This is most likely the default answer in traditional, command and control organisations. When seniority and position in the hierarchy is confused with experience and knowledge senior managers fell obliged to make their stamp and protect their subordinates from doing the wrong thing. I hope this approach immediately raises your concern, at least a bit. First of all, the higher up you are in the chain-of-command the more removed you usually become from where the real work is done and your understanding of the context and specific challenges diminishes. More importantly however, to blindly veto your team’s decision is a stark demonstration that you don’t trust their judgment or their knowledge. It undermines their autonomy (assuming they had some to begin with) and demotivates them from taking responsibility for their own actions in the future.
Let the team fail.
If you care about your team accepting responsibility, about their autonomy and motivation you may think that the best outcome then is to do nothing and wait for the result. After all, you might accept that you are wrong in your opinion or you may want to give the team an opportunity to learn and fail. The team will continue with their own, independent decisions towards some outcome. They may succeed, or they may fail. If the latter outcome realises don’t be tempted to go and say “well, I always knew this was a bad idea but I wanted you to learn for yourselves”. Regardless, by not sharing your concerns you are withholding information from the team which can potentially harm the team and thus the organisation.
There is a third way.
When Paweł initially asked this question my immediate reaction was that it is irresponsible to do either. It felt very similar to the problem of delegation. “To delegate or not” appears to be a puzzle for many managers. Jurgen gives a good solution to this one reminding us that there are in fact perhaps as many as seven different levels of delegation between the two extremes.
I believe it’s better to aim for the middle in this particular situation too. My preferred choice would be for the manager to honestly and openly approach the team. They should share their concerns in a neutral manner giving the team the information and the context they might be missing. Seeking to learn their position on the problem, exploring the different potential outcomes, exposing any implicit assumptions that either side might be holding and then allowing the team to take an independent, but hopefully better informed, decision. And even though it sounds like a long-winded process it can all be done in a 15 minute chat at a cafeteria.
However, remember what Senge repeats after Argyris
If there is disagreement, it’s usually expressed in a manner that lays blame, polarises opinion, and fails to reveal the underlying assumptions and experience in a way that the team as a whole could learn from.
If that were the case, perhaps the question we begun with is not even the right question to be asking.