Be Careful What You Wish For
Are you prepared for what agile really means?
Agile transformations are a big commitment. It’s not just a case of saying “OK, let’s have a go with this agile thing”, there is a much bigger commitment involved than that. As Liz Keogh suggests in her 2011 post just providing a team with a couple of days training is not going to cut it. There is a mindset shift that needs to take place. In all areas of the organisation. The good news is that I have yet to meet someone who hasn’t been able to benefit from what an agile approach has to offer – therefore there is always something “in it for me”. However, as with most things in life, it doesn’t come for free.
Developers (and I am talking in the generic, almost role-agnostic sense here) have a lot to gain from an agile approach. The stand out benefits include greater autonomy and control over their work, less micro-management, regular tangible results, greater teamwork and collaboration and more direct involvement with the people who they are building the product for. As one person told me: “I never before had the chance to meet our users let alone hear them tell me how useful the work I had been doing was for them…this is motivator for me and something I want all the time now”.
Yet these benefits come at a price. Every member of the team now must take responsibility to manage themselves – if they see someone in the team acting up or not pulling their weight, then they have a responsibility to call it out. They will probably have to work outside of their job description, field of expertise and comfort zone in order to do what needs to be done for the team to be successful. They need to be prepared to receive feedback on their work on a regular basis, and collaborate towards customer satisfaction without the comfort of defined requirements. They must take on the challenging tasks of evolving a design, an infrastructure and an architecture without a complete set of requirements and in the knowledge that this will all change as the project progresses. All of this is really difficult but, for most teams, it is a price well worth paying. Many teams, however, are unaware of this trade off – they are sold on the nice aspects of agile. It is these teams that do agile badly – something it is all too easy to do as the discipline and effort required to do agile really well is surprisingly high.
On the other hand though, management are often unaware of the impacts that “going agile” will have on them and how their behaviours can send mixed messages that can kill off an agile transformation that has such promise. They want the greater visibility that regular deliveries of product increments gives them and the power of self-organising, pro-active teams is an alluring one too. The ability to change direction, a reduced time to market and greater visibility of waste are all powerful drivers for management and reasons to “adopt agile”. But what are the costs to management of “going agile”? Well first of all they need to address the legacy organisation – the processes, paperwork and people (more roles than actually the individuals filling them) that are no longer required in a leaner way of working. The legacy organisation was created for an old way of working and it is not only unnecessary in the “new world” but actually hinders its progress.
Then there is their own mindset which often involves letting go of their insecurities and “putting their money where their mouth is” when it comes to trusting the teams. There is no getting away from the fact that agile methods (and more importantly the agile mindset) places a high emphasis on trusting people. And the only way you can make someone trustworthy is to trust them. Saying that you want self-organising teams is one thing but creating an environment where people (who often have had years of being told what to do) feel able to step up, offer suggestions and take responsibility is something else. This requires not only the explicit message that this is what we want but also making sure that there are no mixed messages to contradict this. Asking a team to self-organise but then saying “not like that” is going to kill off not only the prospect of self-organisation and team pro-activity in the future but also kill off morale and faith in the larger agile transformation.
Will teams get it wrong? Of course they will, just like kids get it wrong when they are faced with the opportunity to make decisions for themselves. But this is an important part of the development of not only an agile team but an agile organisation. It is crucial that teams are supported in removing waste, in deciding how to manage themselves. Most organisations are unaware of the implications of “this agile thing” and they are usually much wider and deeper than first thought. It takes great courage to take that first step but even greater courage to keep going once you encounter those challenges. Make sure you continue to hold the benefits that you are likely to obtain up high as a reminder that this discomfort, and the discipline that goes with it, is worthwhile.