Month: September 2015

You can’t handle the Truth!

When it comes to leadership it seems that a lot of problems and a great many solutions come down to either a lack of communication or lack of trust, often both.

But why are those two skills so difficult to master? How much time and effort gets wasted simply because we don’t trust our employees, or don’t understand a request? How much dissatisfaction and uncertainty results from not trusting your boss?

Around ten years ago I was working on a major release of software, it was a gated waterfall project. I and three others were critical reviewers and gate keepers for a major component. At the gate review our component was a shambles, really late, testing was far from completed, documentation hardly started. My understanding of the gate review was to quantify risk and to ensure all components were on track with the plan. Essentially a structured early warning system.

We four reviewers unanimously agreed to reject the component. We met a lot of resistance and were put under pressure, we were told that “we were delaying the project”, that “it would make us look bad” it was a difficult decision and we were well aware that it would be uncomfortable. But the reality was that the project was behind and we saw no value in faking things to keep a plan looking good. We felt the purpose was to highlight problems so they could be corrected.

But at some point the plan became more important than the product. The next day a company wide announcement was issued, the project was on track, it had passed the gate and all was well. We were shocked, it turned out that our boss had removed all 4 of us as critical reviewers and replaced us with others that were willing to say all was well. My colleagues and I were deeply unhappy about this.

The lack of trust was shocking, the lack of transparency and honesty showed just how dysfunctional the process was. Unsurprisingly as the project neared the completion the target date it slipped drastically catching people by surprise and the project was close on six months late and we were not first to market. We will never know if being transparent at that point could have given the project opportunity to rectify the situation sooner, but hiding the problem certainly didn’t help.

It is not that waterfall projects inherently lack transparency, but a rigid plan that has a high cost of change creates a barrier to transparency, Project Managers feel pressure to hide problems in the hope they can fix them before anyone becomes aware, or as more often is the case in the hope that another part of the programme slips more so they are not in the firing line.

These days I advocate a software delivery framework that highlights problems as early as possible, but many execs don’t like this. I sometimes wonder if they prefer to pretend all is well or imagine that problems will resolve themselves, this is an Ostrich mentality that allows them to defer worrying until later.

Adapting to an Agile framework where everything is transparent can be a difficult adjustment for many execs and programme managers, being aware of day to day problems, minor issues, or simply that some tasks take longer than expected can be a difficult experience for managers used to only getting positive assurances from PMs.  Suddenly they are exposed to information that was previously masked from them.  They must fight the urge to interfere and learn to trust the teams, to trust the Product Owners and the Scrum masters. In many ways it was easier to ‘trust’ a Project Manager with a Gantt chart when the real story was hidden – even when 90%+ of the time that story was inaccurate. A pleasant lie is always easier to accept than a painful truth.

You can’t handle the truth

The sad situation is that for many execs they simply cannot handle the Truth, they want an agreeable story that lets them claim a project is on track and are happy to believe all is well until it is too late to hide it any longer, and then they can shout and blame, but all this occurs usually after it is too late to take corrective action, the screaming and the desk thumping achieves nothing but to upset people. No one wants a project to be late, chances are they have all worked very hard and done their best. So in reality they have far less influence over the outcome than if they had valued honesty over platitudes earlier in the process. Rather than enforcing overtime for the last couple of months or scrapping all quality control to meet a deadline they could have taken sensible planned corrective action much earlier had they simply fostered a culture of honesty and openness.

I like to think that most software professionals have a desire to do a good job, they want to complete projects quickly and to a high quality. Trusting them should not be a great leap of faith. In my experience you are more likely to get overly optimistic promises than padding. Your biggest dangers are more likely feature creep or boredom, it is very rare to find a developer that wouldn’t prefer to be busy and challenged.  

In short trust the development teams, it is very likely that trust will be rewarded.

One swallow does not a summer make.

Version One  are currently in the process of compiling their 10th State of Agile Survey (Link to Agile Survey)and this caused me to go back and look at the previous results. As an Agile advocate and practitioner I am very pleased to see that last year 94% of organisations say they practice ‘Agile’  albeit that 70% were relatively new to it and could be said to still be in the transition period. This is all great news, it is a sea change and a clear move towards accepting Agile software development as a mainstream way of working.

But, and it is a pretty big ‘but’ how many of these teams are really, truly Agile and how many are jumping on the bandwagon and saying they are Agile when really all they are doing is one or more activity that has its roots in Agile and so ultimately only slavishly adopting Cargo Cult behaviour.

For those not familiar with the term Cargo Cult, it is where some elements of behaviour are mimicked with the expectation of getting the same results, but without really understanding why you are doing it. Cargo Cult    

With many flavours it is difficult to say what makes a team Agile, it is after all an attitude rather than an action, but there are some actions that are generally considered to be core to Agile Principles. At a minimum I would consider: Co-located teams; Iteration reviews; Retrospectives; Continuous integration and Prioritized backlogs as key.  The list goes on but I would struggle to believe a team can be agile without a minimum of those.

So by using my benchmark of what is the minimum less than half 46% (likely even less) do all of those. More than half of those are claiming to be Agile are doing it without co-located teams, without regular reviews, without regular planning, and without regular retrospection. I want to ask them in what way are you Agile?  You could do all of those and still not be Agile, but if you don’t do any then it is doubtful you are able to learn and adapt.

It is with almost despair at times when I am interviewing a candidate and I ask if they have Agile experience, they invariably answer “Oh yes” when I ask them to describe it they will say “well we have a daily stand-up”, sometimes they say more but for a majority that is it.  I don’t hold this against the candidate, most developers when offered a true agile environment learn fast and thrive, but having a daily stand-up does not make you Agile.

The transition to Agile is now in a pretty vulnerable state, the early adopters were motivated and were likely already Agile in nature and the techniques followed on, they succeeded because of their attitude and created a framework on the back of it and for many this works.  The mainstream have heard it works and are mandating a change but are in danger of creating a wave of cargo cult teams paying lip-service to Agile, and when the transition proves difficult they are blaming the framework rather than understanding that it is a change in attitude and a change in culture and not simply a 15 minute standing meeting that must be endured each day.

The message we as Agile practitioners need to get across is that the transition is not always quick and it is very often difficult, but if you adopt an Agile attitude it will pay dividends, if you simply pick and choose one or two ‘Agile’ techniques in isolation without understanding why, you are in danger of failing without ever really trying.