Agile consultants: where’s the value?

When I first joined the company as a software developer, there was a push from within the team to start adopting Agile practices. Test Driven Development was seen as a good thing (but first we had to really get buy-in to do more development-driven testing), relative estimation could make our planning a lot less onerous (but getting the Project Managers to accept points instead of hours was practically impossible), pair programming had its attractions – even informally. Over the next couple of years we adopted stand-up meetings, we tried to break work down into smaller pieces, we turned on a CI server and spoke about behaviour-driven development.

So why did we need to get in Agile consultants to turn us into an Agile shop? Weren’t we already doing it? Weren’t they just over-paid people trying to tell us what we already knew?
Well, the thing about Agile is that it’s not just a change within the software development group. It’s not even just an IT change. Agile demands that the whole business is behind it – from the top ranks of executive management to the developers, product owners, testers, designers and anyone else who has any part in product development.

Selling Agile to the developers was easy – they were on board before we started. Getting product owners to fundamentally change the way they think is not so easy. And you need a very supportive and understanding management team. We were lucky in having at least 3 senior managers who had lived with Agile teams and seen the benefits in previous positions. They understand the up-sides that would be coming around the corner. They also understood that any change of this magnitude will incur a short-term dip in perceived productivity.

We were also lucky to have adaptable product owners who enjoyed the positive outcomes of seeing their products evolve but were also up for putting in the hard work and time that’s required to get those positive outcomes.
Persuading all of those other stakeholders to come to the Agile party would have been very difficult (impossible?) if it were led by a group of developers who hadn’t done any Agile but had heard a lot of good words about it. Having external help and leadership was key to getting Agile embedded properly in the IT department.

External help also allowed us to get real direction and experience into our team which kept us on the right track. It’s all too easy to see Agile as an unstructured, unplanned way of doing work. (And it can be if it’s not done well; arguably, that’s not Agile). Doing Agile properly is hard – it requires an awful lot of discipline and if you just take the easy bits and leave the hard bits out, you’re decreasing your odds of a successful project.

In Japanese martial arts, the concept of Shuhari describes the progression in three stages from novice to master. When we started out we were definitely in the Shu (“obey”) phase. This is when the student follows a single master and obeys their teaching. Without solid coaching and direction from our external consultants, we would inevitably have tried all sorts of different techniques and tools, confusing our learning.
I feel that we’re now starting to get to Ha (“digress”) where we can start to expand our learning, reduce our dependence on a single source of teaching and explore the world armed with our foundation skills. Until we reach Ri (“separate”), we will continue to need some level of advice and help to really master Agile.

So could we have gone Agile without the external help? Arguably, we could have starting doing something resembling Agile, but my hunch is that it would have been that dangerous blend of 2 parts Agile to 1 part Waterfall that too often passes for Agile. And when you adopt a mongrel, you never really know how it’s going to act. Would it have worked? Possibly. Would it have been as successful as our Agile adoption so far? I doubt it.

Archives