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!

A commuter's rant

This morning was one of those mornings; when the alarm clock went off, I felt like throwing it against the wall. Instead I turned it off and lay back down so that I could ease into the day. I promptly fell back to sleep and woke with an even bigger start some twenty minutes later. I let my colleagues know that I would be late.

As we know random events cluster – today they clustered at a railway near me!

I caught a later train and as it rolled to a halt at its first port of call, the conductor announced that we would go no further as there had been a crash further up the line. The advice proffered, which I duly took, was to return to the station from which we had just come and follow an alternate route. Half an hour after I had left my local train station I was back there waiting on an overcrowded platform for the next train to Den Haag. As the scheduled departure time came and went without any sign of our train, and the crowd of unhappy commuters continued to swell, it was announced that there was a problem with a switch near one of the main stations on our route. I rang the office and let them know that I would be working from home...

My commute normally consists of a ten to twelve minute walk, a train journey of some 46 minutes and a tram ride of not quite 15 minutes. Most days I can get to work in about 90 minutes. The journey home is less predictable because it starts with a tram journey – tram schedules are not strict – and can take up to, and on the odd occasion more than, two hours (the difference usually made up almost entirely of waiting).

Why don't I drive? Well, I don't have (nor have I ever had) a driver's licence. Besides that pertinent impediment, there are the issues of gridlock, congestion, pollution and carbon emissions. But I will readily admit that if the only problem were gridlock I would without doubt have converted to the car long ago. Travelling by car is generally quicker and much more fault tolerant - if you step into your car 5 minutes late at the end of the day, chances are you will be home 5 minutes later than normal. If you leave the office 5 minutes late on the way to catch a train, your journey home may end up being extended by a half an hour or more.

If even well organised and largely dependable public transport (as the Dutch system surely is) results in significant delays at least a few times a month and the freedom that travel by car offers all too often equates to the freedom to sit idle in a traffic jam, what can we do to keep things moving?

There are a few obvious stop gap measures; teleworking may help somewhat in combating congestion and should be considered a useful tool but its efficacy is limited as teleworking is detrimental to team work. Flexible working hours could reduce pressure on transport systems during peak hours but any potential tends to be nullified by the demands of the rest of our lives (opening hours for crèche, school etc. may not be flexible) and here again, the issues that flexible hours raise when working in a team are not trivial. Carpooling is another option but it shares many of the drawbacks of public transport and can be socially taxing to boot.

Traffic needs to flow, maybe there are answers to be found in queueing theory. Take my journey as sketched above; I tend to leave myself  13 or 14 minutes to get to the station in the morning even though I know it generally takes around 10 minutes to walk the short distance required. I have to build in slack – if I aim at arriving on the platform as the train pulls in, an extra long wait at a traffic light might be the difference between happily catching the train and being left on the platform panting and cursing under my breath as I fumble for my phone, my connection riding into the distance. The greater the potential for variation in my journey to the station the more slack I'm likely to build in to allow for the unforeseen. Hand-offs are expensive.

More frequent trains would alleviate my problem somewhat – I wouldn't be as worried about missing a train if I could catch another less than 5 minutes later. The rail-road has limited capacity however and a large increase in the number of trains is not easily realised – unless the trains were significantly shorter on average (smaller batches). Thereafter cycle cost needs to be considered; the ratio of manpower & material to customer-kilometres would limit the extent to which batch sizes could be reduced.

If we were to remove hand-off and radically minimise batch size, say to one traveller, would we not simply arrive at travel by car? Yes. But. We still need to consider WIP - Work In Progress; allowing your WIP to rise above certain levels will be detrimental to throughput, alternatively; maximising the use of capacity (efficiency) will, after a certain threshold, reduce flow. If you get out on to the motorway on time in the morning you can whiz on through to your destination. If you're that little bit later, the road is chock-a-block and although capacity is being used efficiently (no. of cars per m² of road), you will not be going anywhere in a hurry.

In short, if we view travel by public transport as the waterfall option (silos, hand-off, long queues, large batches) and travel by car (as we know it) as the chaos or cowboy option, does that offer up any agile solutions to the traffic problems of the 21^st century? Possibly. If there were a system put in place to ensure that the capacity of the motorway was never utilised beyond around 70%, the issue of gridlock could be so atomised as to no longer exist. Cars would be allowed onto the motorway via many slipways, managed centrally by a  control system of traffic lights which would monitor and manipulate (motorway) utilisation, queue length (on the slipways) and batch size (entering traffic). In that way the motorway could actively pull traffic as opposed to playing the proverbial gullet, packed so tight that it can only choke...

To complete the agile/lean allegory; there is even evidence that self-organising traffic is the safest, although I must admit that I'm not sure I'd like to be the one testing that hypothesis on a high-speed motorway.

The power of play

These days, more a coach than a player, I've been thinking not only about scrum, agile and all the rest but how best to communicate on these topics and how best to generate and/or impart knowledge generally. The power of scrum lies in self-organisation and that complicates the coaching role; even if it were possible, there is no value in telling your team from moment to moment how they should tackle the challenges they will face along the way – you need to get people on the right track and help them develop whatever skills or practices are necessary to stay on that path.

In this regard I am beginning to understand the potential power of play. For instance, Innovation Games can be a powerful tool in getting those mental cogs a-grinding. The sail boat (variation on the speed boat) exercise can be used both for envisioning risks & leverage at the start of a project and as a tool to facilitate retrospectives. Formulating an elevator pitch or designing a product box are also great ways to generate collective focus and get the creative juices flowing.

In developing my coaching skills (and our service generally) I am lucky to be able to interface with a product development group here at our own company; the Qafé team. If I want to try out any ideas that I come across, and the Qafé team and I can identify some reciprocal advantage, then we collaborate accordingly. For instance, having read Derby & Larsen's excellent Agile Retrospectives, I asked the team if I could facilitate their sprint retrospectives for a set period. I gained through practical experience and the team gained through the generally refreshing approach to retrospectives.

We (Wouter and I) also 'tested' our user story (splitting) workshop on the Qafé team. Apart from all the excellent feedback that we got on the workshop itself we also learned that the Qafé team was having a problem relating to potential customers. Strange as it may seem, it is not at all unusual that developers do not explicitly think about who their users might be and what they might expect from the software being built. I decided to run a pared down version of Jonathan Rasmusson's Inception Deck exercise – even though Qafé was long past inception, in fact it is already in production and about to take off in a big way, more of that in a moment – to focus the development team's mind on the why of their daily what.

The inception deck is a technique for envisioning projects which comprises, among other things, several popular innovation games. Some elements of the inception deck were not applicable given the timing of our exercise but in a little under 2 and a half hours we went through Why are we here?, Create an elevator pitch, Design a product box, Show solution and What keeps us up at night? It proved to be a very valuable exercise and thereafter the team was generally much more focussed on who they were building for and why.

Some weeks later the company CEO arrived in the team room with good news and a serious challenge. Several large integrators had voiced an interest in Qafé and had undertaken to invest in some training and, assuming the product matched the potential of the idea behind it, to add Qafé to their list of supported/preferred development frameworks for enterprise systems. “But,” warned the CEO, “realise that this is make or break, if these guys don't like the system, that's it, you won't get another chance and the bad publicity will kill the product before it takes off. How confident are you that the product is ready, that it's stable enough?”.

The answer was a less than resounding “Quite”.

Don't get me wrong; this team is confident that they have a good product, they know that it's well conceived, designed and executed. The problem lies in the limited feedback they have been able to generate up until now – several enterprise applications have been built (by a sister organisation) using Qafé, each one resulting in invaluable feedback in the form of bug reports, feature requests etc. but the team might have been more comfortable with one or two more implementations under their belt before being faced with such a make or break opportunity.

The PO jokingly recalled the inception deck exercise, “Do you still wonder what keeps us up at night?” he asked of me. Suddenly inspired, he instructed the team to think on what would keep them up at night in the specific context of the news they had just heard. At the following planning meeting, with a focus on the release to the big vendors, the team detailed what their greatest concerns were. These were then collated and prioritised. Starting at the top of the list the team translated their concerns into actions and so determined, in cooperation with the PO, what their product backlog should be for the coming period. Sprints were reduced from 2 weeks to 1 and the team has gone about methodically addressing and eliminating the risks identified. 

Confidence has soared.