September 3rd, 2013

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.

Tags:

Agile / Agile Adoption / Management / Self-organisation / Teams

0 comments | view comments | add comment

 

January 13th, 2012

Are you an ADAPTIVE ScrumMaster?

As a Certified Scrum Coach (CSC) I do a lot of work with ScrumMasters in organisations who are looking to find new ways to engage their teams and move their Scrum implementations forward past the basic Scrum framework. When Coaching ScrumMasters I recommend they try to become more ADAPTIVE. As you might have guessed from the fact that the word is capitalised, it is an acronym for a number of behaviours. Following on from my blog post about ScrumMasters getting RE-TRAINED, an ADAPTIVE ScrumMaster: Helps the team to hold themselves ACCOUNTABLE Leads the team to DIVERGE before they converge Helps the team take ACTION to improve Asks POWERFUL questions to make them think about the root cause of their challenge Encourages the team to TRY someth... read more

 

Category:

Games / Scrum / scrum master

Tags:

Accountability / Adaptive / Advanced / Agile Adoption / Asm / Divergence / Elephant / Experimentation / Involvement / Scrum / Scrummaster / Training / Visibility

3 comments | view comments | add comment

 

November 20th, 2011

The whole Scrum vs Kanban thing

I'm pretty bad at twitter. I am terrible at getting my thoughts across as intended in 144 characters and the more I try sometimes the worse it gets. So I am writing this as a response to the twitter debate that ensued after Jim Coplien's latest post. My first view upon reading this was that, considering Jim's normally controversy-inviting style, it was well-written and aligned with a number of things I have been thinking about recently. However, it left me incredibly conflicted primarily because I want to be someone who is being positive and constructive to everything that is trying to help make organisations more successful through agility. This is why Jean Tabakas "Community of Thinkers" post resonated with me. I do feel an urgent need to... read more

 

Category:

Agile / Scrum

Tags:

Agile / Community / Conflict / Kanban / Scrum / Timeboxing

3 comments | view comments | add comment