The trouble with success

This week the first sprint of the pilot transition at our new client was completed successfully. Kudos to the team, if they learned as much about scrum as I learned about coaching then things will turn out alright!

Before embarking on this transition I had imagined (in my wisdom!) that teams transitioning to scrum (or any flavour of agile) would generally be coming from either chaos or toxic and petrified waterfall, so that anybody in an executive role (as opposed to management or admin) would be only too happy to try something new. 

But what about a start situation wherein success is the problem, so to speak? The team we are working with is part of a young company which has grown so rapidly in the last twelve months that it's quite literally bursting at the seams; space in the office is at an absolute premium.

Initially I thought that this would make the job of coaching a transition to agile that bit easier – especially when it became apparent that the existing processes had evolved such that they included some obviously agile elements already. For example, scope was derived from goals via a series of workshops involving the client, this scoping phase was followed by a definition phase, which included (high level) requirements gathering, and subsequent to that, a cycle of design/development iterations was entered into. Finally there was an acceptance & delivery phase whereby a portion of the team would be on-site at the client. Releases tended to fall into the three to six month range and teams were organised by client/project and not by function.

Sure it would be just be a case of crossing the t's and dotting the i's and they would be equipped to deal with phenomenal growth for years to come. If nothing else, in the past two weeks I've learned that naiveté is a good learning stance!

To start with, there is the 80/20 rule: The last 20% of any job will cost 80% of the effort. To take one example from the list above – a feature team is not yet a feature team simply by its comprising all the skills required to deliver a feature; if responsibilities are still strictly demarcated by role then you retain silos, queues and handoff, and it remains exceedingly difficult to genuinely work as a team according to priority (even with the best will in the world).

So, the first sprint has been completed and all the stories have been delivered, in fact, stories were added during the sprint and still the entire scope was delivered. The burndown flat-lined all the way to the second last day of the sprint however and on that last day there was a sheer drop all the way to zero – a typical indicator that the sprint was in fact a mini-waterfall. This posed a challenge for me in setting up the retrospective. I wanted to ensure that the team enjoyed its success and that the people took the time to recognise their achievement, yet I felt it was imperative to discuss the risks (getting a lot of work done without delivering anything) inherent in the approach that had led to the burndown profile described.

I started by focussing explicitly on the successful delivery and then defined the retrospective goal as generating at least one improvement story (for inclusion in the next sprint backlog) which would help the team along the road to delivering sprint scope story by completed story. As you might expect, resistance to the suggestion that there had been anything 'wrong' was strong. Discussion was energetic and I was repeatedly faced with 'the way things are done here'.

“The way things are done here” is a notoriously difficult notion to challenge at the best of times - scrum is incomplete and adaptive, every implementation of scrum is unique and it is most certainly so that some things are best done in a particular way in a particular situation. That said, much of “the way things are done here” during the early stages of a transition is just general resistance to change.

If most of the people are unhappy and the projects are generally disastrous then “the way things are done here” can be rejected relatively easily as obviously the wrong way to do things. If however your team is motivated and successful such that projects are generally delivered on time (even if stress levels do sky-rocket as delivery nears) dealing with the “way things are done here” requires careful thought, concentrated listening and skilled discussion.

I'm working on it!