Sunday, 28 January 2018

Textual description of firstImageUrl

Aligning with the Business

I have over the last few months been concurrently involved in some of the most and least inspiring work of my career. Naturally having a software tester mindset I decided to write about the negative stuff as a priority. What can I say? My glass is usually half empty.

Engaging Through Alignment



I recently had the pleasure of inviting an inspiring lady named Susie Maguire to run a workshop at River. Susie has a wealth of experience in the field of engagement and motivation and was the perfect person to discuss, question and regions our own expertise in this area. In one discussion during the workshop Susie discussed the importance of aligning the goals of the individual, with the goals of the team, with the goals of the organisation to achieving true employee engagement.

As with many of the most powerful ideas in successful work, this is a blazingly simple concept yet surprisingly difficult to achieve and therefore depressingly rare. The divided and hierarchical nature of many organisational structures means that teams can aggressively optimise to their own established goals, which, over time, can deviate drastically away from those of the wider company. As we were talking I couldn't help thinking about a process that I was working through at the time which was an extreme case of when such a deviation of goals occurs.

A Painful Process

As I mentioned at the start I've also recently been involved in some of the least inspiring work of my career in relation to implementing a software programme into a large organisation. This is not in itself inherently painful and the relationships with the immediate client at the start of the programme were healthy and long standing. As part of the implementation we were required to work with an internal team from the wider global organisation to 'certify' that one element of our software meet their standards. We were happy to do this on the basis that we'd successfully delivered software to the client before and felt confident in meeting these standards based on our programmes with other global clients. Our confidence proved to be misplaced, however, when we discovered the details of the process.

  • It became apparent early on that the certification team were not going to engage with us in any kind of collaborative relationship at all but instead would operate primarily through the documented artefacts of the process
  • The requirements that we had to meet were captured in lengthy and convoluted documentation from which we had to extract the relevant information and interpret for our situation. Much of the documentation was targeted at in-house development in different technologies to our stack.
  • Some parts of the process involved different people submitting the same lengthy and detailed information into separate documents or systems, which were then all required to align exactly across the submission
  • Many of the requirements documented were either impractical or actually not possible in the native operating systems we were supporting
  • The process involved no guidance or iteration towards a successful outcome, instead certification involved booking a scheduled 'slot' which had to be reserved weeks in advance based on the predicted delivery date.
  • Any failure to meet the standards discovered during the certification slot were not fed back during the slot in time to be resolved towards a successful outcome, but were communicated via a lengthy PDF report once the process was complete
  • Items as minor as a repeated entry in a copyright list or a slight difference in naming between a help page and guidance prompts were classified as major failures resulting in failing the certification
  • Approaches were presented in the specification as reference examples, yet any deviation from the behaviour of the 'example' was treated as a major failure, even if the logical behaviour was equivalent.
  • The inevitable failure in the certification slot required a second 'slot' to be booked for a retest

The final straw came when, as part of the second booked review slot, new requirements were identified which we hadn't been told about in the initial certification, yet our failure to meet them still constituted a failure of the overall certification. Software components not raised in the first review were newly identified as 'unacceptable' in the second, and the missing behaviours stated in the first review were frustratingly in themselves insufficient to pass when it came to the second.

Misaligned

What was clear to me in going through this process was that here was a team where the goals of the team had diverged significantly from the goals of the company.

The goals of the team appeared to be

  • Ultimately protect the team budget by maintaining a healthy stream of failures and retests (the internal purchase only covered two test slots - a third retest resulted in an additional internal purchase and internal revenue for the team)
  • Tightly document the requirements of software solutions irrespective of value or practical applicability
  • Maximise failure through maintaining a position of zero tolerance for ambiguity or delivering value in different ways.
  • Maintain an internal view - limiting communication outside the team and Interfacing primarily through artefacts - such as requirements and failure reports

If this only affected us as a supplier then I would probably not be writing this. What was more frustrating was that I was working on behalf of a client company that was a component of the larger global organisation. The behaviours of this team were directly preventing the progression of an exciting and engaging programme. Instead of adding value to their programme they were using valuable budget on frustrating bureaucratic processes and inane adjustments that they saw very little value from and ultimately placed the programme at risk.

It could be argued that the team were protecting the company to ensure standards. I'd argue that a process of collaborative guidance and ongoing review would have been easier, cheaper in terms of both team and our costs, and far more likely to achieve a successful outcome. The process as designed was not aligned with the needs of wider company, including my client.

The other side of the fence

I get very frustrated in situations like the one above as they affect me on two fundamental levels.

Firstly, we only have a limited amount of time on the earth. Seeing so many talented people wasting their valuable time on such pointless activities is very frustrating. For me work is about more than making money. If intelligent and capable people are spending their time on undertakings that add little value beyond meeting the specific idiosyncrasies of a self-propagating process then they will start to question themselves and their work deeply. The nature of the process caused tension across all the people involved and caused anxiety for people that simply wouldn't have been required if the process had been structured differently. We wanted to deliver work that benefitted the programme and pleased the customer, yet we were unable to do so due the effort required simply to adhere to the process imposed on us.

Secondly, the process that I described above was essentially a testing process. It's true that the process was so unrecognizable from what I would describe as testing that it took me a while to appreciate it, but testing it was. The process fitted exactly the pattern of:

  • a strict requirements document written before the software was developed
  • a predefined sequence of checks based on adherence to the documentation performed subsequent to and in isolation from the development process
  • the absence of feedback loops that would allow issues to be resolved in a timely fashion
  • communication via artefacts and failure reports rather than direct communication between the person performing the checks and the developing team

Which could describe testing processes in many organisations throughout the world of software development.

Not what I call Testing

Being on the other side of such a testing process was a new and enlightening experience. It gave me an insight into how frustrating it can be working with a testing unit that refuses to engage. I can understand some of the suspicion and even hostility that developers historically have felt towards isolated testing teams. When your best efforts to meet the documents expectations are fed back via reports covered in metaphorical red pen, it's hard to harbour positive feelings for the people involved.

It's heartening then, that each year I read the results of the "State of Testing" survey and see a testing community that is in parts rejecting this kind of approach and embracing more communication and collaboration. In fact the testing skill rated as most important in both 2016 and 2017 survey reports was communication. Whilst this is encouraging, the level of importance placed on communication for testers did drop from '16 to '17 - which is not a trend that I'd want to see continue.

I recommmend if you are a tester reading this that you take the time to take part in this years "State of Testing" survey here http://qablog.practitest.com/state-of-testing/

Our ability to communicate risks and guide and inform decisions is paramount in delivering a testing activity that prioritises the needs of the business over the delivery of the testing process. Going back to Susie's lessons on employee engagement - if alignment with the goals of the wider business is the key to successful engagement then testers whose approach is focussed more on continuous communication and helping to guide towards business goals, are ultimately the ones who will improve their own satisfaction at work but also the others whose lives they impact in the process.

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:

RIG PRINCIPLES

  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.

References

ShareThis

Recommended