Thursday, 21 July 2016

Making Luck

This week I've accepted a permanent role at River, the company that I've been consulting with since February. The title of the role is immaterial - what matters is that I'll be helping both Product Owners and Testers to develop themselves and their functions within the company.

I'd like to share the story about how I came to working in River. I apologise if it comes across as self-indulgent - I think there are some valuable lessons there for those focussing on their careers in demonstrating the value of the effort that we put into our professional development over time.

An Eventful Day

The events of my day on 18th January ran something like this:-

  • 8:00am - at train station as normal ready for work
  • 8:05 am - receive calendar invitation on my phone for "all company" meeting that morning. Predict redundancies.
  • 8:30am - get to work.
  • 10:00am - discover am being made redundant along with a number of colleagues
  • 11:15 am - in pub
  • 1:00pm - in Cafe eating disappointing sausage sandwich in pathetic attempt to soak up copious amounts of beer before going home
  • Afternoon with family sobering up
  • 7:00pm - At Cheltenham Geek Nights. Cheltenham Geek Nights is an development community event run in Cheltenham by Tom Howlett (@diaryofscrum). I'd become aware of it through communicating with Tom previously when he approached me to do a talk on Testing Big Data in Agile. The speaker on this occasion was David Evans. I had already been looking forward to taking the opportunity to catch up with David having benefited from his expertise in the past and maintained an amicable relationship since. After the events of the day I was particularly interested in his insight on the roles and team structures he was seeing develop through his work consulting in the fields of Agile Testing and Specification by Example.
  • 9:30pm - back in pub
  • 11:00pm - taxi home. Speaking to Tom and David that evening was the perfect antidote to my bad news and I ended the day on an optimistic note.
  • 5:00am - awake with hangover and worrying about future

During the next few days I was genuinely overwhelmed with the number of people who got in touch with me. Some contacted me just to wish me good luck, or to ask me what had happened. Others provided suggestions of possible roles or options available to me, and some even came in with direct offers of work. I can't overstate how valuable this communication was to me. Whether or not I followed up on every suggestion, the fact that so many people got in touch was hugely reassuring in an uncertain time and to those folks who got in touch - I can't thank you enough.

One of the options that I did follow up on was when Tom suggested a possible contract Product Owner role at a company he was consulting at. It turned out that he was looking to create a team of Product Owners to help to alleviate some of the challenges that they were facing in their Agile development adoption. This was exactly the kind of option that I was looking for - something that would allow me to get back to work quickly, in a very different organisation and provide some time for me to decide on a next long term move.

Landed on Your Feet

Over the ensuing weeks and months I've found that the nature of challenges presented in a very different work context have been refreshing. The experiences of working with such an amazing, close knit team at RainStor provide a constant reminder of how effective teams can be if you

  • Structure them with the right combinations of skills and experience levels
  • Allow them sufficient stability of members and technologies to confidently establish and meet release forecasts
  • Provide sufficient trust combined with flexibility over the delivered solution to fully engage the team in the creative process Having this knowledge is a powerful tool in looking where to focus to help add value in a new company.

When I've told people about my new position in a local organisation, a number have used a phrase like

'You've landed on your feet'.

This is an interesting one, as it implies a strong element of luck. Of course I would agree that the timing was somewhat fortuitous, however let's look at some of the events that led up to the situation:-

  • The contract role was suggested to me by Tom based on a conversation at a community event that I attended
  • The reason that I knew about the event was because of this blog and talks I'd done in the Agile/Testing communities had prompted Tom to ask me to speak at the event in the past
  • The reason that I specifically attended the event that day was because there were people there who I already knew from the software community
  • The reason that Tom felt confident in suggesting the role to me was because he had read my work, spoken to me personally, engaged me to do a talk and was confident in my abilities

This option, and other suggestions or offers that folks so kindly extended, made me really thankful for the time that I'd taken to invest in being an active member of my professional community.

The Slight Edge

I recently started reading the Slight Edge by Jeff Olsen. Whilst I'm not big on self help books, this one had been recommended to me and the concept interested me. One of the principles that the author presents in his book is the idea that it is not one-off Herculean effort but repeated incremental effort over time yields long term success. Many trends in modern society revolve around the concept of instant gratification: the lottery win, the talent competition, the lean start up overnight success. What Olsen suggests is that, far more reliable success comes from incremental effort to improve, applied over time. It comes from sticking with something even if it doesn't yield immediate results.

I've been writing a blog now for 6 years, and hit my 100th post last year, and I'd like to think that the effort that I've put in to blogging, attending meetups, making connections and generally working to improve myself through sharing ideas with others made that possible. If I hadn't invested that time over those years , then I wouldn't have interacted with so many different folks and would not have built a network of contacts and a body of work that allowed other professionals to place their faith in me.

Writing a blog is not easy, particularly when you have a busy job and a young family. For example during the first months of writing a software testing blog I had no idea whether anyone at all was reading it - it was 8 months and 10 posts before I got my first tweet share. In later years, particularly during the 'creativity vacuum' that comes when your small company is taken over by a large multinational, I have a couple of times considered stopping writing. I really started the blog from a desire for validating approaches rather than networking, but it was through redundancy that the realisation came as to just how valuable the effort was in building a great network of contacts to provide opportunities and guidance when needed. It is never nice losing a job involuntarily, yet ironically it was at exactly such a time that the extra effort in committing to something beyond the day job really showed its value.

I'm of the opinion that it is better to commit to one thing and stick with it than take on 5 things and give all of them up weeks later. I've given a specific example of writing here, however there are innumerable other areas where success comes not through moments of inspiration but through perseverance:

  • Keeping on top of emails
  • Keeping a backlog or to-do list up to date
  • Maintaining a sprint/status board
  • Writing unit tests
  • Testing with the right user roles not just admin
  • Adding testability/supportability properties to code
  • Having regular catch ups with team members
  • Diet
  • Exercise
  • Not having a cigarette (10 years so far for me)

The takeaway is that commitment matters here - you don't see the value, or get the power of incremental improvement, unless you stick at something. One of the great powers of the internet, blogs and conferences is that anyone with a great idea can contribute massively to their professional community. Looking at those people who enjoy universal respect amongst the groups that I communicate with, it is the ones that are persistently contributing, always putting in effort and maintaining their commitment that attract the greatest admiration.


Thursday, 30 June 2016

Being Honest

It's safe to say that there has been a fair amount going about in the UK news recently about honesty, or lack thereof, surrounding a certain political event that I'm not going to discuss here. I've always been an honest kind of person. Whether driven through a higher moral compass, fear of getting caught out, or simply a lack of imagination that it doesn't really occur to me to fabricate, even to my own advantage, I'm rarely tempted to resort to fiction to resolve an awkward situation. I had a friend at school who was very different. He would tell me stories that, years later in adulthood, I have discovered were complete hogwash. Like the time that he told me that his cat had killed his neighbours parrot while he was at home alone ...

... a story that I later discovered he'd invented to excuse his missing a homework deadline and had told all of his school friends to reinforce his tale to the teacher. I'm still friends with him (I'm not entirely sure why) and even now every so often he reveals to me the truth behind some absolute porker he told me years before.

It's easy for me to say that honesty is always the best policy, but it doesn't always feel like the best option. A situation that occurs frequently in the working environment that can tempt anyone to stretch the truth, is when we're worried about the status or progress of our work. When this happens it is easy to fall into the trap of thinking that giving the impression of being in a better position than we actually are might satisfy those that we report to for a while, and allow us to catch up or fix the issue.

But you rarely do catch up. The fact that you are in a position where you feel the need to fabricate your progress in the first place must have come about because you're progress is not quite where you, or someone else, would have liked it to be. This will have happened for a very good reason, like the work being more challenging than you thought, which you're not going to change overnight.

Let's look at the potential impact of misrepresenting progress to some important people:-

To The Customer

The more distant the third party the easier to be economic with the truth so the customer is a prime candidate for inventive reporting. Of course you don't want the customer to know things are taking longer than expected, why would you? Perhaps you run the risk of exposing that perhaps your up front estimation processes were, actually well, estimates, and the development is taking slightly longer. Or, even worse, it could involve admitting that you are actually doing some work for, gasp, another customer. If the customer is on the other end of an email or phone then the temptation to give a false impression of progress is ever present.

I'd advise against it. Consider some of the disadvantages that can come down the line:-

  • If you misrepresent progress on a development, and then hit a technical challenge that requires a rethink, or at least some major decision making on the part of the customer, how are you going to broach that conversation when the customer thought that you were already well past making such fundamental decisions?
  • Also if you misrepresent progress then it diminishes your ability to negotiate scope as the development progresses. Better to be open early and often, at least then you can negotiate openly around what you are delivering.
  • If you misrepresent the level of rigour in your testing, this can really backfire. I've worked with more than one supplier who has insisted that they were thoroughly testing what was delivered. I therefore focussed my own testing on the integration points and relied heavily on their testing of their own features. On discovering a high number of issues in these features this immediately called into question either their competence, or their honesty. In subsequent developments I actually had to negotiate for the supplier to deliver the software slower to give adequate time for them to test it.
  • If you misrepresent the severity of an issue that has been discovered, then it is hard to justify taking time in testing a fix and therefore you place pressure on yourself to push out untested bug fixes. When I was running both support and testing I had to negotiate a reasonable delay on delivering changes to the customer a number of times. This was done on the basis that we had just found an issue and the last thing we wanted to do was rush in a change and introduce more issues, so we needed to take the time to do some thorough testing around the fix. Under-playing the severity of an issue makes such negotiations more difficult.

In the drive for 'responsiveness' to please the customer it's easy to lose sight of the value of honesty, however responsiveness in communication can deliver a huge amount of value without necessarily the need for the same responsiveness in scheduling or delivery. In my experience customers appreciate knowing where they stand, even if it is not necessarily where they want to be. They also find it hard to argue if you are putting effort into ensuring improvements to the quality of the end product you're delivering to them. Even with the awkward subject of other customers, software customers want to be buying from a stable supplier, so your having other customers is something that they should view in a positive light (though not all will). Showing respect for those other customers and being seen to uphold your commitments to them will reinforce your integrity as a supplier. If on the other hand, you are seen to default on your commitments just to please the customer in front of you, they are going to be under no illusions that they'll receive the same treatment once they're not in front of you.

To your colleagues

Misleading your progress to colleagues seems like a strange thing to do, yet I have encountered situations where this has happened when individuals are struggling or making mistakes.

  • On one specific occasion I can remember a tester working in an agile team felt that he wasn't keeping up with the user stories he was supposed to be picking up. Instead of admitting this, he misrepresented the level of testing that had been done on the user stories that he was working on, to the extent that I thought they were completed. I then reported to other teams in the business that they could make plans on the basis of that work being completed. On examination I discovered the status of the tests had been misreported and what had been done gave us little or confidence in those features. The result was me having to drop my other work in order to devote time to testing those items so that we could fulfil my commitment to the other teams. Had the tester been honest with me about his status, I wouldn't have misreported our progress and the problem simply wouldn't have occurred.
  • Similarly, if an individual has made a mistake then the temptation can be to try to cover it up. One lesson that I personally have had to learn over and over again, is that it is rarely as bad as you think, and getting a mistake out in the open is empowering. Keeping mistakes concealed, conversely, accumulates stress on the individual, and anyone else taking the responsibility to resolve a difficult situation will not appreciate it if those who have made mistakes hide the truth in an attempt to conceal their errors.

Being honest with your colleagues goes beyond operational benefit. In the world of self-managing teams and a move away from strict hierarchical control and micro-managements, creating a community of trust with your colleagues is essential. If you're co-workers feel that they can't trust your status reports in terms of what you have developed or tested, then they will likely resort to committing effort to double checking your work, at the expense of progressing their own, a situation which at best will result in ill-feeling and at worst could blow up into serious confrontation.

To management

Senior managers tend to be more removed from the immediate development and testing work and so often don't have the low level view of the software products to really make a good assessment of status. That's what they rely on you for, particularly the testers. It's therefore relatively easy to give a false impression of progress to senior management, but this can have dire consequences for them, your colleagues or you.

  • Something I've seen more than once is when a senior developer or architect takes it upon themselves to develop a pet project that they put together as they see value in it for the business and want to impress with their ingenuity. Much of this type of development has gone on outside of the core development processes and has had little or no formal testing. The software is presented to C-level executives as release ready in all but requiring a "rubber stamp" sign off from the testing team ( I have actually had a CEO say to me "now all we have to do is test it - right?" in relation to just such a development ). The result can be a lot of stress placed on colleagues who have to take this work and try to test it or support it to the level expected of them. The sad thing here is that there's no need to keep such projects away from others. The best chance of success of any new endeavour is to bring others on board with it and get them behind it, being honest about what you don't have the time or skills to do, such as the testing. If you are honest about getting others on board and giving them the credit for the contribution they make, they'll be more than happy to report your contribution to senior management and give you the credit that you are looking for.

  • Another route for misleading management comes from the manner by which we communicate with them. If we're communicating via metrics or aggregated reports and metrics then for some reason it becomes easier to massage the truth. Now I've admitted that that I strive for honesty, however I'm not a saint and admit that I have in the past been tempted to tweaking metrics and measurements to make a situation look better. For some reason the level of guilt around gaming metrics to give a positive spin on things is far greater than it would be doing the equivalent in an open conversation. If ever there was a need for an open and communicative relationship with senior management, this is one. Inevitably the truth will out and no metrics in the world can the reality of the status of development. If you don't realistically appraise management of the status of development then someone else will, and if that person ends up being frustrated customer who is suffering delays or poor quality, then the outcome will be far worse than the awkward conversation you could have had around more realistic metrics.

Honestly, Honesty - it's not that hard

Looking back at some of the most challenging times of my career so far, many of the biggest difficulties have been the direct result of someone not being open an honest as to the status of their work. The problem with taking a misleading line in relation to work is that, once done, it is so easy to escalate and compound your problems by telling more lies. Taking ownership of difficult situations, getting the problem out in to the open and driving through to a conclusion is an empowering activity that actually helps with personal development and builds experience and character. Whether in software development/testing, management or support - there isn't a successful technical leader out there who hasn't at some point had to tackle a late project, missed deadline or simple mistake head on and face the consequences.

Coming into a new organisation, as I have done this year, has been a difficult journey for me given the level of knowledge that I had developed around my team and processes in my former role. I've inevitably made some mistakes as I've worked to understand the culture and processes of a new organisation with a very different technology stack and customer base. Maintaining a level of openness around what I'm doing and any mistakes has hopefully allowed the same openness in communication to me and encouraged others to be honest with me about their work - as honesty is a two-way thing. By being honest with colleagues, management and customers I believe that we not only uphold our own principles but also encourage others to do the same.


Monday, 23 May 2016

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:-

  1. 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.
  2. 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.
  3. I was getting ready to turn 40 - that's out of the way now, back to business, nothing to see here
  4. 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.