It can be difficult to face up to the truth.
Sometimes the way that truth is told comes across as abrupt and direct and can have the opposite effect to that desired and drive people into even more denial.
We know, however, that facing the truth means we can take action and early action often means a better chance of recovery or even survival.
We were working with a team to get a project on track after at least two years of going nowhere. We helped them to readdress their requirements, get business partners to take ownership and be part of the process, set clear vision and value drivers, introduce new tools to measure progress and bring a new sense of vitality to what had become the poison chalice.
All was looking wonderful: beautiful people, beautiful process, beautiful….
But what about the product?
The positive thing about making work visible, both in terms of that displayed on Kanban boards and described in daily stand-ups, is that it is clearly apparent when things are not being completed.
Taking a visit one day to check on progress with this team began with a quick look over their boards and a listen in on their daily meeting. Immediate concern over what was previously displayed as a “September” release was now “Autumn”, but more about that later. Clearly plenty of work in progress in development, nothing in test and a frighteningly small amount of work complete and ready for user acceptance testing.
So to the stand up: lovely people, very upbeat and optimistic, but not one person said what they had completed the day before or what they would complete on that day. And no one was challenging them. But it was all beautiful.
We spent some time talking with people. To get over the problem of a lack of progress they were hiring more people to give them greater capacity, but, in the short-term, that was going to have a detrimental impact on productivity, as it would draw the productive members of staff away from the task to train the new.
For those involved in producing software, the newly adopted test-driven approach was, of course, going to give them a massive benefit when it came to testing the software later on. So much so, all their effort was being put into developing tests rather than software.
So we spoke with the senior guy. He looked worried, so called the senior leads from the team. We started with dates: “why is it that we can’t get a straight answer to what is the target date for this project, what had you previously committed to for September and why is this now autumn?”
It was a beautiful question – they loved it and they all found it very amusing because, although they said September and autumn, no one ever said which year it would be in. “Best not to be too precise with the business as it would only set false expectations”.
So, we faced the truth: when we started out on this project there was an observation, more of a complaint, that the business never engaged in the process, threw requirements over the wall for IT to get on with. We were asked to change that and we did. They are now an integral part of this process and everyone thinks it’s beautiful. “So now, why won’t you be honest with them? As the senior team, look at the consequence of your lack of precision: your development teams are equally vague about what they are doing or what they have done”.
We left them with two clear actions: get honest with your business and talk about specifics and, if dates can’t be achieved, let them know sooner rather than later; get honest with your team and seek honesty from them and, when things are not clear about what has or hasn’t been done, just ask.
Kanban boards are a beautiful thing and they will tell you the truth about what is going on. You just have to be brave and face up to reality.
