Monday, 8 October 2018

Textual description of firstImageUrl

The Sacrifices of the Servant Leader

Being in a position of leadership is a mixed blessing. Many of us starting out in our careers assume that achieving a position of leadership, and the respect that comes with it, is something to ultimately aspire to. Others don't feel this calling and at some point on their career path decide that a position of deep expertise is more suited to their skills. Some end up in leadership without any real concept of what their approach is - after all many people are promoted into a leadership role from a technical position without any real training or initiation into the role. Many such folks tend to 'find their style' rather than intentionally selecting a particular approach based on their personality or context - in my experience this can result in some rather unpleasant and dictatorial work environments.

Having studied management science in the past I have found that as I've moved into senior roles my approach has been guided heavily by my former studies on management, leadership and motivation. Whilst not a purist in any sense, I do find that the concept of 'servant leadership' is one I can strongly associate with. Research, and my own experience, suggests that the approach - whereby leadership is delivered through promoting collective decision making and supporting teams in taking responsibility - is very effective at leading teams to successful results, particularly when compared to more autocratic approaches. This success can, however, come at some personal cost to the leader themselves....

What is servant leadership and why is it a good idea?

I don't particularly like the term servant leader. It under-sells itself as a term, for me coming across rather weak and woolly. The reality could not be further from this. Yes servant leadership is a more supportive approach than other approaches, but it's a hard approach to adopt that takes strength and commitment to deliver.

  • A servant leader will seek to bring together diverse opinions rather than dictating their own ideas with a focus on inclusive decision making
  • Servant leadership is built around the idea of culture of mutual trust between leader and team which requires a high level of openness and honesty
  • The aim of a servant leader is to encourage others to take responsibility and provide support to improve their ability to do so
  • A servant leader places a high level of autonomy on teams and motivates people to step up and deliver

This definitely correlates with my style of leadership. I believe that building strong autonomous teams containing the right balance of skills and supporting them through a process of collaborative decision making provides the greatest opportunity for long term high performance and incremental improvement.

Does it work

I can appreciate that one person's experience does not provide for exhaustive evidence. Also my personal approach isn't one of 'pure' servant leadership. Last year I took an IDEOU course in creative leadership which identified 3 types of leadership.

  • Leading with a strong point of view
  • Leading through culture
  • Leading alongside

Servant leadership ties in strongly with the last of these. I agreed with the couse approach that to be effective this needs to be combined with other leadership approaches that can be adopted at appropriate times. This allows a leader to establish a vision and culture necessary to establish an environment that supports servant leadership.

In the situations where I have personally succeeded in creating such an environment and adopting an approach aligned with the principles above, I've experienced significant benefits as compared to other leaders that I've seen adopt a more autocratic standpoint

  • Team motivation - Being more inclusive in decision making really does motivate everyone to contribute ideas. I find that people respond well to being part of a decision making process and really engage as part of a team that makes their decisions and deals with their mistakes collectively.
  • Not hiding the problems - Playing a supportive role for people working in your department helps to more quickly spot the problems and keep them out in the open. Rather than having a culture of hiding bad news from the boss, keeping problems out in the open helps to identify where genuine and useful improvements can be achieved.
  • Collective Responsibility - Delegating responsibility for decisions helps to ensure that people are genuinely considering the risks and benefits of what they are doing. One of the biggest dangers of command and control leadership is that those implementing decisions are aware of the problems that may arise from them, but don't act on this as they have no personal responsibility for the negative outcome
  • In it together - Adopting a standpoint of serving the team provides a sense of being all in it together which makes it easier to drive through difficult times or raise and discuss challenging subjects. I recently raised a subject with my team around some potentially negative habits which, as an autocratic leader would have made them very defensive. Instead I discussed whether there were any underlying causes and whether the habits indicated problems with direction or motivation that I could help with. As a result we had an honest and open discussion without animosity about a potentially emotional subject.
  • Knowing how to help - When problems do arise I find that a servant leader approach actually positions me well to help the team to work through and deliver. When I've been in a more isolated 'pure management' role relative to a team with problems I've found my input very limited. There's nothing worse as a leader than being limited to repeating platitudes and passing ineffective generic advice on issues that I don't really understand.

With this in mind - I'm not about to change my approach to leadership in a hurry, however it's not all plain sailing...

Challenges of being a servant leader

Given all the benefits I've outlined why at the start did I suggest that being a servant leader may not be so great for the leader themselves?

I think the main challenge is that, being an effective servant leader is only possible if you work within and among the people who report to you. Unfortunately this can diminish your standing from the perspective of other with different ideas on what leaders look like.
It's a frustrating dichotomy that to be a really effective leader requires humility and the abdication of ego, yet doing so may undermine some people's perception of you as a strong leader and can place at risk some of the 'respect' that comes with a position of leadership. In a world that increasingly promotes individual 'profile' and accomplishment, delegating responsibilities and achievements is something that may appear to place our profile on the back foot on a few different fronts.

In the team

  • Not leading the charge - It can be hard to give up being the one at the front. For someone used to setting direction it can be unnerving to accept input from others on the best approach. This is something that I have got used to, while at the same time having to remind myself not to be too defensive about my own opinions.
  • Finding the time for strategic thinking - Leaders will naturally have responsibilities for strategic direction and long term planning that may not be the focus of other members of the group. Yes we can coordinate group planning and strategy workshops, but ultimately the responsibility for strategy will lie in leadership and it can be hard to carve out time to do this when operating to support the day to day team activity. I find that taking time away from the office at fixed times (e.g. 'Strategic' Work from Home Wednesday mornings) helps to step into that more long term mindset and ensure the important long term considerations aren't forgotten.
  • Constant questioning can be demotivating - This is one that I find personally tiring. While the dictatorial leader can issue JFDI commands and expect unquestioned obedience, a servant leader can and should expect to have to justify their decisions. This undoubtedly results in a lot more consideration of the decisions that you make, which overall is a good thing but can become tiring if you are having to do preparations worthy of a court prosecutor to progress decisions. There's a balance to be had here and in my current role I've worked to establish an expectation around the degree of questioning that is appropriate. This is based on trust in my decisions and has been necessary to ensure we avoid justification paralysis and avoid the risk of not being able to progress anything.
  • Bring together opinions - Inevitably when it comes to collective decision making not all opinions will align and individuals sometimes come to loggerheads over which approach to take. This is when the strength inherent in servant leadership really comes apparent. Being able to bring opinions together into a considered approach that everyone at least supports is critical to avoid ongoing resentment and counter-productive behaviour towards other people's ideas.
  • Being T-shaped - As part of an effective Square-shaped team, leaders need to be T-shaped people as much as everyone else. This inevitably means having to learn basics of a lot of skills at a level that allows you to understand and evaluate options, if you are to drive decisions that others respect.

Amongst other leaders

  • Underestimation resulting from not visibly making all decisions - Allowing others to drive success and supporting them in doing so means stepping out of the limelight so that others can step in. In environments of competitive leadership this can seem like a personal sacrifice.
  • People think it’s easy - This is an unfortunate consequence and something I've encountered a few times. When you are running effective teams or departments with little fuss, this can result in others' perceiving your situation as somehow easier than if you're battling disorganisation and discord.
  • Less credit for achievements - Inevitably when working to share collective responsibility and recognition for work there's less of a sense of personal achievement. Whilst this is both right and good, it is still a relative sacrifice when compared to the high level of individual achievements that we may have enjoyed through education and early career. It's right and good for those not in leadership roles to get the lion share of recognition for their efforts - after all being in a leadership role in itself is an ongoing reward for achievements of the past. At the same time it's important to gain appropriate acknowledgement for your achievements so maintaining a solid professional profile both internally and externally e.g. on LinkedIn is a good way of tracking your own achievements.
  • Less time for leadership positioning - Leading from alongside a team requires a much higher level of involvement in day-to-day work than high altitude command and control behaviour. This is time consuming and can result in having less time for general high level relationship building that's key to progressing oneself and influencing the higher level decisions in a company. Just as maintaining time for strategic work is important, so too is taking the time to maintain solid relationships with your peers and ensure that your close connection to practical delivery doesn't diminish your internal credentials.

What flavour respect

At the start of this post I used the word Respect to describe an aspirational goal for those pursuing leadership roles. In a literal sense this seems harmless and should be something that we should all expect and drive for. In a leadership context it's one, as I've stated above, that we fear is most at risk when we adopt a servant leadership oriented approach. Respect however is nuanced, and I'd argue that respect is a word that has negative connotations as well as positive, and I personally place much higher value on some sources of respect than others:-

  • I value respect from my teams, however I would never expect to insist that they respect me purely through my position.
  • I value respect from my peers, whilst at the same time not wanting to receive that respect for values that I don't believe in.
  • I don't believe that respect should ever come through fear, such as wielding the power of hiring and firing.

I think that with an approach aligned with servant leadership, respect comes mutually. It gets greater over time and is strengthened rather than diminished by admitting mistakes and admitting others opinions may be more valid. It is reinforced by taking on board others' ideas and including them in decisions.

Most importantly respect for the servant leader is received because it is given. For me that provides the strongest basis for deserving it, so even if the principles of servant leadership may present some challenges on the way, I don't see myself giving up on them any time soon.

References

Robert Greenleaf is probably the most notable advocate of servant leadership * A brief introduction can be found here - https://www.greenleaf.org/what-is-servant-leadership/ * A more in depth exploration of the concept here - The Servant As Leader * Interesting arguments presented here as to why the approach is not more popular - https://hbswk.hbs.edu/item/why-isnt-servant-leadership-more-prevalent



Image: https://www.globerovers-magazine.com/

Tuesday, 14 August 2018

Textual description of firstImageUrl

A Salesperson for Testing

One of the challenges of progressing in your career is maintaining the ability to admit you're still not great at some things. As you progress into more senior leadership roles it's easy to fall into the trap of getting more defensive about your shortcomings when a younger you would have been more open about them and therefore ironically more likely to address them.

As I progress in different roles I try to make sure I continually maintain a realistic sense of vulnerability and look for areas where I can continue to improve. One such area I'm working on right now is persuasive communication. I often find myself frustrated with an inability to persuade a group of my position, even if I feel that it is justified. I find that my inability to concisely persuade others is the cause of a significant amount of my work stress in not being able to turn insight and experience into influence.

Selling without knowing it

In order to try to improve on this I was recommended the book 'To Sell is human' by Daniel Pink. It's a fascinating book written around the idea that, although the number of people employed in direct sales roles has reduced, the number of people who spend their time in activities to influence and persuade others has increased such that we are all essentially salespeople in one form or another. One of the key sections of the book explores research performed on how much sales-like activity people are involved in as an inherent part of their working lives ... quite a lot as it turns out:

"People are now spending about 40 percent of their time at work engaged in non-sales selling - persuading, influencing and convincing others in ways that don't involve anyone making a purchase. Across a range of professions, we are devoting roughly twenty -four minutes of every hour to moving others."

I've never wanted to be a salesperson. I'll admin that I have harboured a certain level of disdain for sales jobs in the past, along with many of you reading this I'd dare to suggest. I felt that salespeople were a certain 'type' with potentially a higher level of extroversion coupled with a slightly lower degree of integrity than I was prepared to adopt in my professional life. They were prepared to mislead customers to a false understanding of the value that they were going to achieve in order to achieve a sale. I have in the past rolled my eyes as I tried to manage expectations with a customer after an over-enthusiastic colleague in sales has promised capabilities in our software which hadn't yet progressed beyond the white-board. How much of my opinion was informed by such experience and how much purely driven by stereotype I can't say for sure, however based on the research and analysis presented in Pink's book I'm certainly not the only one to have held such opinions.

Whilst I have always rejected the idea of being in sales, Pink provides a compelling case in his book that actually being more effective at selling is something that has benefits way beyond just sales. The ability to convince someone to exchange their resources in exchange for your product, idea or service is one that is invaluable in any role that interacts with others as part our information and communication rich on-line industry of software creation.

Selling testing

In the testing community I've long moved beyond the idea that throwing counts of test cases and completion percentages at people was an effective way of communicating the status of testing. What I had perhaps failed to appreciate, until reading Pink's book, was that I believe a lot of the value that testers can add is in selling. If selling is the process of persuading people to trade their resources for an idea, opinion or position then the testing role can require a great deal of such activity.

  • Testers sell the need to prioritise one issue over another
  • They sell the need to commit more time to risk mitigating activity prior to releasing
  • They sell the need for testability to developers
  • They sell the value of spending effort on rigour in development processes in order to reduce risk
  • They sell the reduction in scope of features in order to achieve greater confidence in a robust outcome

So, whilst we may not necessarily feel or want to be expert salespeople, to be an effective tester requires negotiation skills that would make most salespeople proud.

Reasons to be positive

Before you cry into your coffee in the realisation that you've actually been working in a sales role without realising it, there are some great take-aways from Pink's book that leave a lot of reasons to be positive.

  • Ambiverts make better salespeople - The belief that extroverts make the best salespeople is so ingrained in our expectations that it is rarely questioned - yet evidence suggests that it simply isn't the case. In actual fact there is a strong link between effectiveness at sales and level of extroversion, however the most successful level is in the middle - neither introvert nor extrovert. If you worry that to be effective at persuasion requires you to be the most gregarious character in the office - don't. Chances are if you're a tester who balances a strong analytical focus on detail with the ability to communicate with various stakeholders, you're probably better at selling than you think.

  • Salespeople with integrity are better - If we genuinely believe in the value of what we are selling then we negotiate on the basis of progressing towards a mutually beneficial outcome. Pink suggests shifting the focus from "selling" to "serving" and making sure that you believe that both parties will benefit from the transaction will result in you being a more effective salesperson.

These should be give us a lot of encouragement when it comes to 'selling' testing. To start with most testers I know fit solidly into the ambivert camp. Plus I'm confident that in the situations where I've negotiated for greater testability, or argued for the roll-back of a volatile change, then I'm striving to benefit both sides of the transaction. I'm not typically in the habit of just negotiating in my own interests or the interests of just the testers - it has always been from the position of trying to reduce risk and achieve the best outcome for everyone concerned. Just as a better salesperson who genuinely believes that what they are selling will benefit the customer, so as long as we believe in the value of our information and the decisions coming from it then we'll be better and more persuasive testers. If, however, our negotiations are purely geared towards the interests of our own roles or teams with no tangible benefit for anyone else (read this post for a great example) then we should consider ourselves no better than the stereotypical car salesman in a pie hat putting sawdust in the gearbox in order to flog a dying car.

Image: https://en.wikipedia.org/wiki/The_Market_for_Lemons#/media/File:Kovacs_special_1968.JPG

Tuesday, 19 June 2018

Textual description of firstImageUrl

How Not To Get Into Test Automation

I’m going to have a bit of a moan. I’m not inclined to rant, however this has been a bugbear of mine for a while which came up again recently. I’m hoping that sharing my thoughts will hopefully both get them off my chest, whilst at the same time providing some useful career advice for budding testers.

Here’s an example of a conversation I recently had with a candidate for a testing job

Me - So what would you ideally like to be doing in a new role?

Candidate - Well I’ve got lots of experience of manual testing so I’d like to use my experience there, and ideally I’d also like the opportunity to get into automation

Me - have you done anything so far to develop automation tooling skills?

Candidate - No, the opportunity hasn’t come up in my previous roles so ideally I’d get a role with a company that’s going to help me develop in this area

Me - Sigh.

I have lost count of the number of times I’ve had this conversation and I’ve never hired a candidate off the back of such a discussion. I’m sorry to these candidates - but if I am hiring with automation in mind then the last person I’m going to hire is someone who claims to want to develop skills in that area but has taken no steps in acquiring those skills themselves.

If I want someone to create automation tools then the characteristics that I'm looking for are typically

  • They are capable of writing code to automate tests - this doesn’t have to involve knowing a specific language - just that they can understand coding structures
  • They are capable of understanding the benefits and limitations of automating test execution
  • They are capable of self learning

If you are not able to demonstrate these skills then it's naïve to expect an employer to land you with a juicy test role where you get trained in test automation.

To be absolutely clear, I'm not in any way stating that personal development is the sole responsibility of the employee and any new skills need to be progressed in their own time. What I am saying is that the chances that I would choose to invest time and money into building the skills of an individual increase significantly if that person can demonstrate the ability to learn and improve themselves. Opportunities for self progression don't often land unexpectedly, they tend to gravitate towards those people who appear to deserve and merit the opportunity.

Teach yourself

Across my previous testing roles I've created many test tools and harnesses

  • I created a multi-server database test scheduling harness in Linux shell after teaching myself shell scripting
  • After a manager rejected my proposal to automate ODBC tests, I did it anyway, demonstrated the value and got justification to build on and maintain these
  • I taught myself java in my evenings and created two test harnesses for acceptance and load testing the JDBC interface
  • I learned Perl to output our test build results in a readable html report
  • I learned python to create a simple test harness to parse JSON to test a REST interface
  • I learned ruby to create a random SQL query generator as a side project

In every single instance I learned the language off my own back in order to add the value in what I felt was the best way. Sometimes this started with some help from developers. Other times this involved sitting up late on Friday nights starting from "Hello World" with a beer and a few web pages to get me started on the basics of the language. Now I’m not advocating that everyone spend their Friday nights working, but if you’re driven to do something and are learning new skills it genuinely doesn’t feel like work (the beer helps with that!).

The intention here isn’t to show off - after all most of these harnesses were picked up, maintained and often improved by other members of my team who developed themselves and their skills in the process. Not only that but they then went on to create their own tools - not because I asked them to but because they wanted to and because they could. And the reason that they could was because I’d hired people with a demonstrable ability to self learn to improve their skills whilst adding value.

The technology doesn’t matter...

When hiring testers I’m not interested in whether they know a specific language or tool. I am, however, absolutely focussed on finding people that have shown the ability to drive their own improvement and make opportunities for themselves. This doesn’t necessarily have to involve tool creation, however the people who I have hired for this have shown clear evidence of researching and intelligently creating or introducing tools to improve the testing in their companies.

I remember once being particularly excited about a CV that landed on my desk. The tester in question had clearly self-learned new technologies in order to demonstrate value and suggest a number of improvements in previous roles that improved testing and saved time/money. Naturally I hired this person and she went on to become one of the best testing hires I’ve ever made. That CV became my go to example when talking to recruiters about what a good tester CV really looks like (a great way to discuss tester recruitment - I call it "recruitment by example" )

... and technologies alone aren’t enough

On the flip side, I’m also very sceptical of hiring individuals who have been trained in one technology, such as Selenium, and shown no flexibility in looking outside that at other tools or approaches. Testing ain’t programming people and, whilst coding with one technology is useful it’s not what makes a great tester.

One of the best testers I’ve hired has no coding skills but has delivered great automation. She used her strong testing knowledge and relationship building skills to motivate developers to help her in introducing automated acceptance testing. The same tester also introduced Session Based Exploratory Testing to cope with a cutting of testing headcount in the business. I’d rather have a tester with no coding skills who has effected change in this way over someone that’s worked exclusively on Selenium automation for 5 years.

Don't just sit there

So that’s it - rant over. I hope that if you’re a tester who is looking for work then you take some of this on board. Don't expect prospective employers to do the work for you. Be hungry, be proactive, be a pioneer of tools and approaches in your organisation, and ultimately be prepared to take the first few steps on whatever path you wish to pursue yourself...

..oh and if you live in commutable distance from Gloucestershire UK let me know - I’m always happy to speak to you as I'm frequently looking for proactive and passionate testers to join my team.

Photos by Fabrizio Verrecchia and Etienne Boulanger on Unsplash

Monday, 4 June 2018

Textual description of firstImageUrl

The Wave of Risk Perception

I had an interesting chat with a former member of my team recently. We were in the pub and she was sharing with me her woes in a new role. The problem, as she explained it, was that the members of the leadership team in her company were pushing back against her efforts to devote development time to improving existing features, robustness and stability of the product. They were solely interested in new features. The issue seemed to be that they didn't have an appreciation of the levels of risk involved in their existing product. To help her to understand the reasons for their position I drew up a diagram that I've used in a few talks to explain the perception of risk. The conversation reminded me that I'd not written about this, so here goes...

Destined to be Different

It is not a coincidence that in many situations people close to software development, particularly testers, have a very different perception of risk than some leadership roles. One of my favourite historical blog posts is this one on why testers and business leaders inevitably differ in their perception of risk. I recommend reading that one for a deeper exploration, but to summarise here:-

  • Humans are susceptible to the 'Availability Heuristic' that leads us to attribute higher risk to outcomes which we can recall experiences or stories around. Therefore roles with greater visibility of issues that have occurred through a process, or of software problems in general, will attribute higher risk to a software release than those who have not
  • Research such as this paper has additionally shown that managers who don't have a detailed understanding of negative outcomes will aggregate multiple separate negative possibilities into one 'risk of failures' which they then attribute a lower level of risk to than is appropriate due to lack of availability.
  • The 'Affect Heuristic' means that we naturally attribute lower risk to things that we associate a strong positive outcome to, and vice-versa, so a manager focusing emotionally on the benefits of a software release for customers will typically attribute lower risk to the release than those roles with a focus on the challenges of technical delivery

These three factors combined give good cause to expect leadership roles to have a much lower perception of risk around a software delivery than testers and other development roles.

The Wave of Perceived risk

Understanding differences in risk perception is all well and good, however unless it is in understanding and recognising the potential outcomes of this disparity that the theory becomes practically useful. What would we expect to see as a result of this somewhat inevitable difference in perspectives?

When creating a talk around risk and the reasons that I came up with the 'risk questionnaire' I used the following diagram as a means to represent the scenario that can arise when there is a strong disparity of risk perception between testers and management. The idea here was to represent perceived risk over time in a tester and a product role on a new development and to explain the shape of testing that we would expect to see as a result.

Initially when commencing development what we expect to see is a large difference in their perceived levels of risk around the same situation. The perception of risk in management is low and decisions on approach and expected pace of development are driven based on this. The tester is aware of the lack of rigour in place and will have an elevated perception of risk driven by their experience of the many issues that could surface.

Inevitably one of these potential problems goes bang and the manager is suddenly and painfully aware of a specific risk.

Additional effort is justified to tackle 'the problem'. This is likely to be in the form of a process improvement or the creation of some new tests, however the scope of this work will in all likelihood be limited to covering the issue that emerged, possibly in excess of an appropriate level given the testers elevated perception of risk.

The manager is satisfied and returns to a having a lower perception of the risk situation, however knowledge of the problem does give some increased awareness of the chances of hitting problems. The Tester, on the other hand, knows that only one of the many areas of potential concern has been mitigated and their confidence is only slightly increased due to their maintained perception of the other potential negative outcomes in their process.

Inevitably another issue cross up in another area with similar consequences

over time the encountering of issues and improving testing reaches a point where, whilst not necessarily aligned, the perception of risk between tester and manager is closer and in balance with a consensus around the level of testing needed and the resulting chance of hitting issues.

The testing is likely to be formed around pockets of high (potentially excessive) coverage where risks have manifested themselves, with lighter coverage in other areas.

Surfing the Wave

I was slightly nervous when I first presented this at a conference, however I've presented this a few times now and had many testers confirming that this looks very much like the way that testing evolved in their organisation. At the last talk one audience member said it was the best way of representing this situation that he had seen.

The same person asked an interesting question - given the choice would you reduce the amplitude or the frequency of the curve? To rephrase - is the way to tackle the problem to reduce the number of issues or the difference in perception to start with? For me the two are separate but go hand in hand, and it is necessary to address the second to justify focussing on the first. Working towards a more common perception of risk between roles will not in itself reduce the problems encountered. Without addressing this disparity, however, it can be hard for testers to establish and justify a level of rigour around development required to do so. Such a change for a manager with a low perception of risk would appear to be an increase in development time and cost for little benefit. If we want backing to improve testing, without just bouncing from issue to issue to justify point improvements, then helping to establish a more consistent perception of risk is clearly a key area to focus.

The good news here is that, from our understanding of the causes of the difference in perception, we have a great starting point in understanding this might be achieved. I identified at the start of this post three biases that impact our perception of risk that we can act to influence.

  • Tell stories to convey risk information. Human risk perception simply isn't driven by the logical brain processes that deal with facts and figures. Risk perception is influenced far more through 'availability' of stories and experiences that convey the potential for negative outcomes. My personal experience supports this - one excellent example involved a conversation with a CEO once around improving data security that I was expecting to be a challenge, however he had just recently read an article on a data breach from a similar company which made headline news, and he was therefore very open to addressing the risks in that area.

  • Don't aggregate all conversations on issues into 'bugs'. Discussing different potential problem areas separately will help to establish a more realistic understanding of the multiple negative outcomes that could arise in our development. Actually discussing these collectively as bugs could result in an under-appreciation of the different risks in those not close to the details of the development.

  • Include testers early in value conversations - Testers are often excluded from early conversations around developments, and are only brought in when the solutions are scoped. Yet it is in those early conversations that the real value of the development is established and discussed. It carries then that one positive way to avoid the curve by influencing their own risk perception is by getting themselves involved from the start and understanding the value that each development could deliver.

It is worth remembering here that our focus needs to be on establishing a realistic and consistent perception of risk across roles, which involves more than just increasing awareness of risk in management. Despite the superpowers to find issues and save projects, testers are only human and just as susceptible to biases in their risk perception as everyone else and the tester's default position is as likely to involve over-estimation of risk as management roles are to under-estimate.

A key element to the testing role is to understand the biases that can influence the perception of risks in our own roles as well as others. Understanding these can provide the key to being able to have genuinely influential conversations with business leaders in ways that will effectively convey risks in a way that is meaningful to them, and hopefully avoid the painful process of progressing up the wave that comes when different roles start from very different perspectives.

https://www.pexels.com/photo/action-beach-fun-leisure-416676/

Monday, 23 April 2018

Textual description of firstImageUrl

An Emotional Journey

Of all roles in software development, the Product Owner is one that I find is most at risk of positive biases around their software. When creating a product there's a natural tendency to be overly optimistic around the positive reception that it will get from its target user community. I am in the process of developing an innovative new engagement and productivity product in my company and naturally am very excited and optimistic around the benefits of will give. As my colleagues and I started out in this endeavour we wanted to make sure we included a consideration of potential negative feelings into our development process - and our UX (User eXperience for the uninitiated) specialist came up with a great way of doing this...

Getting into UX

One of the things that I've found most rewarding in moving to Web and mobile work after many years of being in a world of APIs and command lines, is learning more about UX. I maintained an interest in UX during my years working on big data, but the absence of significant front end development work left this as a secondary concern to those of accuracy, scale and performance. The last two years working on Web and mobile technology has given me the opportunity to make up some ground on the UX learning curve - a process which has been accelerated thanks to the enthusiasm of our in-house UX team.

When we decided to create a product that attempted to bring together the worlds of data and employee engagement, the importance of establishing the right emotional connection with users was paramount to ensure the team experience of using the product was empowering rather than intimidating. In chatting with the UX specialist working on the product, who I'll call Phoebe, we discussed the need to identify the emotions that we wanted to promote in using the product. On the flip-side we also talked about the emotions that we did not want to promote, and how useful it would be to identify some of these up front so that we could design with these in mind.

An Emotional Journey

Phoebe had the bright idea of running an 'emotional user journey' workshop to help flush out both positive and negative emotions that could arise at key points through the process of using our product. This was something neither of us had done before but seemed like a great for for what we were trying to achieve.

The starting point was getting the right mix of people in the room. We pulled together a combination of Development and Commercial roles as well as some of the senior client services and Product Ownership people from our successful bespoke engagement and data programmes.

  • Phoebe started by presenting the different user personas that we had created for the product, explaining the personalities, pet hates and goals of each one.
  • She then progressedd to map out the primary elements of the flow of product behaviour that we had identified as our core journey.
  • At each stage she placed some leading 'question' cards with questions to make the attendees think about the emotions that the people and teams using the product might feel at each stage.
  • Phoebe then split the attendees and invited individuals to consider the journey from either a very positive and optimistic, or a very negative and cynical position.
  • These two sets of individuals added emotions to the journey at the key points - one colour of card for positive and one for negative emotions
  • At points where the cards were concentrated, we placed further cards to highlight the ideal emotions that we would want to promote to help avoid any potential emotional pitfalls that had emerged.

What was fascinating about the session was that, as the emotional cards were added to the wall what emerged were a small number of critical 'fulcrum' points which had the possibility of a engendering very strong emotions, but also risked very negative ones. Some areas that we had assumed would promote a positive response around visibility and openness actually had a high level of risk of people feeling exposed and monitored or judged. Additionally a strong set of potential emotions emerged around the product as a whole emerged around how people might feel if it was put in front of them. What we realised was that, without our perspective on the potential benefits there was a risk of suspicion around new business technology and its potential for 'big brother' monitoring that we needed to consider and mitigate with our product features and messaging.

Emotional Take-Aways

The workshop provided some invaluable insights into our target product from the perspective of the people who would be using it. Identifying the main points that carried the greatest emotional risk allowed us to focus on those areas to ensure that they encouraged the responses we were looking for. Through the development of the initial features we tailored our approaches to specifically include steps to encourage open and democratic behaviours and discourage command-and-control, autocratic ones. Our awareness of the general risks around the perception of new products was also empowering in ensuring that we provide the right support and messaging to back up the benefits that our product can provide.

Our company brand and sales and marketing collateral all carries the messaging our software and services are for everyone in a company, not just managers. With the help of the insight that came out of the emotional journey session, we're ensuring that this is a message that is reinforced rather than put at risk as we build the product features.

References

We didn't use it in the session but here's an interesting post by Chris Mears on using Robert Plutchik’s emotion wheel to measure emotions through user journeys that I would consider using if repeating the exercisehttps://theuxreview.co.uk/driving-more-valuable-customer-journeys-with-emotion-mapping-part-1/

Photo by Kasuma from Pexels

Monday, 19 March 2018

Textual description of firstImageUrl

Disruptive Work

Just over a year ago I instigated a move in my company to stop recording bugs. It was a contentious move, however it seemed that for the context in which we worked - tracking bugs just didn't seem to fit. I'd planned to write about it at the time but wanted to see the results first. In light of some recent internal discussion in my company in favour of re-instigating bugs, now seems like as good a time as any to write about what we do instead.

A scheduling problem

My current company, River, has historically worked on an agency basis. Rather than having development teams devoted specifically to one product or feature area, each team will have their time allocated on a sprint-by-sprint basis to one of the client programmes that we develop and maintaining software for.

This presents a number of challenges to effective agile development, probably the most significant being scheduling work. When product teams work in agile sprints they commit to delivering a backlog of work for each sprint. Inevitably I my experience sometimes things didn't always go as planned and work may need to be brought into a sprint that has come in urgently from another channel such as a Proof of Concept (POC) or the customer support team. In product teams I've worked on there was always an understanding across the business that these disruptive items would impact on the teams ability to tackle its scheduled work and subsequent sprints would be affected. As all of the sprints related to the same product this was manageable - we may have had to reduce the scope of a long term release deliverable, but for the most part the work could be absorbed as an overhead of the long term development work of the team.

The challenge we faced at River with the agency model was that for any given sprint for a team there was a good chance that the work would be completely unrelated to what they had done in the previous one. Any items being raised through other channels such as ad-hoc customer requests or support tickets may have come from a different programme from the one that was the subject of the active sprint and therefore the emergent work could not simply be slotted in to the team backlog at the appropriate priority level.

We saw some challenging tensions between undertaking new planned developments and maintaining existing programmes. I'd personally struggled to make progress on two high profile projects due to the impact of disruptions from existing ones, so I was keenly aware of the impact that unplanned work could have. A particular problem that I'd encountered was issue snowballing. As one sprint was disrupted by unplanned work, it would inevitably have a knock on effect as promised work would be rushed or carry over and impact a later iteration. Timescales on the new programme would get squeezed resulting issues on that programme, which would consequently come in as disruptions which impacted on later sprints..

Being Careful with metrics

Last year across the development group we set about establishing a set of meaningful goals around improving performance. Years of working in software testing provides me with a strong mistrust of metrics and I was keen to avoid false targets when it came to striving to improve the quality of the software. I'd never suggest that counting bugs provided any kind of useful metric to work to, however I did feel that examining the amount of time spent on bugs across the business could provide us with some useful information on where we could valuably improve and so I set about investigating use of bugs across the company.

What I found on examining the backlogs of the various teams was that each team took a different approach on recording bugs. Some teams would capture bugs for issues they found during development, others would restrict their 'bug' categorisation for issues that had been encountered during live use. Some teams went further and raised nearly everything as a user story - yielding such interesting titles as "As a user I don't want the website to throw an error when I press this button".

I and the group involved in looking at useful testing metrics took a first principles approach by taking a step back from what to track on bugs and actually understanding the problem that we were trying to solve. Whilst obviously the absence of bugs was a desirable characteristic in our programmes, more importantly was reducing the amount of disruption encountered within teams relating to software that they weren't working on at the time, whatever the cause and so we decided that looking at disruptions would give us more value than looking at bugs alone.

The Tip of the Iceberg

What became apparent was that the causes of disruptions went far deeper than just classic 'bugs' or coding flaws. The work that was causing the most disruption included items such as ad-hoc demands for reports from customers that we weren't negotiating strongly on, or changes requested as a result of customers demanding additional scope to that which had been delivered. I would have been personally happy to consider anything that came in this way as a bug, however I'm politically aware enough to know that describing an ad-hoc request from an account director as a 'bug' might be erring on the side of bloody-mindedness.

The approach that we decided to take was to categorise any item that had to be brought into an active sprint (i.e. something that had to impact the current sprint and could not be scheduled into a future sprint for the correct programme) as 'disruptive'. The idea was that we then track the time spent in the teams disruptive items and then look to reduce this time by targeting improvements, not just in the coding/testing, but in all of the processes that impacted here including prioritisation, product ownership and customer expectation management. A categorisation of a 'bug' was insufficient to identify the range of different types of disruptive work that we encountered. We therefore established a new set of categories to better understand where our disruptive backlog items were coming from :

  • Coding flaws
  • Missing behaviour that we hadn't previously identified (but the customer expected)
  • Missing behaviour that we had identified but hadn't done (due potentially to incorrect prioritisation)
  • Missing behaviour that would be expected as standard for a user of that technology
  • Performance not meeting expectation
  • Security vulnerability
  • Problem resulting from customer data

Each item raised in the backlog would default to be a 'normal' backlog item, but anything could be raised as 'disruptive' if a decision was made to bring it in to a team and to impact a sprint in progress.

Did it work?

After over a year of capturing disruptive work instead of bugs we are in a good place to review whether it worked. Typically and frustratingly the answer is both yes and no.

Some of the things that did really help

  • No-one argued any more about whether something was a bug. I have gone over a year in a software company without hearing anyone argue about whether something was a bug or not. I cannot overstate how important I think that I has been for relationships and morale.
  • We don't have big backlogs of bugs. The important stuff gets fixed as disruptive. The less important stuff gets backlogged. At my previous company we built up backlogs of hundreds of bugs that we knew would never get fixed as they weren't important enough, treating all items as backlog items avoids this 'bug stockpiling'.
  • All mistakes are equal. I've always disliked the situation where mistakes in coding are categorised and measured as bugs but mistakes in customer communication that have far bigger impact are just 'backlog'. There is a very murky area prompting some difficult conversations when separating 'bugs' from refactoring/technical debt/enhancements. These conversations are only necessary if you force that distinction.

What didn't work so well

  • People know where they are with bugs. In many cases they are easy to define - many issues are so clearly coding flaws that categorising them as bugs is easy and allows clear conversations between roles simply down to familiarity with bug management.
  • There was still inconsistency. As with bugs, different teams and product owners applied subtly different interpretations of what disruptive items were. Some were treating any items that impacted on their planned sprint as disruptive, even if they related to the programme that was the subject of that sprint, others only raised "disruptives" if the work was related to a different programme.
  • The disruptive category led to a small degree of gaming. Folks started asking for time at short notice to be planned into the subsequent sprint rather than the current one. This was still significantly disruptive to planning and ensuring profitable work, however it could be claimed that the items weren’t technically "disruptive items" as the time to address them had been booked in our planning system.

In Review

Right now the future of disruptive items is uncertain as one of the product owners in my team this week raised the subject of whether we wanted to consider re-introducing bugs. Although I introduced the concept I'm ambivalent on this front. Given the problems that we specifically faced at the time, tracking disruptive items was the right thing to do. Now that we have a larger product owner team and some more stability in the scheduling disruptive work is not the debilitating problem than it was. At the same time I'm not convinced that moving back to 'bugs' is the right move. Instead my inclination is to once again go back to first principles and look at the problems that we are facing now, and track appropriately to address those, rather than defaulting to a categorisation that, for me, introduces as many problems as it solves.

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.

ShareThis

Recommended