James Shore made a great post the other day, Stumbling Through Mediocrity in which he talks about how dysfunctional companies will never truly reap the benefits of an Agile adoption as they aren’t inclined to actually change their ways. Rob Bowley then followed up with his post, Agile Isn’t Enough likening the introduction of agile to dropping a bomb on the internal workings of an organisation which then sends out ripple effects with much wider repercussions that actually get ignored by managers.
I posted a while ago about the fact that I thought that all a team needed to be successful was a clear set of parameters to work within and the support needed to build a learning culture and I maintain that opinion. Indeed when I started at 7digital I was keen not to sell any particular methodology. I set out 3 things that I thought that the department as a whole should focus on; Focus On Quality, Releases as Non Events and Building a Learning Culture. Whenever I spoke about those things I was careful and still am to a certain degree, not to use the dreaded “A” word.
One of the biggest impediments to introducing a change in process whilst I was at my last company, aside from the abundance of people with their own political agenda, was my attempt to introduce “Agile”. I realise now that rather than bestowing the virtues a bunch of practices I should have spent more of my time talking more about the principles. Furthermore, I should have found out whether or not people wanted to change. If they didn’t perceive there to be a need to, then it was my responsibility to find out why, perhaps they had a point and perhaps even in having that conversation they may have heard my point a little more. You live and learn.
What’s interesting though is that whilst there were a large number of people that I used to perceive to be willing to fail, pretty much all of them wanted to get the job done or the project delivered but I was putting it down as a failure because we hadn’t successfully engaged with our Customer, we weren’t in my opinion delivering everything that we could be for them and we hadn’t truly enabled the development team to deliver a quality product. Often I would sight agile as I thought that it would be the answer to these perceived failings and I still think it is, ironically it became a barrier to it though.
Given the posts I mention above, it would suggest that I am not alone in my point of view. My take on it is though, everybody hears the “A” word and thinks “here’s a process that we can use to deliver this piece of software” but actually it won’t. It requires commitment that a lot of people just aren’t willing to give and in many respects, perhaps the word Agile is in fact a hindrance.
Perhaps we should just start sitting with our customers more and hearing exactly what they want from the software that we deliver them and in doing so, put our case across about what we want from them. Do we necessarily have to persuade them of anything other than that we want to deliver the best quality product and that we want to do that by working as closely with them to understand their business model, that we want to as honest and transparent as possible about how we’re progressing. It’s keeping these conversations going throughout the project that’s most difficult. And it’s that very thing that we should be working on the most. The arguments have been won already for how much more successful we are when we use certain techniques as opposed to others, they should be implicit when we say we’re going to develop software.
braek for caek 