Skip to main content

Keystone Habits

Now I have changed how I am going to structure these posts on habits. In this post I am going to talk about  Keystone Habits.

Now a keystone habit is:

"A habit that has the power to start a chain reaction, changing other habits along the way."

Now this may sound simple but keystone habits can be very hard to identify. They are often what people would call small wins. Let me give you a real world  example of a keystone habit.
There is a company in America called Alcoa who are the 3rd highest producer of Aluminium in the world. Paul O'Neil was appointment as the new CEO back in 1997 and after his appointment there was a meet and greet between Paul and the shareholders. Paul took the stage and started to talk about safety. This shocked a few of the investors as they were probably expecting some clique filled speech about how profits would increase and how he would 'streamline' the business. Now you may think the same as the shareholders, that it was a little odd, and on the face of it you would be right. However this focus on safety was to have a massive effect on the company and improve the stock price considerably. He implemented a culture where all accidents had to be reported to him within 24 hours and employees were encouraged to suggest safety recommendations.

When Paul retired in 2000 he had managed to increase Alcoa's stock price by 200%. By focusing on safety, other habits began to surface, below is an example:

The Alcoa plant that manufactured aluminum siding for houses, for instance, had been struggling for years because executives would try to anticipate popular colors and inevitably guess wrong. They would pay consultants millions of dollars to choose shades of paint and six months later, the warehouse would be overflowing with “sunburst yellow” and out of suddenly in-demand “hunter green.” One day, a low-level employee made a suggestion that quickly worked its way to the general manager: If they grouped all the painting machines together, they could switch out the pigments faster and become more nimble in responding to shifts in customer demand. Within a year, profits on aluminum siding doubled. The small wins that started with O’Neill’s focus on safety created a climate in which all kinds of new ideas bubbled up. “It turns out this guy had been suggesting this painting idea for a decade , but hadn’t told anyone in management,” an Alcoa executive told me. “Then he figures, since we keep on asking for safety recommendations, why not tell them about this other idea? It was like he gave us the winning lottery numbers.”

Duhigg, Charles (2012-04-05). The Power of Habit: Why We Do What We Do, and How to Change (pp. 117-118). Random House. Kindle Edition.

By changing just 1 thing Paul O'Neil managed to transform an entire company. The focus on Safety was a keystone habit. From that keystone habit other habits were formed which helped the company grow and develop.

Now how can we relate software testing to keystone habits?
Well its not an easy answer. For example a keystone habit in your personal life may effect your testing, so identifying them can be very difficult. To help, below is a habit I believe is one of my keystone habits and one that effected my testing in a positive way:

Keystone Habit
Making sure my sure any notes I make in my notebook are clear and readable

How it changed my testing
When I raised issues in our bug tracker, occasionally the detail of these issues was a bit sparse and sometimes the developer would need extra clarification from me. By making clearer written notes I have found that issues I raised were more detailed, which in turn do not require as much clarification from me to the developer. This meant that developers would not need extra explanation from me which in turn would lead to more time for them to write code and more time for me to  look for issues. Also as my notes were neater I found out I remembered more from meetings and client discussions and this helped me to understand clients needs more and I could take this extra knowledge into my testing.

How do Identify Keystone Habits
The hardest thing about keystone habits is identifying them and identifying them can take a lot of time. One bit of advice I would give is to see how you can make small wins, so for example making sure when you raise issues in your issue tracker that the steps you enter are clear and  concise. I'm not saying that doing this will improve every aspect of your testing but I hope you get the idea. They key thing is to keep looking for small wins .

Once you have tried a few small wins hopefully you will see other aspects of your testing change which will have a positive effect, These positive things could be things like:
  • Improved communication with other team members
  • Better relationships with Team Members
  • Improving your testing skills
The list could go on and on and can keep growing as you find more and more small wins that are Keystone habits.

 If you notice that the keystone habit have a negative effect on your testing,  then stop and try and find another one. Not all habits are good so just be aware and observant of how you work after you have found a small win.





Comments

Popular posts from this blog

How to deal with pauses and timeouts in specflow

So this blogpost is in response to the weekly Specflow blog posts and challenges that have been written by Gojko Adzic. This weeks challenge was how would you rewrite or rephrase the below scenario: Given a user registers successfully When the account page reloads And the user waits 2 seconds Then the account page displays "Account approved" My initial though was something like this: Given a user registers successfully  When the account page reloads   Then the account page is displayed within a satisfactory time period     And the account page displays "Account Approved" Now the problem with this scenario is what defines a satisfactory time? You could add it as a comment or in a scenario outline but over time the time a user waits could change and if this is updated in the code behind but the scenario outline or comments are not, then what the test does and what is described do not match - this would potentially cause issues in the future. My next ide...

Benchmarking in C# - Simple Job attribute

In this post I am going to continue my servies on BenchMarkDotNet and I will explain what the various parameters do that are present in the simplejob attribute.  Now I say all....... the documentation is not great so I will explain what 3 out of the 4 do :) So If you remember in my previous post I had a MyFirstBenchmark class which contained the details about the benchmark test that I wanted to run. In this class there is an attribute called SimpleJob and this attribute contains a few parameters that can be configured when you run a test.  By default BenchMarkDotNet will choose the number of iterations that will return the best precision. However, using the simplejob attribute allows you to quickly get a set of statistics. Below is how my test was setup: Now as you can see I had the following parameters in the SimpleJob attribute: launchCount - This parameter allows you to define how many times the benchmarking test is run warmupCount ...

Monitoring and Observability

In this post I am going to talk about monitoring and observability. Now what are monitoring and observability? Monitoring is defined as….. "to watch and check a situation carefully for a period of time in order to discover something about it" From <https://dictionary.cambridge.org/dictionary/english/monitoring> Observability is defined as….. "to watch carefully the way something happens or the way someone does something, especially in order to learn more about it" From <https://dictionary.cambridge.org/dictionary/english/observe?q=Observing> So the main difference between the 2 is that one is around checking to discover something whilst the other is about watching something in order to learn more about it. Why are both important? They are both important as they can tell us different things about a system and can provide us with information that can feed into decisions and actions that can be made both now and in the future to improve software quality as ...