Improving in the moment
Seeing the opportunity
Many teams and programs that even implemented some Agile practices, miss one super-important thing that prevents them from succeeding. And that’s something we’re going to talk about today.
I’m sure you heard the term “retrospective”, or maybe your team already has one. It is an event, typically held by an agile team at the end of the iteration. As many teams would say, this is where you “improve”. Well... not exactly. In fact, if this is the only moment in time where you consider improvement, it’s not going to get you very far. And no wonder, by the way, that so many teams have dysfunctional retrospectives. The only problem is that it is not the retrospective that needs fixing. It’s bigger than that.
Agile and Lean have their actual roots in the Toyota Production System that created unprecedented quality and manufacturing success. They took improvement very seriously. And one thing they would never do is: postponing the improvement. As a matter of fact, they designed their process in a way that would help spot and leverage every opportunity for improvement. One such specific mechanism is called the “andon cord”. This was literally a cord hanging along the assembly line and any worker who saw a problem, would pull the cord which would stop the production line and a team of engineers would work to address the problem and then resume the process as usual. It’s things like this that their success attributes to. And just so you get the right idea, and not think that this is some idea that is great only in theory but not as useful in practice: andon cord could be pulled hundreds of times on a given assembly line over the course of just one week. And every time it’s pulled, there is an improvement.
From TPS to your team
Now, what often happens in teams is when a problem occurs, the mentality is to keep working on things and not interrupt that, because we have so many work items to take care of. And hey, we have a retrospective in less than two weeks from now, right? So, we’ll be sure to bring that up. But in reality, by the time the team is at the retrospective, so many more things already happened and so many contexts have been switched that only some of those problems bubble up to this level and even if they do, the precious deep context, the tacit knowledge of the problem is lost. It existed in the moment, for sure, but in a matter of days, it’s gone.
But even more importantly, it’s the mindset issue. It’s the mindset of ignoring, postponing, deferring opportunities for making both the product and the development environment better. But only if you relentlessly improve, you will be creating great products that are delivered in time to leverage the business opportunity. So, not only is this relentless attitude towards improvement a matter of great professional pride, but also a critical component in the competitive game that only gets tougher in the age of digital disruption.
So, when a developer on a team that is relentless about improvement, spots a problem with this data access method in their code, for example, she will raise the issue immediately and herself, or maybe with the help of others, solve that problem right away, and then she goes back to her planned effort in that iteration. Not doing this, is precisely the reason why organizations have their IT and software ecosystem in such a dire state with terrifyingly chaotic architectures – because they deteriorated over time, as a result of this ideology of neglect.
So, what is your team’s andon cord? Can you leverage your opportunities for improvement? Put yourself to test! Make a decision, as a team, to take one or two problems that (I assure you) will emerge over the course of the iteration and solve them AS you find them. That’s the important action item. And once you do solve them, be sure to celebrate, right there, without postponing.