Rivers and Streams

After a productive start to the year in terms of writing, I realise that I didn't manage to post anything in April. Looking back I can identify four reasons for this:-

The first is that I was working on an article for the Testing Circus Magazine on Agile Test strategy. If you haven't done so please take a look at the April Edition of Testing Circus - my article is in there along with many interesting articles and interviews.
The second is that I was responding to an request for an interview from the folks at A1QA blog. I haven't done an interview before but in the spirit of having moved on from a long term role earlier in the year in the optimistic glow of change I said yes when asked this time. My interview hasn't appeared at the time of writing this post but I hope that it will be there soon. In the meantime there are some great interviews with testing experts to read.
I was getting ready to turn 40 - that's out of the way now, back to business, nothing to see here
I had been at my current engagement just long enough to get really busy

In relation to this last one, I now know that the lead time on getting really busy in a new role is about 2 months. Up until that time there's a sufficient level of inexperience of the context and isolation of your activities from the day-to-day work to keep your inbox blissfully quiet. Once two months are up then people start relating your presence with actual useful activity and the honeymoon period is over, you're busy.

The work that I've been doing has been setting up Product Owner and Testing functions at a company called River. The name River is a really interesting one for a company involved in software development, as the nature of rivers has some really interesting parallels with work - particularly how the nature of our activity in work reflects on our productivity. Anyone with a strong dislike of analogy should probably stop reading now.

The fast flowing river?

If I asked you to think of a fast flowing river you may be inclined to think of something like this

The rushing white water clearly moving very quickly as it cascades over the rocks. The interesting thing is that, whilst this river might look fast, a huge amount of the energy is not going into moving the water downstream. There are eddies and currents and energy is being used moving the water in many different directions that aren't always downstream. The net result is that, despite the steep gradient that it is moving down, the actual average velocity of the water downstream is slow.

What I've found both in my own personal work, and the teams that I've led, is that in a similar way it is possible to expend a huge amount of energy being busy and filling the working day, without making much progress towards your goals. An apparently busy individual or team can actually be making slow progress if much of that activity is directed at overcoming friction. I'm not talking about the friction of ill-feeling between employees here. What I'm talking about is the friction of energy expended on activities that unnecessarily distract from progressing work to the benefit of the organisation. Whilst organisational friction comes in too many forms to consider here, a lot of friction that can massively impact velocity is relatively straightforward in nature and easily avoided. Some 'velocity killing' sources of friction that I've encountered are both obvious, and easy to reduce, however still affect many companies and teams:

regular disruptions or distractions
A good collaborative working environment is a boost to motivation and productivity, however too many distractions reduce the ability of individuals to take the time to focus on their work. Likewise regular ad-hoc requests coming into a team can disrupt the flow of work repeatedly, causing friction through context switching between tasks.
cutting corners
Nothing reduces velocity like, say, bad code, and nothing generates bad code like cutting corners. I've seen a number of occasions where the decision to push ahead with a product that hadn't been developed with any thought to maintainability or sensible decoupling/separation of concerns has been made to save time. The inevitable result is that any team who has to support, maintain or extend that product later ends up getting slower and slower as they struggle to understand the structure of the code and how to safely change it. As a general rule, unless what you are working on is a temporary one time activity, any corner that you cut now will result in significantly harder work at some time in the future.
Handing over poor quality or incomplete work
I can remember James Lyndsay teaching me once that Exploratory Testing was not an appropriate approach if the software was too poor in quality. My immediate thought was that this was an ideal time to explore as you would find loads of bugs - however on reflection his point was sound. Finding bugs is time consuming and disruptive - as Michael Bolton so clearly explains in this post and so making any kind of testing progress through a system that is awash with problems is going to be an exercise in being very busy but making little progress, and generating a lot of friction between developer and tester in finding and fixing the issues. The developer-tester interface is just one where pushing work before it's ready causes friction and slows everyone down. Similarly the Product Owner to developer interface suffers if the PO prioritises work into the team that is not ready. As I wrote in "A Replace-Holder for a Conversation" I'm a great believer in adding acceptance criteria to the story at the point that it's picked up. On a few occasions, however, I have received/delivered stories into a sprint where, on elaboration, it became clear that we didn't have a clear enough idea on the value being delivered and the result was delay or, worse, misdirected effort.
Repeating the same conversations
This one is a real progress killer. After working on a product for some time, there are stock conversations around that product that certain individuals will revert to given any significant conversational time spent discussing features or architecture. No matter what you are trying to achieve it would all have been a lot easier if we'd have re-architected the whole system in the way that someone wanted to do a number of years ago, or if we just went back to having test phases after development had completed. Poring over the decisions that were made years ago can't help now and reverting to conversations of this nature in every meeting massively increases the friction of the process. Inevitably someone will at some point have to make a pragmatic decision that does not involve the re-architecture of the entire product stack, or reverting back to waterfall, and thirty minutes of everyone's time could have been saved in unnecessary conversation.

The slow flowing river?

By contrast, if I asked you to think of a slow flowing river you might conjure up images like this

We may think of such rivers in terms such as 'lazy' and 'placid', however the fact is that the average velocity of water downstream of such a river is actually greater than an apparently fast mountain stream. This efficiency comes about through the massively reduced friction on the water travelling downstream. Despite the fact that the gradient is less, the efficiency gained means that overall velocity is faster, and the fastest point is the centre of the River where the water is furthest from the friction of the sides.

It seems sensible to strive to minimise friction, yet we know that simply handing development teams a set of requirements and leaving them alone for 6 months is not an appropriate solution here. How do we maintain the potentially conflicting goals of minimising friction whilst also having regular collaboration, providing feedback and generally communicating regularly. Here are some ideas:-

Don't distract people if they're trying to concentrate
If you want a social chat - see who is in the kitchen. If you have an issue, ask yourself if it is essential that you speak to the person right then, or could it wait? I'm personally quite bad at distracting people immediately on issues that could possibly wait, something that I've become more aware of through writing this post. I don't want to imply here that teams should work without conversation, a healthy team dynamic with strong social bonds is really important, however if one person is distracting another who is trying to focus then that not only introduces friction but also can erode team goodwill in that people will start to resent the distractions.
Keep it to yourself
If every time you find a bug, or an email annoys you, you announce it to everyone within earshot then chances are you're the work friction equivalent of a boulder in the river, keep it to yourself until a natural break occurs and you can catch up with people then. I've seen whole teams slowed dramatically through the fact that an individual would announce each small thing that annoyed them through the day.
Avoid ad-hoc tasks
If you have a task that might mean a context switch for someone e.g. a bug to investigate or an emergent task, wait for them to finish what they are working on, or raise up the need to do it in a stand-up so that the team can plan it in. Managers are notoriously guilty here of wandering in and disrupting teams with ad-hoc requests that derail them from their scheduled activities - having a way of capturing/tracking ad-hoc requests is a useful tool for teams who suffer heavily here. Again I like to capture this information on a team white-board and clearly mark any impacted tasks as 'Paused' whilst the ad-hoc task is addressed.
Have timely conversations to confirm assumptions.
Identifying necessary conversations in a stand-up meeting and planning them into the day is a good way of avoiding blocks on progress whilst reducing the friction of trying to get people together ad-hoc. I like to see important conversations either booked in calendars or at least identified and written up e.g. on a scrum board so that everyone is aware of when they need to catch up, thereby avoiding the friction of people walking round the office trying to round up the necessary individuals, like children on a playground looking for volunteers to play "army" (the ultimate demonstration of friction in that it typically lasted the entire lunch-break and never actually left any time for playing army - see number 8 here).
Don't rush jobs that others will pick up.
Maintain your standards and defer work if necessary. You being busy is not an excuse to multiply the efforts required of the person who has to pick up your stuff, whether that be poorly understood stories or badly tested features, no-one is going to thank you for 'getting the job done' if the result is someone else having to do twice as much.
Take a break
One of the most interesting findings of this study referenced in this post, aside from the fact that someone thought that watching netflix and drinking vodka constituted work, is that taking regular breaks actually improves productivity.

Small changes yield big benefits

A colleague of mine was explaining to me this week how, off the back of reading Jeff Pattons "User Story Mapping", that it was making him look differently not only at his work but also his own activities. He'd really taken on board the idea of reducing friction across his life to the point of correlating his visits to the gym with the length of his commute so he didn't waste time in busier traffic, when on other days he could reduce the round trip time by going earlier. By looking at the friction of every day activities there are huge gains to be made in productivity.

Having worked with teams that did have predictable, organised processes where we had minimised the friction in our own processes as much as possible, I have found that it is easier to both

Identify and isolate the impact of higher level decisions
Work through issues and still maintain a stable velocity and predictable level of rigour

when you have a smoothly running team or department. Sometimes it's so easy to attribute problems to higher level organisational problems and major decisions that it's easy to overlook simple changes closer to home that could yield huge benefits. No company, individual or organisation gets it right every time, but by reducing the friction in your own individual and team activities we can ensure that we're not the limiting factor in achieving our collective goals.