Sunday, 17 December 2017

Textual description of firstImageUrl

Impersonal Development

It is a rare and privileged situation to find oneself in when the values that the company that you work for promote, and even sell, are consistent with things that you yourself feel passionate about. Fortunately for me this is just the situation that I find myself in when it comes to personal development. Working for a company that promotes employee engagement and intrinsic motivation is a natural home for someone like me who believes that giving people rewarding jobs is the most important thing that a company typically does.

Losing the personal touch

A couple of years ago I underwent the strange experience of having the small company that I knew and loved taken over by a major multinational. One of the requirements of that acquisition was that we move to adopt the personal development structure that was a standard for that enterprise. In summary this involved

  • Identifying the core competencies that were appropriate for each role (at the time I looked after testing, support and technical authoring)
  • Scoring each person against each of these competencies based on a supposedly objective scoring structure

This approach ran contrary to the one that I'd adopted up to that point and it took some effort to come up with a way of meeting the requirements without sacrificing the principles that I had been working to up to that point.

But it was still a sacrifice.

Personal, Really?

I don't know anyone the same as me. I know many people with similar skills in certain areas, better in some, less capable in others. Inevitably when compared to any individuals we find that they have deep expertise in some things at which we would consider ourselves complete novices, even when we are involved in very similar roles. It has always seemed rather unnatural to me then that, in looking at personal development so many organisations look to measure people based on a set of 'core competencies' for that role, and nothing else. My natural inclination for personal development is that it should be a bit more … well … personal.

Prior to the acquisition I had taken an 'individual first' approach to personal development. I would work with each member of my team to identify what their personal strengths were, what areas they needed to work on and, most importantly, what their personal goals and aspirations were. Rather than treating each individual as a plug-in resource to mould to a pre-defined shape determined by the role they were employed in, I would look to understand the unique qualities that each person brought to the organisation and how we could best make use of those to make their job and our work as rewarding and productive as possible.

I see this as nothing more than common sense. People are not pluggable resources that are swappable in and out of equivalent positions. Even in the same role different people will adopt different approaches with different outcomes influenced by their strengths, weaknesses, proclivities and biases. This should be something we celebrate and encourage as it promotes diversity and innovation, rather than seeing people's uniqueness as corners that need to be rounded to fit the mould that we have predefined for them.

A new opportunity

I've a painful habit of landing myself responsibilities by opening my big mouth. This is exactly what happened recently at my current company River when looking at personal development. In response to a suggested approach to personal development based on rating people against core competencies I pushed back, warning of the dangers of the 'cookie cutter' approaches I'd seen before and instead ensure we built something oriented around individuals. Somewhat inevitably my intention of proffering an opinion ended up with my being volunteered to help define an approach.

The approach I came up with was oriented around two main principles

  • Capabilities vs Skills
  • Mentors and Coaches

Capabilities over Skills

In terms of terminology I distinguished between capabilities and skills. It seems a little pedantic to differentiate but there's solid reasoning behind it. A person can have skills however if they are not able to apply them to good effect, or share them with others, then they aren't capabilities that benefit others in the business. Someone might be a brilliant coder but if they don't help to coach others and the overall quality of their team code is poor then they are not applying that skill as a strong capability. We wanted to focus not only on building skills, but also in sharing with others where deep skills exist within the business.

To help with defining the level of someone's capability I adopted an interpreted version of the Shu-Ha-Ri learning concept to allow people to assess their stage of learning. The idea is well covered elsewhere such as here by Martin Fowler, so I won't go into details here. In simple terms the concept considers three different stages of learning.

  • Shu - where someone is learning precisely based on one teacher or source of learning ('Learning from others' in our personal development template)
  • Ha - where the student has mastered the basics and extends their learning to assimilate from other sources ('Self sufficient')
  • Ri - where the student is now learning based on their own mastery and practice to innovate on what they have previously learned ('Throw away the rulebook')

I felt that these definitions could help to identity appropriate activities around that capability, for example whether to focus more on learning from others or to consider sharing learning and coaching others as more of a priority.

Mentors and Coaches

The terms mentor and coach are sometimes used interchangeably. The terms can have different meanings in different contexts, however for the purposes of defining a structure for personal development I wanted to clearly differentiate between these roles.

  • Mentors - there is some confusion as to the role of a mentor. I've seen experience reports of organisation where drives to encourage mentoring faltered as they restricted the mentoring relationship to a task based collaboration, failing to promote the one-to-one ongoing relationship that for me is fundamental in a mentoring role. For the purposes of personal development I defined Mentoring as being about developing someone as a whole, looking at their strengths and weakness and understanding their motivations to guide not only their ability for their current role but also the needs of both themselves and the company in the future. Through mentoring we get an understanding of what motivates people and can see opportunities for people to grow themselves and add value, potentially outside their current role.
  • Coaches - coaching in our definition is focussed on building capabilities in specific areas. The role of a coach is to help people to learn or improve in a certain capability. This could be over a very short duration, such as running a training session or workshop, it could be providing advice on resources to improve someone's learning, or it could be a period of longer duration coaching to build someones expertise. One of the goals of the mentor is to identify capabilities that the mentored individual wants to develop and to facilitate the appropriate coaching arrangements to support them.

Showing that we care

Essentially when asking people to engage with their work we are asking them to care. Care, however, is usually reciprocal - more likely to be given when received. Care cannot come from a company, which is after all little more than a collection of assets and contacts, it must come from the people within it. A mentoring arrangement is a great way to engender a relationship based on care and built around personal development that is genuinely focused on each unique person.

I find it rather distasteful when companies treat employees as if they are resources to be moulded to the shape required to fill a predefined gap in that company. I believe that people engage best in teams of they feel that they are making a strong and unique contribution to the work of that team. This isn't just visible in the workplace. From the Greek Gods through Robin Hood's merry men to the 'A-Team', our cultural heritage celebrates variety and the opportunity for unique contribution in team working. Treating everyone in the same role as delivering a comparable, even quantifiable, skills takes away that opportunity. As I have written previously, both in this guest post on Rob Lambert's blog, and in More Agile Testing by Lisa Crisping and Janet Gregory, by combining 'T-shaped' people who possess both solid broad skills and unique deep skills, it is possible to create powerful 'Square-shaped' teams. Such teams comprise a strong general ability with a much greater depth of expertise in a variety of capabilities than a team of carbon-copy 'resources' could offer. Some larger organisations might argue that a more personal approach is only possible in smaller companies, however I know people who've taken similar approaches in larger companies, moving individuals within the business to take on tasks that better fit with their capabilities and interests, with very positive results.

Another factor to consider when developing individuals that I feel should not be ignored is market value. Too often companies focus on people's value within organisations and don't consider their market value and developing their CV and public profile. This is naive - even if you as an employer aren't considering someone's market value you can bet that they are. Better to be open about the need for people to remain current and employable than suppressing these conversations and losing visibility of them. By having open and positive conversations about people's personal development we may well identify desires that take people in unexpected yet beneficial directions for both them and the company, that might otherwise have simply taken them to the exit.

Monday, 13 November 2017

Textual description of firstImageUrl

A Principled Approach to Innovation

One of the greatest unspoken benefits of networking and attending conferences is the sharing of book recommendations. The books that have had the greatest impact on my professional development or direction are often recommendations from peers that have been made during conversations at conferences. In fact I've literally today bought a book that was recommended to me over a pint at the EuroStar conference last week.

It was just such a situation earlier this year when I had the pleasure of John Stevenson's company for some time at the Romanian Testing Conference. He recommended a very easy reading book on innovation and creativity called 'The Myths of Creativity ' by David Burkus. It turned out to be a very useful recommendation indeed, as not only was it a great read, but soon after I found myself taking on the responsibility of running a group promoting innovation across my company.

Progress with Caution

During the summer a lot of the discussion on my work internal social network was around the need to involve more people (specifically across the development teams) in innovation activities. As can often happen when we are foolish enough to take holidays, in my absence the CEO volunteered me to run a group to drive innovation across the company. Whilst it was something of a surprise to come back to, I was very happy to take on this challenge.

At the same time I was wary of creating such a group. In my post on 'The Innovation Silo' I explain many of the challenges that I've seen companies face if innovation is owned by one individual or group at the expense of getting others in the company involved. If not approached carefully then setting up an innovation group in the company would result in just such a silo risking consequences of de-motivation for those not involved. So it was with a mixture of excitement and trepidation that I scheduled the first session of the River Innovation Group (aka "the RIG") and asked for volunteers.

'I'm not a creative type'

During the week before I ran the first session, I was involved in an internal workshop and one of the participants mentioned how she was nervous of volunteering for the innovation group as she wasn't a 'creative type'. This was someone with a wealth of customer experience and a positive approach that I felt would make a great contribution to the invitation group, so this reluctance worried me.

As luck would have it I'd not long before finished reading Burkus's 'Myths of Creativity' based on John's recommendation. I asked if the individual would consider still joining, and recommended the book as one that might give her some reassurance that her contribution would be really valuable. I explained that, in the book, Burkus attacks some of our preconceived ideas around innovation and creativity such as 'creative types' and 'lone innovators' that were the basis of her fears. I was pleased when she agreed to come along.

The conversation got me thinking about the need to establish an understanding, both within the Innovation Group and the wider organisation, about the purpose and nature of the group to avoid misunderstandings around why the group was set up. I decided to use the book as the basis to structure the first session. 'Debunking' some of the myths around innovation would be the perfect way to set the scene for our group and give confidence amongst all the attendees in their ability to make a difference.

The Myths of Creativity

In his book Burkus identifies and challenges ten myths that people often believe when attributing the factors of success in innovations. I suggest reading the book to get a detailed perspective on the 10 myths, however I will try to summarise them here :

  1. Eureka myth. Genuine flashes of inspiration rarely happen. Research has shown that what appear to be 'flashes of insight' are actually the culmination of periods of research followed by stepping back from the problem allowing 'incubation' of the problem and the subconscious mind to make connections.

  2. Breed myth: There is no such thing as a genetically creative person, both personality traits and genetic links have shown no correlation with creativity. The creative label often comes with a role, however we are all able to think creatively around problems.

  3. Originality myth: Innovations are rarely entirely new ideas - more often they are the novel application of existing ideas to new contexts, or the combination of ideas in new ways.

  4. Expert myth: It is not just the experienced experts in a domain that drive innovation. New perspectives and ideas can come as easily from a novel viewpoint.

  5. Incentive myth: Incentives to innovate are extrinsic motivators, whereas it is an intrinsic motivation to solve a problem that yields better results when it comes to innovation.

  6. Lone Creator myth: Edison didn't work alone on the light bulb, he had an entire research company to back him. We often associate the most famous individual with inventions that actually are the result of brilliant team efforts.

  7. Brainstorming myth: Throwing people in a room with post-its and white boards does not provide a good source of creativity. Brainstorming can be effective if it involves the bringing togther of people who have had a chance to think about a subject beforehand, such that the brainstorming brings together their ideas.

  8. Cohesive myth: We can't all get along. Sometimes a healthy level of conflict and disagreement is needed to promote genuine progress on solving problems.

  9. Constraints myth: Constraints don't stifle innovation , actually as long as they are not too restrictive they can promote it as we look to innovate to solve problems within the constraints that we have. Would Tesla's cars be as efficiently designed if Musk had a full production line at his disposal?

  10. Mousetrap myth: Just creating a good product does not guarantee success. The world will not 'beat a path to your door' - you still need to put a huge amount of work into making that idea successful.

In the kickoff session for the RIG I stepped through each myth in turn, and went on to explain what Burkus presents as the true foundations for organisational innovation * An engaged team with a desire to innovate * A culture that is accepting of change * Strong expertise and domain knowledge * A defined creativity methodology or set of work practices

I explained how I felt that River had the first three of these in abundance. We are an incredibly engaged organisation with expertise in both business and technology domains, that promotes agility and acceptance of change across the business. Where I suggested the group could focus was on the methodology aspect - promoting processes and practices to support innovation that would allow us to harness the engagement, expertise and desire to change that we already possessed.

10 Types of Innovation

To examine the areas that we can consider as a target for innovation I referenced a second book - the "10 types of innovation" (confusingly - why is it that these things always come in tens?). In this book the authors present a model of innovation that goes beyond just product innovation to cover other areas where companies can be innovative and disruptive

  • Profit Model
  • Network
  • Structure
  • Process
  • Product Performance
  • Product System
  • Service
  • Channel
  • Brand
  • Customer Engagement

This model was very useful to set the scene that we weren't just looking at software innovations but any areas of the business where we could add value through adopting new mindsets and approaches.

Establishing the Principles of Innovation

When setting up any new team or group I find it a very useful exercise to establish a set of principles for the group. Working together as a team to identify the principles helps to break barriers and bond the team. Creating principles also helps to flush out any differences of opinion about the purpose and activity of the group and gets us all on the same page. As new people join the group the principles then provide an excellent basis for introducing them to the way that the team operates, and we can refer back to them in situations where we feel that we might be straying off our original purpose.

The first task that I set for us as a group was therefore to establish a set of principles for the RIG. Given my experiences with innovation silos though, I'll admit that I did provide the first principle to start things off:

  • The RIG does not own innovation at River, we are here to promote innovation across the organisation

Everyone input something and we pulled the results together into the following:


  1. The RIG does not own all of the innovation, we aim to foster a culture of innovation across the whole of River

  2. The RIG is an open community and encourages participation from people across the business

  3. We encourage cross-functional knowledge and thinking and look for opportunities to innovate in all areas, not just products

  4. We aim to continuously improve and question and innovate on our existing ideas as much as new ones

  5. We don't dismiss any ideas and celebrate any failures as opportunities to learn

  6. We aim to empower and encourage people to be confident in owning their ideas seeing them through

I was very pleased with the result. The group were keen to keep the membership fresh and encourage new members to come regularly so that we avoided becoming a silo. We established an approach of having different people run the session each time and to suggest and vote on topics to avoid making the group to just one person's agenda.

We've since already had session two and identified some great new approaches to adopt to identify the challenges we face (which furnish great opportunities for innovation), to constantly question what we're doing, and to focus ourselves so as not to spread our opportunities too thinly.

Accepting Change

One of Burkus's key foundations for innovation is an acceptance of change. I've rarely seen a company change as rapidly as I've seen here in the last 18 months, and empowering people across the business to be part of innovation is going to be key to people having a positive perception of that change. As I hand over the reins of running our next RIG session to another member it is my hope and belief that we have something that is genuinely going to make a difference, not just in the group but across the business, and not just now but for a long time to come. Oh, and if you are wondering about the individual who was reluctant to join - it almost doesn't need saying that she has made a fantastic contribution to the group and it's a much better group for having her there.


Sunday, 1 October 2017

Textual description of firstImageUrl

Software Development - A Sisyphean Task?

It's rarely a pleasurable event returning from holiday. No matter how much you might enjoy your job it's still a sad event when that family time is over and you have to return to the more mundane routine of home, work and school. On arriving back you're never quite sure what emails are sat in your inbox or what post has landed on your doormat.

(I sincerely hope that you take the opportunity to take time away from emails on holiday - it's a holiday for a reason and the extra productivity from a genuine break far outweighs the apparent benefits of 'keeping on top of things' whilst away)

My return from holiday this year was markedly more pleasurable this year than previous years thanks to :

  1. My inadvertently buying double the amount I intended of a wine I'd never tasted at a spanish wine merchant and subsequently finding it to be quite delicious
  2. My finding a copy of Gojko Adzics new book 'Humans vs Computers' on the doormat as I arrived through my front door.

It's rapidly becoming one of my favourite books on software.The basis of the book is a series of lessons on the common pitfalls in software with strong and amusing anecdotes of projects that have suffered them.

  • Individuals getting charged tens of thousands of pounds for hotel rooms and car rentals because of decimal point position bugs
  • Computer systems refusing to initialise on 29th February as they didn't recognise it as a date
  • UK Post-codes failing to match because of inconsistency in how they handle the space between the incoming and outgoing postcode sections
  • US drivers being assigned huge numbers of fines due to inadvertently selecting number plate sequences matching the default text that traffic officers would enter in forms for a non-readable plate.

Whilst the stories that Gojko shares are amusing and eye-opening in equal measure, there is a more worrying aspect to them. The reason behind many such anecdotes being amusing is the fact that they strike a chord of familiarity with so many of us. The fact that so many people that have worked in software development, particularly testing, can identify with the calamities that can occur when working with leap years shouldn't really be trivialised as a subject for amusement. The problems with decimals that, as Gojko points out, cause so many embarrassing and costly mistakes, really aren't a laughing matter. I've spent my entire working life working with computer software and yet we still don't seem to be able to match addresses between different IT systems. We do seem doomed to making and discovering the same mistakes over and over again.

A sisyphean task?

I was chatting to a group of testing enthusiasts including Rob Lambert a while ago about the current state and future of testing. Rob in his eloquent way went on something of a diatribe about the fact that we won't be able to truly progress until we find ways to solve these same issues that come up again and again. I couldn't agree more.

When I started this blog it was with this post suggesting that software testing might be perceived as akin to the task of Sisyphus - forever destined to repeat the same activity. I wonder whether in actuality it is software development as a whole that on too many occasions is more like a Sisyphean task. Despite the availability of open source code repositories, shared libraries, Nuget Packages, development frameworks and ever more functional programming languages, we do still seem to have a habit repeatedly striving and struggling to solve the same issues that have been plaguing software development teams since the days of the BBC Micro.

Even casting my mind back over the last year or so I can recall examples of problems that I have encountered in exactly the 'classic' areas that provide such a rich supply of anecdotes for Gojkos' book.

  • Last year I was forced to implement a manual backup to an automated validation process for people using one of my systems as it was not possible to reliably check a match between postal addresses algorithmically between two separate systems
  • On a related system I was forced to prioritise a change to the UK postcode processing of an interface as an associated website provided postcodes without a space whereas our own system utilised and expected spaces.
  • A couple of years ago a system I supported encountered an issue where the 2015 leap second resulted in massive unexplained CPU usage requiring a server reboot to correct
  • In the last couple of weeks I've had to revisit discussions on calculation of performance figures in a customer dashboard as the example figures we were given demonstrated rounding up to the nearest integer whereas to maintain consistency with other systems we actually needed to always round down to one decimal place.

It's not all bad news

In a weekly publication I read there is a section "It wasn't all bad news" where they present some more light hearted stories from the week to stop the reader from being too depressed at the state of the world.

In a similar vein I'll leave with this sentiment. It may be easy to rue the apparent lack of progress in avoiding issues in software development, however at the same time there are still many reasons to be glad:-

  • Software testing as a craft is still very much needed.
  • Testing Heuristics have far greater longevity than expected and so our fantastic testing resources such as Hendrickson, Emery and Lyndsay's Test Heuristics Cheat Sheet are still valid and relevant.
  • We can enjoy great stories around software issues, such as those that Gojko has collected together in his book, relate to them and continue to share them even years later.

So I suggest taking some time to have a read of "Humans vs Computers" and maybe feel better about things the next time you can't match a postcode, or your software stops working on February 29th.

Sunday, 13 August 2017

Textual description of firstImageUrl

The Big Bang

In the last month two significant things happened in my work.

  • Firstly we completed a major release for a high profile client.
  • Secondly I got the opportunity to work in the new River office for the first time.

This is an exciting time in my current company as we strive to move not just to taking an agile approach in our software development, but to embracing agility across the organisation by working flexibly and incrementally, always looking to add value and regularly review priorities. Working in an agile way on internal projects is one thing, taking an incremental approach with customers is not always as straightforward, particularly with customers who have a large set of requirements, a target date when I they want these to be delivered by and an expectation of getting it all delivered in one 'Big Bang'.

New Office

I worked in the new River office for the first time recently. In a mildly surreal experience a colleague and I were initially sat at desks in the middle of a nearly empty room.

I then I had to move to the corner of the room as the chap who was using an industrial cleaner to deep clean the carpets needed me to move. I wasn't bothered by this, or the noise of the cleaner, or lack of tea making facilities. I had a desk in an isolated space where I could get my head down on a task that required some careful attention. There was a lot of value in that office space for me.

Typically you would think of a move to a new office as a classic big bang operation with everyone packing boxes and piling in as part of a large scale coordinated event. Right now in typical fashion for my company, we're taking things incrementally and getting a lot of value even before the whole thing is ready. People started having meetings over there and some folks went over just to get some quiet 'heads down' time. Then slowly teams started to move in as and when they could be supported and at this stage about half of the company are now based in the new site.

Old School

By way of a contrast, in recent weeks I've been involved in a major release of software to support a customer engagement programme. As this was a replacement for an existing site the customer was keen to get as many of the features in place ready for a big launch as possible. The release was also the first to be based on a set of core capabilities that we were investing in ourselves that needed building from the ground up to support not only the bespoke needs of the programme in question but also other similar programmes in the future. This magnified our uncertainty around the development, and therefore the risk, significantly.

When working with new customers and trying to convince them off the benefits of an iterative approach, one of my favourite images to reference is one from Henrik Kniberg

It gives a very simple representation of why delivering incrementally can provide a safer option, particularly in projects with large scope or many deliverables. Not everyone is familiar or convinced by such an approach and many still insist on rolling the scope, and risk, up into a major release - as was the case in my latest project.

Did it work?

I have to say that in terms of big bang customer releases my most recent one was one of the smoother ones that I've been involved in. There was a lot of effort put in and some longer hours as we approached the release, however we did release within 2 hours of the target time with the majority of the features in place and a generally happy customer. If I was to attribute this success to anything I would highlight two factors

  • We ran a number of user testing sessions during development to demonstrate and get feedback on the features delivered to that point, essentially embedding a level of incremental delivery into the larger project
  • We did manage to negotiate a number of features out of scope of the initial release thanks to a very reasonable customer and some open conversations.

As we approached the release the customer could not have been more reasonable about things that were/were not going to be included. Nevertheless there was still a degree of pressure around the delivery that resulted in some anxiety, not least on my part, around getting the release out on time. I was painfully aware of the potential for a sense of frustration around having to compromise on some of the features that would be available from day one.

It is hard to over-state the sense of satisfaction and relief that comes in getting software released. The difference in anxiety level in a team that has successfully delivered working software and is adding to it, as compared to one that is in the process of accumulating a large inventory of unproven software, is tangible. From a personal perspective, the discomfort I felt in having a fixed scope of work and a fixed release date to deliver led to some very stressful moments.

What has happened since has also not been plain sailing. Despite efforts to maintain our standards around our core capabilities, we still accumulated a small degree of technical debt leading up to the release such that we consequently struggled to deliver the follow up work to the time-scales expected by the customer. We simply weren't in a position to progress them as quickly as we thought due to the final push to deliver the release.

In a riff on a Benjamin Franklng quote, I once read that 'the smell of poor quality lingers for long after the champagne bubbles of an on time release have gone flat'. I can relate to the sentiment. I'm pleased that we made the right decisions to maintain quality under pressure in most decisions, but not all. Despite the apparent success - the retrospective that we held post-release exposed the discomfort felt by some of the team in the days leading up to the release due to having to increase the pace of development.

A Confession

At this point I should make a confession. The fact is that for 9 years in my previous company all we did were big bang releases. Our customers didn't want new versions of the software every 2-4 weeks so we'd typically roll up new functionality into 6 month releases. Over this whole time we consistently delivered on time and with the target major feature set. In my more moribund days at that company (I am prone to a high level of self criticism) my VP would repeatedly remind me what a fantastic achievement it was to repeatedly release on time over such a period of years.

In order to achieve this we tailored our approach so that they were very well suited to tackling Big Bang releases successfully:

  • We worked constantly with the same team on the same product so had highly predictable velocity
  • We generally operated to product roadmap deadlines rather than customer deadlines, whereas other big bang releases I've worked on were based around when the customer wanted to release rather than a practical target appropriate for the software in question.
  • We had the ability to negotiate scope from the beginning and remove items from the release that were unachievable, or became unachievable due to emergent priorities
  • We had the time to focus on a continuous integration and testing structure that allowed us to maintain a constant level of quality.

It wasn't that we had the luxury of working slowly - the pace and predictability of the work delivered was impressive. It was the case that we had the maturity of process to know what was possible and predict early what was not. We also had the rigour and stability in our continuous integration and testing processes to know that we were never far away from a releasable product.

Big Bang or Hard Sell?

When working in a commercial capacity it is easy to plump for the big bang approach. In simple terms - it is easier to sell.

As an example I was recently asked to scope/cost a response to an RFP (Request For Proposal) from a company wanting an intranet and engagement programme. On examining the RFP it was clear that the scope had been established more on the basis of a big list of features desired by a number of stakeholders than a clear understanding on what value the program was intended to deliver. The list of technical requirements was huge, yet each sufficiently ambiguous to present a high level of uncertainty and risk in attempting to deliver. Even so the customer was expecting a fixed cost fixed time-scale based response to the delivery.

We took a brave approach to the response and actually offered a fully iterative delivery. We suggested working with the customer to establish their highest priority goals and target initially the delivery of features that supported those incrementally. We fully expected this to be a challenging approach and our expectations proved correct. The customer's response was along the lines of :

"Why would we take that approach when we can work with another supplier who promises to deliver this whole list in a fixed time for a fixed budget?"

I'll admit it is a harder sell. Customers are always going to prefer the illusion of certainty over the honesty of unpredictability. I've included some useful links in the references below on approaches to try to sell an agile approach to project delivery from others facing this same challenge. My strong belief is that, any supplier who did promise such a delivery would need to renegotiate once clearer details of the true requirements became clear.

On a more optimistic note - for some companies that we work with the understanding that agile deliveries can present a lower risk to both parties is starting to take hold. We are encountering more organisations who not only understand but expect an incremental delivery. Given how ubiquitous agile understanding is in development communities if can be hard to believe how alien the concept is in other fields. yet the common perception is still that the setting of arbitrary deadlines for large scope projects will deliver software of equivalent value as delivery through a process of incremental release, review and refinement. Hopefully as stories of the successes of more incremental projects become more readily available this will change, so to help this process along...

Despite the project I've described above being a 'big bang', we still approached the work in an agile way. We delivered completed features through the process and exposed these to the user community for feedback and refinement as we went. Because of this, despite the fact that not all of the scoped features were available on day one, we still released on the target day, with what is proving to be a very popular and well liked application (one of the users this week wrote a poem in celebration of the new system!) and a solid set of core capabilities that have the quality and exten sibility to use in other implementations. So I'll leave you with another of my favourite Kniberg images, to help in deciding whether the project was successful or not.



Tuesday, 23 May 2017

Textual description of firstImageUrl

The Most Effective Form of Communication

Have you ever had trouble explaining what your job is to someone? Whilst struggling to explain your role outside work may provide some social awkwardness, when the same situation arises with work colleagues it can be more of a problem. If those colleagues interact with you directly and have a very different expectation of what you should do than you, it becomes a genuine concern.

One thing that has characterised the roles that I've held since I first became involved in setting up and leading teams is the need to establish an understanding amongst others of what I and my teams do. When I was focused solely on testing this was typically due to the need to correct a restricted and out of date view over what testing involved. When running technical support it was more around establishing an understanding of what support could and should be doing for others and the appropriate ways to interact with the support team. More recently, as I've overseen the introduction of Product Owners into River, I've seen it in relation to understanding what a Product Owner does and how they work.

I've tried various ways to communicate out what's involved in different roles.

  • Presentations to talk people through the processes and activities undertaken by the team
  • Group sessions on how to work together
  • Taking each new starters through individually to discuss what we do
  • I've even created graphic user journeys in prezi showing people might interact with the team

All of these have worked well to some extent. There is, however, one approach that I've found consistently communicates am understanding of what a role entails better than any other. That is by focusing on doing a great job.

Not as easy as it sounds

It sounds simple, however this isn't always the case. If within your company there are those who misunderstand your job, responsibilities or approach then it is likely that they will make demands of you that are inconsistent with what you know will deliver value from your role.

I've had many situations in my work in software testing where the expectations of others differed greatly from my own opinion of good work

  • Being asked to test a piece of software where the only reference point for target behaviour is the software itself ('can you just find the bugs?')
  • The perception of testing as a process of creating test scripts and running them
  • Testers being expected to ignore the risky architectural concerns in a piece of software and focus on trivial bug finding in the user interface
  • The perception of a lack of need for testing other than creating automated unit tests and running them

...and the same is true of other areas that I've worked in

  • Product owners being expected to deliver an already defined list of features simply by 'turning them into user stories' and assigning them to sprints
  • Product owners expected to predict which features will be delivered in which exact sprints to strict timescales throughout a lengthy development
  • Support staff being expected to repeatedly deal with the same issues in flawed software without raising their concerns and recommendations for improvement with the product team

In all of these cases, the situation that the individuals or teams can find themselves is a frustrating one. There is expectation, often associated with a certain level of pressure, to perform a role that is fundamentally different to the one that you should be, or want to be, doing.

Turning in around

As I said in my post 'Knuckling down' - I believe in putting in your best effort to resolve problem situations rather than being too quick to walk away based on a role not meeting your expectations. Clearly if your organisation shows no sign of changing despite all efforts to improve then the door is an option, but I'd always strive to try to turn this around first. But how to do this?

I suggest to start with, ask yourself why the mis-perception exists. Do you believe that what you see as the role will genuinely deliver more value than simply delivering the work in the way that is anticipated?

Presumably the answer is yes. Therefore by changing your behaviour to deliver in the way that you envisage you should deliver more value to the stakeholders in the process than they were hoping for. The problem here can be that, making major changes can impact an existing flow of work. The last thing you want is for your 'improvements' to be associated with a big disruption. Instead I've found that a more incremental approach, focusing on introducing small changes and steering the pipeline of future work rather than what is currently in progress, is much more easily digested.

  • Do some small elements of the work your way 'guerilla' fashion and then demonstrate the value from those small pieces - nothing demonstrates the value of exploratory testing more than a shed load of risks and problems exposed that wouldn't have been discovered by your test scripts.
  • Know when to bend and when to push back - if people ask you to deliver tasks that aren't appropriate, potentially agree to it this time to avoid disruption but state clearly that on the next occasion you will be tackling it in a different way
  • As you deliver, go 'above and beyond' on the work, but make sure any extra effort clearly demonstrates the value of your preferred approach
  • Use what you have done to provide information on status or risk that would not have been available previously
  • Avoid a backlog of inappropriate work building up - take the opportunity when discussing new work to introduce new ideas at that point and establish a change in expectation for future programmes

The what, not the how

You inevitably need a level of stubbornness here. No matter how much you believe in what you should be doing, if you consistently acquiesce to others demands then attempting to steer a role away from their misguided expectations of it is going to be a challenge. One of my greatest failings in the past has been too easily assuming that the approaches taken by others are appropriate without questioning and asserting my own ideas on a process. Over time I've found what really helps to reinforce stubbornness is passion. The more passionate I am about something the more likely I am to research it, discuss it, reinforce my beliefs around it and belligerently strive to deliver value by doing it, even in the face of conflicting expectations.

If you find yourself in such a situation the most important thing to remember here is that other people ultimately aren't really interested in how you do your job so if you persist you are more likely to win through. Others are probably not that excited by discussions around why your approach is better so trying to present people with explanations of theory is going to have limited success. What people do care about its achieving success in their own roles, so focus on how you can help them with that. The most effective way of convincing anyone of the value of a different approach is by showing what it can do for them, and the best way of achieving this is by doing it. Really damn well.

Image - there are many who believed that a metal ship would be too heavy to float, or that a screw propellor would not work as well as a paddle. Brunel proved them all wrong when he built the SS Great Britain.

Wednesday, 15 March 2017

Textual description of firstImageUrl

When is a Prototype not a Prototype

When is a door not a door ...

... when it's ajar

Throwing away things that we've put effort into creating is not something that comes easy to most of us. It is hard to look at our outputs without seeing the hours and days of effort that went into their creation. Yet throwing away previous efforts is exactly the right thing to do when it comes to prototyping, or the consequences can be dire.

When is a prototype not a prototype?...

I'm not going to discuss in this post the merits of prototyping, suffice to say that an effective prototype can provide a massive learning opportunity. Whether or not to prototype in any situation is not really pertinent to the focus of this post. What I do find very interesting is that, whilst I have seen seen lots of what I would consider to be prototype code, it's rare that I've encountered a capability that was openly described as a 'prototype'.

What I have seen are 'proof of concepts' to demonstrate and trial a capability, or 'pilot' software where a product is being trialled on a subset of users and doesn't have to support the full scale of production use. I've seen 'innovations' coming from 'innovation silos' (where an individual or small group in a company has cornered the market in product innovation) which serve to demonstrate a new development. But I've rarely seen an honest, openly labelled prototype.

...when it becomes a product

Is there any problem with calling our prototypes something else? Well yes, there is a gigantic problem with it. Using the appropriate shared terminology is vital in understanding the situation we are in. In my opinion the correct approach in all of the situations I described above at the point of deciding to progress these capabilities into production would be to... wait for it... write it again using the existing code as a throwaway prototype. The team developing the production code would take valuable learning into that development from the existing capability and create a high quality piece of software from it. Unfortunately I've seen too many situations where this is not what happens.

Given that so many involved in developing and testing software are so aware of the perils of implementing poor code, it seems somewhat surprising that we'd ever allow the situation whereby we're trying to take prototype code into production, yet I've seen this happen many times, and often the development teams have little choice in doing so:-

  • In some cases where the code has come from an innovation silo, it has not been made clear that something is only a prototype. This is usually because doing so would rely on the innovator admitting in delivering low quality throwaway code, something that they're disinclined to do.
  • If a pilot capability hasn't been delivered to production quality, it can be a huge challenge to persuade the business of the need to rebuild when it is already being used, albeit in a limited capacity.
  • It is an unfortunate truth that, if you demonstrate a working piece of software to a C-level executive or customer account owner, it is then hard to persuade them that the next step is to throw it away and build it again, but this time 'properly', after all - you've just demonstrated it working.

Instead what I've seen happen on to many occasions is the decision is made to take the existing code as a starting point and turn it into a production quality piece of software.

This rarely ends well.

Turning prototype code to production code is a time consuming activity that yields little observable value outside the development team, as it generally involves such 'trivial' concerns as:-

  • Adding error handling and validation
  • Adding logging for monitoring and diagnosing faults
  • Putting in place proper decoupled architecture, isolating component responsibilities and defining interfaces
  • Adding transactionality around operations

All of this is critical to having a product that is genuinely ready for live use, yet delivers little in terms of new user facing capability that business owners can see as progress. Inevitably the development team come under pressure for taking so long to tidy up something that appeared to work with all of the features they needed. In one extreme example I had the CEO say to me of a particularly risky piece of research code written in a loosely typed script language -

'now we just need to test it, right?'.

Well wrong actually, what we needed to do was rewrite the whole thing in a more appropriate coding language that supported strong typing and at least compile time validation of parameters across function calls and interfaces, but that was not what he wanted to hear.

Shooting fish in a barrel

For testers this is a confusing and frustrating situation. Their initial explorations will typically expose a wealth of issues which should result in rethinking the entire approach but inevitably do not. Instead one of two things happens.

  • A massive onus is placed on testing to reduce the risk of release through bug finding.

    This is clearly an expectation which is not only impossible but demonstrates a lack of understanding of what testing is there to achieve (like giving someone a dilapidated old Datsun Cherry and expecting them to 'test' it into a Ferrari). The code has not been built incrementally to a high quality and so finding bugs in this situation is far too easy and, whilst potentially fun, is wasteful for the company and the skills of the tester. Error handling and validation and other basic requirements are eventually built in but, as these are done in response to the bugs found the result is that this takes longer and yields less consistent results than if it had been done as a consolidated activity during the creation of the software.

  • The testers are warned by management not to test 'too thoroughly'.

    I'm not quite sure what they are expected to do in this situation. All I can assume is that in order to release if the process is that code has to have been sprinkled with the 'magic fairy dust' of testing, then if this can be done without slowing things down by actually (gasp) looking for problems that would be a great help. On one occasion years ago I was actually told to test the 'easy bits' whilst avoiding any of the high risk areas I'd identified in my initial analysis of the system - sigh.

Other options

There are, of course, other options. Rather than attempting to test out an entire process with throwaway quality code another option is to create a 'tracer bullet'. A tracer bullet has a very different purpose to a prototype. Instead of a throwaway model designed to learn about the viability of a feature, a tracer bullet is a fully production quality but very narrow implementation of a small slice of the target feature set, which can be used as a starting point for evolutionary development. In the reference links there are some discussions around the purpose of tracer bullets. Here I'm referring to a thin slice of production code to help answer questions around architecture and interfaces, rather than a more incremental concept of developing slices and getting feedback, which some might consider 'evolutionary prototyping' however I consider implicit in an agile approach.

I recently had the pleasure of being involved in a cross team activity involving multinational teams to demonstrate an integration capability. I mentioned my determination to avoid the expectation of being able to implement prototype code with the developers. I was pleasantly surprised when they adopted a tracer bullet approach. In the session they developed an initial very thin but working slice of the integration that we could then directly implement and expand upon to create a production capability. It would have been all too easy to deliver a low quality prototype here and generate false expectation in the group around a realistic pace of development and the level of progress. Instead adopting a higher standard to a narrower piece of functionality provided a great starting point for the ongoing development.

Kidding ourselves

We do have a habit in software of kidding ourselves. Like cigarette smokers we go into a kind of state of denial that our bad habits will ever catch up with us and tend to repeat them over and over. I remember when I was a smoker I was terrified of the word 'cancer'. I didn't want to associate the grievous potential outcomes of my habit with the habit itself. Openly giving things the right names helps us to be honest about our situation, and software development is no different. By hiding prototypes behind terms like 'proof of concept','pilot' or 'spike' we are creating a loophole in our quality standards. We're excusing an approach of coding without rigour and testing, which is fine for a prototyping or research activity, but not the basis of a solid product.

My recommendation if you see this situation in the future is to openly and loudly use the word prototype at every opportunity.

  • I'm just working on some PROTOTYPE code
  • I'm not planning on testing the PROTOTYPE any further as I've found to many bugs, I assume I'll have more testing time when we develop the real one?
  • Is that the customer who are still using the PROTOTYPE version?

OK maybe you need to be careful with this, however promoting honest conversation around the state of what we're working with is the first step to avoiding some painful soul searching later.


Image: Old Door by Oumaima Ben Chebtit

Sunday, 19 February 2017

Textual description of firstImageUrl

The Innovation Silo

Who is responsible for product innovation? Is it an individual, a specific role, a devoted team, or is it everyone? I can tell you now that unless the answer is the last of these options then you could well have a situation that undermines the motivation and performance of your development group.

The Innovation Silo

A couple of weeks ago I was discussing with a colleague the challenges of innovation. We'd both encountered in previous roles the situation where one individual or group was given a free role on innovation. These people went by different titles, either as individuals or teams : Chief Scientist, Architect, Research Team. The result was the same: those given the freedom to research and innovate would perform those activities in isolation from those working on the main product streams, operating in what was effectively an 'innovation silo'. The focus of the innovator's activities would be to come up with advances in technology or capability. Their output would be aimed at senior management, with the goal of demonstrating to them a 'working' capability of an idea that they had developed and obtain approval to push it through to production.

The Motivation Sink

Arrangements like this were great ... if you happened to be the ones in the innovator roles. These people enjoyed a high level of job satisfaction and operated with a low fear of failure as their work was rarely exposed directly to live use, instead it fell on the regular development team to take these initiatives and carry them through into production.

In addition to inevitable practical issues of handing over prototype code, (which I've decided is a big enough topic to merit a post of its own shortly), the problem was that this arrangement caused a huge amount of frustration for the individuals that weren't part of the innovation activity. The freedom that one individual or team enjoyed came at the expense of many other developers and testers working hard to deliver the commercial obligations of the company. The people who were responsible for the day to day delivery of release schedules and customer deadlines would rarely have the time or the freedom to try out new ideas, unless done in their personal time. The closest many would come to innovation would be in struggling to understand, implement and test designs (if they were lucky) or code (if they weren't) of new products or features which had been created by someone else.

The inevitable outcome of this type of activity on the development and testing teams is demotivation. Fundamentally what we are saying to these people is - "we don't trust you to come up with good ideas". Not only is the exciting work of innovation and research out of reach to the rest of the development group, but to add insult to injury they are then asked to take the output of that innovation and perform the necessary yet uninspiring activities that are so crucial in software, and deliver these in an atmosphere of unrealistic expectation and high fear of failure. I've never encountered the situation where a developer was ecstatic to be working on someone else's code, however at least when that code has been working as part of a live system there's an element of respect in it. When the author of the code has never had to expose it to formal testing or the rigours of production use then that respect is absent and resentment can result.

The arrangement places testers in a frustrating situation as well. Being isolated from the process of innovation results in a separation from the goal of the development. In order to perform effective testing a tester needs to be on board not only with the behaviour of a solution but also to have a keen grasp of the problem that is being targeted. When product research is performed in isolation from the testing group then testers are forced to work within the solution domain. Any benefits of having the critical thinking of a tester integrated in the design process to question decisions and refine early designs is lost. Even if the tester does have valid concerns it can be politically difficult to raise these in the face of support from influential technical staff backed by senior management. Instead the tester politically and practically is compelled to limit their frame of reference to what functional understanding they can gain from behaviour of the developed solution. Their role is diminished to a confirmatory one of verifying existing behaviour rather than a wider scope of questioning value.

An open innovation

I'm hoping that I've just been rather unfortunate to see this type of relationship in more that one of my past jobs - I'd be interested to know in the comments here whether anyone reading this has encountered a similar situation. It it a common scenario for opportunities for innovation to be restricted to a chosen few?

I'm sure that many companies out there have very open and inclusive approaches to innovation, and I'm keen to help make sure that my current company is one of those - so what are the alternatives to innovation silos? In a recent product workshop I ran, some ideas that we identified to avoid this kind of situation included:-

  • Getting everyone in the company on a user feedback forum to share their innovation ideas and vote internally for their favourites
  • Allowing people time to pitch their ideas and provide the support for small cross-functional teams to be created to develop them together.
  • On a similar vein one of the developers at River pitched an interesting idea recently of having 'ideation sessions' where at regular intervals different cross functional groups were given the chance to try out an idea and develop it.
  • Having innovation sessions at whole company days to get everyone involved at the same time to generate ideas.
  • Developing and trialling new capabilities into our own internal version of our engagement software

Whatever form it takes, I think the important thing here is that everyone should be able to contribute and feel part of innovation activities. At the very least everyone should feel included in the process and able to actually raise their concerns over any new approaches being adopted.

As I stressed in my post on 'sharing the vision' there's a huge amount of value in simply having all of your team members engaged with a vision and able to identify connections and opportunities that help to move towards it. You don't have to be the smartest person in the company, with a job title of 'Scientist' or 'Architect' to come up with an idea that advances your capabilities. Naturally some individuals are more inclined to innovation and will generate more ideas than others, however at the same time many great advances come from simply making connections, such as applying an existing approach to a different problem, which anyone can do. The less we think of innovation as part of a role, and more part of an organisational culture, the more likely we are to get everyone driving and supporting our innovations rather than resenting them.


Tuesday, 31 January 2017

Textual description of firstImageUrl

Sharing the Vision

When you work in the field of employee engagement , as I've done for the past year at River, it's hard not to pick up a thing or two about the subject. Luckily for me this was already an area of interest - as I wrote in this post I've always placed a high value on the motivation and personal development of the individuals in my teams, so working in the field of employee engagement is a great opportunity to extend my own knowledge in an area I care about.

Whilst researching the subject of engagement, one strong driver of people's commitment to their employers that I've seen referenced as crucial across a number of studies is when they share in a vision of the company's goals and culture. This sounds like a simple thing to achieve, however many organisations struggle to do exactly that.

The importance of vision

Studies such as this one of employee engagement and motivation, such as this one have identified the feeling that you are a contributing part of a larger vision for your organisation as one of the strongest factors in engagement and motivation. In fact some studies have concluded that a feeling of being part of a wider vision is the single most important factor in employee motivation.

But what do we mean when we talk about a vision? Well what I'm not referring to its a facile written statement, posted on the office wall - although I'm aware some organisations seek to compensate for an absence of genuine vision with just such a weak imitation.

This is not to say that vision statements themselves cannot be inspirational - this list of vision statements for nonprofits organisations contains some wonderful examples (though you have to admit the creation of an inspirational vision statement must be somewhat less challenging when ones organisation has such inspirational purposes). For organisations with less altruistic goals the encapsulation of the vision into a one line statement can feel contrived, and I personally find written vision statements in isolation from company practice or principle both trite and unsatisfactory.

A vision is, and needs to be, more than a statement. Just as in agile development we describe a user story as a place-holder for a conversation, so a vision statement needs to act as a place-holder to summarise the common values, goals and behaviours that characterise the employees of an organisation. A company vision is more like a shared consciousness of where we want to be, and how we want to get there and has to be not just understood but embodied by the individuals working for that organisation.

Missing the vision

Given the importance of a vision it's surprisingly easy to overlook when hiring teams and structuring work. This HBR article quotes 95 percent of employees being unaware of the company strategy. In development specifically I've seen situations where there simply isn't a high perceived value in sharing corporate goals with development teams. Perhaps it is the often quiet, focused nature of roles such as development and testing that results in the perception of people in these roles as resources that can be moved around interchanged, needing only their immediate inputs and outputs to be defined to deliver effective work. It is easy to target peoples' efforts on tackling the feature developments, bug fixes and releases that the make up the day to day activities, without considering any value in their understanding the wider organisational vision.

Why would we worry about missing the vision? As we tackle the tactical work that is prioritised around our immediate needs there will be opportunities to advance ourselves towards our longer term goals. Whether or not we take these opportunities depends heavily on whether the individuals working on those activities identify them as important. I've seen very successful cases of teams identifying opportunities. For example a team working on a customer website project recently identified the addition of a new user role in the programme as an opportunity to start introducing a content management capability that was one of the long term strategic aims of that programme.

On the flipside, opportunities can be missed if those involved don't have context of a wider purpose. I've also encountered projects that deliver value in the project context in question, but miss the opportunity to deliver value on a more central strategic level for the organisation of the work had been approached slightly differently. If the whole team is not on board with the strategic goals of the company then opportunities can be missed.

Vision workshop

Small companies, such as the ones I've worked in for the last 12 years, often have a distinct advantage when it comes to sharing a vision in that they are likely to have a much more accessible CEO or leadership team than larger organisations. Having a leader that can interact directly with employees is one of the key strengths of smaller organisations and I believe can provide competitive advantage in the motivation and engagement that it can drive. Software development and IT teams in particular can be operational silos, separated from the roles with a more direct business connection. Having access to top level leadership who can convey the importance of the work that is being achieved across a company is a huge benefit to these roles.

Recently I organised a workshop day with the main aim of sharing the vision of the CEO with the new product owners recently brought into the company and to allow those POs the opportunity to cement their relationships with other key people in the company. An introductory session from the CEO on the history of the company justified the day before we'd even hit lunchtime. I'd not previously appreciated the direct historical link from the very first engagement rewards company to the modern company that we were now part of. Learning the history of River and how this has shaped the programmes and capabilities now being offered was both interesting and important knowledge for the attendees to understand.

In further sessions we explored our capabilities across various customer programmes and examined how these fitted with the theories and models of engagement which are relevant to our business domain, as well as looking at options for how to validate new ideas and innovations through the research and development lifecycle.

Whilst some elements of the day were more successful than others, for example the sessions probably generated too many high level ideas at the expense of practical implementable suggestions, overall the value of having the Product Owners in a room with the experience of the CEO and creative and UX folks discussing our products was invaluable in instilling in them a vision of the company and where we wanted to be.

making your own vision

Not everyone has the autonomy to arrange events such as the one I just described. Even those that do sometimes don't have the luxury of an inspirational leader or a company situation that they find engaging or motivating. The good news here is that in my experience it is still possible to engage people with a vision in the form of a group cause that people can get behind.

At one point in a previous role the development department were struggling with motivation. A significant change was being imposed externally which as a group we had little control over or belief in, but risked a damaging impact on the quality of our work and our pride in it. It was a challenging time where engagement was in short supply. Whilst it was never going to be an inspiring project, I focussed on establishing a collective cause for the development team. Our goal was to take ownership of the situation and do the best job that we could of providing a quality delivery. As a group we renamed the project to introduce some team ownership of the situation. We established the work we were able to do in the short term to understand and improve the status of it and defined and communicated appropriate approaches to refactoring, testing and documenting the changes (the testing was based around my mind map for testability).

I believe that the work done in the time available on that delivery was exemplary. As a group, having a shared vision of what we were working towards really helped us to gel together, when it would have been easy to descend into melancholy and denial of the situation.

Just do it

"If you are working on something exciting that you really care about, you don't have to be pushed. The vision pulls you". Steve Jobs.

Even without inspirational leadership of the nature of Steve Jobs it is possible to create a vision within a department or team that motivates and inspires. This could be working towards an aspirational goal or simply collectively tackling adversity in a constructive way. Just as there are always going to be times when things aren't going as well as we'd like and a clear vision can help us in persevering, so it can be that when times are good a vision helps individuals to make connections and create opportunities to move us further, faster.

Having a higher purpose in terms of a group or organisational vision is such an important motivator that, if you don't have one, and you don't have access to someone who does, maybe it's time you made your own.