Category: Tips

3 traits of Self-leadership

A colleague of mine Qambar Raza recently shared this great Ted talk with me on self-leadership 👏

🎥 🍿🥤 Great leadership starts with self-leadership | Lars Sudmann

In it Lars describes three behaviour traits to improve your self-leadership:

1. Self awareness
2. Self reflection
3. Self regulation

This is a brilliant way to change any personal trait that you would like to be different.

The key to it is Step 1 by recognising what you do want, how that differs to what you do now and then identifying the incremental steps towards it.

The difficulty comes in Step 2 being honest with yourself everyday about how you are progressing towards your goal and what feedback mechanisms you are using.

Finally Step 3 is recognising that situations outside of your control will still occur where you might default back to your existing behaviour. So instead of trying to repress your response reframe how you look at the situation instead that enables you to look at the situation in a different more positive mindset .

Don’t know where to start yourself improvement journey then start by identifying some of the default behaviours you might exhibit.

Three things of 2020

3 minute read

Below are three things that when I reflect back on 2020 that stand out to me. I’ve purposely not mentioned COVID because I think this is one thing that all of us would have on our list so didn’t think there was anything more I can say on this that no one else is already thinking. I’ve also included my three things from 2019 at the end which I still think are important. 

🌳 You can’t stick your apples on other people’s trees

  • Something that Sarah has been trying to tell me for some time but it never really clicked until this year 💡
  • I’ve learned a lot this year about how we learn and what we can do to enable more or it
    • My apples…
  • But there is one thing that keeps coming back
  • It doesn’t matter how many different ways you find to engage people with the content
    • Unless they really care about it they may never have the insights that you think they should have 
    • They may never see the benefits you do or incorporate that that information into their ways of working 
    • This is all about trying to stick your apples on other people’s trees…
  • Usually they are just too busy to even be able to give it the time 
  • The best approach is for them to find ways to incorporate into their own learning 
    • To encourage them grow their own apples…  
  • This takes a lot more time than simply forwarding a link to read or even sending them on workshops/training courses… 

Speaking of apples…

🍎 Informal Relationships

Informal Relationships between team members is the key foundation for high performing engineering teams

  • Most teams members can work with each other quite efficiently but the level with which we do makes the difference between low and high performing teams 
  • We can cooperate and coordinate quite well as can be seen by how well teams can slice up work into tickets and hand them off to the next stage (cooperating). Some teams take this further and begin coordinating their actions using information from their step in the process to inform the next stages (coordinating)
  • But coordinating with teams members isn’t enough we need to be able to collaborate because of the level of complexity we work in means no one person can ever know it all. This essential and often forgotten detail makes team members interdependent 
  • It’s the level of how well we can collaborate and work through problems that gets teams towards higher levels of performance. This performance can be measured by how sustainably the team can deliver end user value (throughput)
  • Psychological safety plays a big part in this interdependence and collaboration and can be characterised by how well people in the team can “just talk to each other” 
    • Psychological safety being the belief of individual team members that it is safe within their work environment to take interpersonal risk 

🎓 Learn more: Fundations of great teams? Start with relationships

🍏 Manager or Leader? 

Understanding the difference between the two can be really helpful  

  • One of the things that has really stood out for me this year has been the difference between management and leadership
  • I always conflated the two and never really appreciated the difference
  • Since then I’ve not looked at software engineering teams the same again
  • Do other make the same mistake? 
    • Leading to confusion on when we should be leading our teams and when we should shift to a more management style 
  • A Hybrid model may also be workable 
    • especially the closer you get to where the work is happening 
    • With a heavy slant towards leadership then management 
    • But the further you get from it the more a leadership style works best 
  • A simple heuristic: 
    • the less experienced a member of staff then a more hybrid approach 
    • but the more experienced they are then a more leadership style is appropriate  

Three things 2019

Teams

  • Working as a team will accomplish more than just working alone 
  • I’ve tried and accomplished some things with some good results 
  • But nothing compared to what I’ve contributed to as a team
  • But it starts with trust… 

Trust 

  • that people really do know what the best course of action is
  • They just sometimes need help thinking things through 
  • Which needs people to listen…  

Listen

  • And I mean really listening
  • This has by far been the most important thing I’ve done this year
  • Just asking very open questions and listening to what people say 
  • I’ve learned more about people and what is happening in our teams from this than any other way 
  • The interesting thing is the people I’ve listened to seem to get so much more out of it 
    • I think this is because not many of our team members get a chance to be listened to… 

What are your three things for 2020?

Let me know in the comments below

My biggest takeaways from AgileTD 2020: The future of testers isn’t in automation or testing

I was lucky enough to speak at AgileTD this year and also attend some of the talks. These are my main takeaways from the conference based on the talks that I was able to make.

My confirmation bias sense is tingling with this but…  

The future of testers is not in automation or testing – it will play a part but not as big as – helping teams build quality-in.  

Most teams see testing as either bug hunting or just another cost centre that needs eliminating. Therefore testers (at all levels) need to get much better at communicating the value of testing.

As testers we need to start shifting our skill set from doing the testing to advocating for testing within teams.

The skills we need to develop will take time to build as it’s not a matter of just attending training but having hands on experience of using and applying the skills.   

Otherwise testers risk becoming irrelevant in teams that begin to form without the need for testers if (or when) the next shift happens.

What is working in our favour is the slow shift to adopt new development ideas such as those expressed in Accelerate. But also teams figuring out how to really collaborate and not just cooperate. Think of the dance of passing tickets around that happens in a lot of development teams.

Which talks should you take the time to watch?

So which of these talk further lead me to believe the above. Let me break it down:

The future of testers is not in automation or testing

That is not to say it will go away, but it will not be the main objective of our roles.

Is not automation: Automation Addiction by Huib Schoots and Paul Holland (Day 1)

  • A lot of people’s addiction to automation appears to come from automation tool manufactures marketing (promising the world) and sunk cost fallacy (making it hard for people to stop once they’ve started). I’d also add peoples job spec also asking for automation with no rational as to why they want it
  • It is good for some things, generally things we know how they should behave and especially when we can isolate them from the UI.
    • UI’s can behave in unpredictable ways so not always the best place to put automation that needs to be consistent and reliable
  • So what do you do?
  • Focus on teams and start small: 
    • (Focus on) exploratory testing,
    • (Start small with) a good test strategy that includes what is and is not to be tested
  • Automation should be focused and isolated

Is not testing: Let it go by Nicola Sedgwick (Day 3)

  • We as testers need to let go of testing and start focusing on how we help teams understand what quality is and how they build it in
  • Nicola does this by being a Quality Coach and using Quality Engineers embedded in teams to help them mitigates the risks
  • This was a great talk and something lots of others have been advocating.
  • I think we still need to better define the Quality Coach and Quality Engineer roles but we have to start somewhere
  • I’ve written a little about what testers could do next
  • You can also learn a more about Quality Engineer from my TestBash Manchester talk (paywalled)

Also see

  • Testing is not the goal! By Rob Meaney (See below for more)
  • Beyond the bugs by Rick Tracy (See below for more)

Communicating the value of testing

How to pitch and value testing properly in the age of DevOps by Bjorn Boisschot (Day 1)

  • A fairly simple and affected approach to getting the test team behind a testing vision that they can then use to describe what it is that they do.
  • Rather than the typical dry approach of traditional testing (test scripts, reports, bugs) which all reinforce the bug hunter viewpoint of testing
  • This gets testing focused more towards what the organisation is trying to do (think company mission statement) and focuses the testing vision towards that
  • This helps others understand that it more then just bug hunting but about helping make decisions on the quality of the products and how they affect end users
  • His approach was to create a testing mission based on the company vision statement. With a focus on the why of testing and not the what or the how (see Simon Sinek: Start with why). From there they created a number of goals that would help them achieve that mission. Then they used the goal, question, metrics technique to make it measurable.
  • For some in the org this approach made testing much more accessible and greatly improved their view of it.
    • But for others, well, they still didn’t care 

Beyond the bugs by Rick Tracy (Day 3)

  • As senior members of the test team we need to help our testers understand what value they bring to teams. Then give them the tools (verbal and written communication skills) to make their value relatable to other roles. Otherwise they are very likely to be seen as bug hunters and a cost that can be eliminated.  
  • Really fascinating talk where he showed how everyone outside of testing views our roles (bug hunters that cost money). He then showed how we need to cover three main arguments for others to see the value we bring. These being conceptually (does it make logical sense to them) practically (how can they/others use it) and monetary (what does it cost and what’s the ROI). 
  • He then applied these three arguments to different testing scenarios from doing no testing at all to shifting testing as far left as possible and doing it earlier and earlier in the process. Through this he showed how the initial investment in testing increased but would dramatically decrease the costs later on in the process due to issues being found earlier and therefore easier and cheaper to fix.
  • This all reinforced the idea that testers do much more then add costs to projects and finding bugs. Such as 
    • Manually finding issues that would otherwise affect users 
    • Testing earlier on in the process before code is written by testing requirements and designs to prevent issues entering into the systems earlier
    • Raising levels of team understanding in the product, the processes they use and potential issues that is could be introduced 
    • Types of risk that could affect the team and acting as a type of insurance of that risk 
    • Making testing relatable to non testers 
    • Providing sources of information for innovation and improvements within the teams ways of working 
  • But all of this doesn’t just happen. You have to invest in your testers (and them in themselves!) for them to be able to do this such as their technical skills, improving their awareness, understanding risk, alignment with the org etc. IMO: If you keep testers ‘dumb’ and just bug hunting then that is all you will get 
  • He then linked this investments to potential measures so you can see if your investments was paying off and a way for testers to see improvements. Cycle and lead times where two areas that came up quite often 
  • These measures where then linked to business value. Two main ones being faster time to market and improved customer trust in the product. 

The skills we need to develop

These skills are not limited to just these talk but are great examples of what they are

How to keep your agility as a tester by Ard Kramer (Day 1)

  • Great talk about how he uses the 4 virtues of stoicism to be a better testers. I actually think this would help a lot of people within development teams so if you’ve not heard of it before I recommend checking it out. 
  • This looks like a good resource https://iep.utm.edu/stoiceth/ but this talk focused on just the 4 virtues of wisdom, courage, justice and moderation 

Also see 

  • Extreme learning situations as testers (Day 3)
  • How to keep testers motivated by Federico Toledo (Day 3)
  • Beyond the bugs by Rick Tracy (See above)
  • Testing is not the goal! By Rob Meaney (See below)
  • Introducing psychological safety in a tribe (See below)
  • Growing Quality from Culture in Testing Times by Tom Young (See below)
  • Faster Delivery teams? Kill the Test column by Jit Gosai (See below)

Adopt new development ideas

Testing is not the goal! By Rob Meaney (Day 2)

  • From  testability > operability > observability and his journey with his learning with these techniques and how teams have be able to make use of them.
  • I think one of the really interesting points he made was understanding where your team is in their development life cycle.
    • Are they just starting out or are they an established team and product.
    • Depending on where you on this cycle will affect to what level you will need testability, operability and observability.
    • As the three things are about managing complexity and when you are starting out complexity isn’t the problem, product market fit is. 

Also see

  • Faster Delivery teams? Kill the Test column by Jit Gosai (See below)

How to really collaborate and not just cooperate

Growing Quality from Culture in Testing Times by Tom Young (Day 1)

  • Great story from Tom Young on how the BBC news mobile team have grown over the years and how focusing on their team culture has been one of the best ways to build quality into their product. All they way through the talk Tom shouted out to how the whole team help deliver their product

Faster Delivery teams? Kill the Test column by Jit Gosai (Day 2)

Introducing psychological safety in a tribe by Gitte Klitgaard and Morgan Ahlström (Day 3)

  • Hearing how other people have tried to address psychological safety in organisation was very interesting. There was a lot in the talk that I recognised from Amy Edmundsons work (Teaming and Fearless organisation). They didn’t use Amy definition of what psychological safety is but from what I’ve seen all the definitions are almost the same. Simply put are people willing to take interpersonal risks within group settings. If so they have psychological safety if not then they are considered lacking it. 
  • The things that stood out for me was that all these types of initiatives take time and constant work. They are not things that you run a workshop, take a few questionnaires and you have the safety.
  • Also psychological safety is very personal thing so what one person feels is not the same as another in the same team. 
  • There is also a lot of misconception around psychological safety in that people feel that in psychologically safe environments will no longer have any conflicts and is all about everyone being comfortable. This is not the case.
    • PS environments are about being able to share your thoughts and ideas without the worry that it could be used against you in some way.
    • The main reason for PS is to establish environments conducive to learning from each other – which is what is needed for the knowledge work that we do 
    • But to learn effectively your need some level of discomfort
    • Too much discomfort and it can tip into fear which causes the flight or flight response  
      • and you’re not learning anything other then self protection 
      • The best way to protect yourself? Don’t say anything that could lead to a situation that causes conflict… 
    • So PS environments are about people being able to work through conflict productively that can lead to new insights and ideas

There was many, many more talks at the conference (perhaps too many) that I wasn’t able to make and thats not including the workshops so it is worth looking through the programme and seeing what stands out for you.

Think I missed a talk that should be in the list above let me know in the comments.

What is it about that particular talk that makes you think it should be included?

What above do you disagree with?

August – Toread

31st August

📻 How Can You Stop Comparing Yourself With Other People? If you manage people then this podcast is worth a listen. Having a better understanding of why we compare ourselves to others (social creatures living in hierarchical structures) and what issues it can cause (de-motivation, decreased self-esteem and confidence) can help you from stop doing it but also help you help your reports from falling into the trap. They also cover some biases that can lead to it such as casual inference and narrative fallacy.  

💪 How Resilience Works  The post calls out three traits for resilience: 1. A grasp of reality 2. Life has a purpose (for you) and 3. An ability to improvise. I’ve not see resilience called out like this before but there are some good anecdotal stories in there and in broad strokes I agree with it. But like a lot of things with the mind its easier said than done. Especially when you’re in the thick of things going wrong. (Book to add to the reading list: Mans search for meaning)

🍏 How Apple controls the App Store and therefore the end users How Ben explains the App Store Integration in stages is really interesting and key to understanding how Apple has so much control over developers and users. This is a long read but worth it to understand Apple’s almost unbelievable control of developers and users. If you want to access Apple’s users then you almost have no choice but to do as they say otherwise they can revoke your certificates and cut you off in a instant. The thing is this integration is so complicated most people are either not going to understand it or take the time to figure it out. This is very different to how Microsoft controlled Windows. 

17th August

🗺  Things Jobs said I’m no Steve Jobs fan (in the literal sense of the word) but no one can deny he helped create some incredible products. Every so often I read these quotes from him and depending on what’s going on in my work life they take on a different meaning. But one that always stays with me is this one: “You can’t connect the dots looking forward; you can only connect them looking backwards. So you have to trust that the dots will somehow connect in your future. You have to trust in something–your gut, destiny, life, karma, whatever. This approach has never let me down, and it has made all the difference in my life.” 


🏌️‍♀️The Beginner’s Guide to Deliberate Practice What is it? Deliberate practice requires focused attention and is conducted with the specific goal of improving performance, while regular practice might include mindless repetitions. But its not that simple deliberate practice requires that you break down the task into small sub-sections and practice each one till you get better. This is easy if the domain you’re trying to learn is well known, but if it doesn’t have any existing training that you can make use of or you don’t have access to trainers that can help (e.g. mentors or coaches) than you might struggle. I believe this is why it is always a good idea to learn from multiple sources when skilling up in something new that pushes you out of your comfort zone in different ways. If you’re learning something just from one source then keep in mind that it might be one sided…  

10th August

🎼 What software teams can learn from music masterclasses Via twitter from ‪@katrinaclokie.‬ Feedback is by far one of the best ways you can learn and Helen makes a great point in that software teams can learn a lot from music masterclasses and studio classes too. Both are great ways to get feedback from more established artists, peers and teachers. But also from peers in different disciplines who can give a viewpoint that your own peer group might not be able to. Another key point Helen makes is that giving and receiving feedback is a skill and as such needs to be practiced to really help people. I don’t think we do this enough in software teams and when we do it’s not always the best. There is a lot we can learn from artistic masterclasses as an industry which I guess reflects the maturity of their professions and the relative youth of ours. 


🚽 Code Coverage Best Practices This post from Google testing on the toilet series makes some great points on how code (or test) coverage can be a useful metric for teams to use. The biggest one being about how it highlights code that isn’t covered by tests. This is the perfect opportunity for teams to discuss if it should or shouldn’t. Also the advice on using it to inform on conversations topic for code reviews per commit it also a really good idea. But as the articles points out going straight in with “We should use code coverage!” is probably not going to get you very far. Most engineering teams have been burnt pretty badly by it in the past with developers just trying to hit numbers or it being used to measure the effectiveness of them. Both of which lead to the wrong incentives of number gaming rather than productive conversation starters on what are good and bad tests for your context. 


🐦🧵 Everything you needed to know about 2+2=5 Kareem makes a great point that it’s all about context. If you’re thinking just about raw numbers then 2+2 =4 but if the context was say a male cat and a female cat give it some time then could quite easily be 1+1=8. Numbers are an abstraction of the underlaying reality therefore context matters when you’re looking at numbers. One to ponder the next time you’re looking at statistics 🤔


📹  What is white privilege? Via BBC Bitesize from psychologist John Amaechi. This short 3 minute video does a really good job of explain what privilege is and what white privilege in particular means.It’s not that white people have it easy or struggle any less than people of other races. It’s that their struggles are not going to be about their race where as race can be an additional limiting factor from people in the BAME community. In short white privilege means your skin colour will not be used against you.  

At the intersection of software, technology and people 

Things I’ve been reading this week that I’ve found interesting or intriguing.

July – Toread

At the intersection of software, technology and people 

What is this?

Things I’ve been reading this week that I’ve found interesting or intriguing. Sharing because I thought you might like them too. Most of the links will revolve at the intersection between software, technology and people – with the occasional testing slant. I aim to update them weekly, with some commentary on my thoughts and findings. Feedback always welcome 😁

📬 Latest post what do testers do next if the risks mitigated by manual testing can be reduced through other means? Is it about moving more towards creating a quality culture and if so what do you need to know?

📝 My notes on Kind and Wicked learning environments and how they affect your ability to pick up skill.

Some more notes on a really interesting idea from Eugen Wei on Invisible asymptote. See July 10th below for more or head over to my notes on the article that pull out some of the bits I found interesting.

31st July

❓ Four-Level Training Evaluation Model some useful ideas on what to look for when trying to get feedback on your training or other presentations. Another question that comes to mind: Is the training for the learners or for you to accomplish/be recognised for something… 🤔


💭 10 signs you’re an over thinker While thinking is obviously a good thing overthinking isn’t. But how do you know when you’re doing the good type of thinking? Simple rule: overthinking is focusing on the problems (by either ruminating about the past or worrying about the future). Good thinking is problem solving by focusing on the solutions and self-reflective thinking is looking at situations from a different perspective and finding new insights. 

3 things that motivates us to work

👷‍♀️  3 things that motivates us to work From Dan Pink’s RSA lecture based on his book Drive. The three things being autonomy, mastery and purpose. Autonomy is about being self directed over what and how you do something. Mastery is having the ability to get better at something that challenges us and making a contribution. Purpose is the reason for being or why are we doing the thing we do. The interesting thing is this is about individual motivation to work. Does it still apply when working in teams as we do in software? 

27th July

A model of what could happen if you dropped the ‘In Test’ column…

👷‍♀️ From ‘In Testing’ to ‘In Progress’ columns on team boards: This has a very narrow focus on just dev and test relationship. This model helps illustrate how improving their relationship and getting them to actively collaborate to improve confidence that the code changes work as intended is going to start having an affect on work in progress (WIP). Which as @johncutlefish shows high WIP can lead to a whole host of other problems. The grey lines are what it was previously with the ‘In Testing’ column broken out into it’s own section.

👯‍♂️ Don’t Mock Types You Don’t Own This happens more often then you realise and leads to lots of other problems the main one being you now have to maintain a mock of a service you don’t own or fully understand how it works. Therefore you’re testing against your assumptions of that service you’re mocking. This could lead to a false sense of confidence that everything will work when you go to production. Ideally you want to be using a stub with little to no logic e.g. little to no assumptions and any made are obvious to other developers. Contract and consumer driven contract testing particularly can help here. The other issue is people use the word mock to mean a whole host of other types of Test doubles (fakes, stubs, spies etc) which leads to more confusion so check what they mean when they say mock before assuming you’re talking about the same thing.

🎓 Accountability vs Responsibility This has been really useful when thinking about who is accountable within teams for tasks and who is responsible. I found others (and myself included!) mix these up. Accountability can not be shared and means you are answerable for your actions where as responsibility can be shared and you must respond when someone questions your actions. Having these distinctions can be really helpful in making sure people understand what they are accountable and responsible for. The comments are worth a read too…

20th July

😱 Programming is not a craft from Dan North in 2011 and I have to say I agree with his take even from back then this still stands. I think this really sums it up “Non-programmers don’t care about the aesthetics of software in the same way non-plumbers don’t care about the aesthetics of plumbing – they just want their information in the right place or their hot water to work”. By putting programming at the centre (by treating it as a traditional craft) and not the value you are delivering you risk building what you want and not what users want/need/care/value. Thats not to say the that the code can be shoddy far from it, but just like the plumbing it needs to work but does it need to be gold plated with silver fixings? 

🐦 Learning How to Learn thread from Jez Humble calling out a book: Learning how to learn: A guide for kids and teens. The book aims to help you talk to younger people about how to learn. It covers a really interesting topics called focused and diffuse mode of learning that I hadn’t come across before. There is also a free coursera course by the author on the mental tools of learning covered in the book. 

📻  How to make your own luck (podcast) the frame with which you look at world (people, events, things that happen etc) are going to have a big impact on the opportunities that you’re going to find. So what frame are you using when making decisions? The world is a wicked learning environment (slow feedback hard to tell which variable caused the outcome) while poker can be kind learning environment (fast environment, low number of variables, easier to identify mistakes and learning from them) therefore helps you to understand your decision making easier and then possibly translate over to the real world.

You can find more about wicked and kind learning environments from How Falling Behind Can Get You Ahead:
Kind Learning environments  

  • Kind give lots of feedback as you progress which aid deliberate learning 
  • The rule of the system don’t change either so what it is today is the same tomorrow 
  • Golf, chess and poker are such environments 

Wicked learning environments  

  • Mixed levels of feedback as you progress
  • Rules of the system keep changing 
  • I think software engineering maybe a wicked environment

13th July

🤩  Invisible asymptote (AKA The Invisible glass ceiling of testing) Excellent (and long) read from Eugen Wei and a must read for anyone working in product and software development in general. Brilliantly articulates that all products have an invisible glass ceiling and that by recognising your total addressable market it can help you understand when you’re going to hit it and actually do something about it.  

Why should testers care?

This is a great way to understand how your product owners might be thinking (or should be if they are not). In terms of product quality this could be one of the lenses from which you should look at your products to understand what is valuable to product owners. It’s also a great way to start understanding what value your product is potentially bringing to your users and what cohort that it is and isn’t addressing. My notes on the article pull out some of the bits I found interesting.   

In terms of analysis this hits two of the three domains that testers should have a grasp of: business and users. From that angle we can help the third domain (teams) understand how this affects them.

Remember testing doesn’t always look like testing


🔈 How do you handle criticism Getting feedback is by far the best way to get better but not all feedback is equal. You need to filter out the valuable parts from the things that sting the ego. One way to get better at receiving feedback is to rate yourself on how you respond to it. 5 being excellent and 1 being poor. Did you respond positively and thank them (4 out of 5) or did you try and talk them out of their opinion (2 out of 5). This will help you get better at hearing feedback but also more likely to do something about it. 


👩‍💻 Develop your culture like its software Interesting post from 2017 from the ex-engineering manager of The New York times. They used a google doc to make it collaborative and to start iterating on it. Culture is something that either just happens and evolves in a direction out of your control or you try and be deliberate about it. My preference is towards deliberate because then if it starts heading in a direction you don’t want you’re in a position to do something about it. Otherwise you find out when something hits the headlines. At which point its too late to do something…


🏚 Extreme testing Cool video of what IBM do to make sure their mainframes can handle earthquakes. Makes you wonder what type of testing AWS/Asura/GCC do for all their server farms

6th July

👩‍🏫 Professionalism is not enough via Ten things I’ve learned by Milton Glaser 

…when you are doing something in a recurring way to diminish risk or doing it in the same way as you have done it before, it is clear why professionalism is not enough. After all, what is required in our field, more than anything else, is continuous transgression. Professionalism does not allow for that because transgression has to encompass the possibility of failure and if you are professional your instinct is not to fail, it is to repeat success. So professionalism as a lifetime aspiration is a limited goal.

🥾  New employee bootcamp really interesting approach to getting people (product owners in this case) up to speed quickly and productive within their work. I really like the concept of “put your own gas mask on first before helping others”  in terms of helping them figure out their own career paths. What would this look like for on boarding new testers in a team? 

🧫 What is culture? I was doing some research on this and it turns out (unsurprisingly) that its not that easy of a question to answer but the Centre for Applied Linguistics at the University of Warwick (UK) has some really good resources. In particularly this doc which tries to answer that very question in a way that is approachable and can actually help you understand what it is. They break it down into 12 key characteristics but I think this explanation from Spencer-Oatey (2008) does a pretty good job:

“Culture is a fuzzy set of basic assumptions and values, orientations to life, beliefs, policies, procedures and behavioural conventions that are shared by a group of people, and that influence (but do not determine) each member’s behaviour and his/her interpretations of the ‘meaning’ of other people’s behaviour“

https://blackswanfarming.com/value-a-framework-for-thinking/

🤑 What is value? Interesting way of thinking about what value means. In this model there are two focusing areas: revenue and costs. How does something sustain revenue, increase revenue, avoid cost and/or reduce cost. By applying a monetary number to these  you can then discuss them in a way that everyone understands and can hopefully agree on. The other reason for relating this back to a number is having a discussion on what assumptions people are making about those numbers. 

Thanks to Duncan Nisbet for his intriguing blog series on cost of delay Vs cost of poor quality which linked me to the above post. In Duncans post he does a really good job of showing why trying to answer that question is really difficult and is setting up a framework in trying to do just that. I’m looking forward to seeing how this works out!

May – ToRead

Toread

At the intersection of software, technology and people 

What is this?

Things I’ve been reading this week that I’ve found interesting or intriguing. Sharing because I thought you might like them too. Most of the links will revolve at the intersection between software, technology and people – with the occasional testing slant. I aim to update them weekly, with some commentary on my thoughts and findings. Feedback always welcome 😄 

May Round Up

Three new posts this month with what is a quality culture within teams and what do people mean when they say they have confidence in test automation? I also attended Agile Manchester which had a lot of talks that related to testing and testers too.

I’ve been using Headway to get digest of books which has been pretty good for working out if it’s worth going all in on. I can recommend reading the The Coaching Habit and The five dysfunctions of a team but wasn’t so sure on Leaders Eat Last. Scroll down for my summaries of the books.

It turns out google do have testers, ThoughtWorks got a new technology Radar out which is always worth a look through, Spotify called them squads because it sounded cool and risque was all about pirates for 18th & 19th century merchants.

31st May

🕸 Technology Radar (PDF download) of the latest trends as seen by ThoughtWorks. Always worth a look through as they have the advantage of seeing what’s actually happening with tools, platforms, techniques and languages within the industry. Still recommending team use pipelines and infrastructure as code (worrying teams are not!). Simplest possible feature toggles which is exactly what it sounds like use if/then statements if you can get away with it. Some useful tools for ethical bias testing of ML algorithms too. Visual regression testing was another mention worth looking at for legacy systems but be careful of it turning into your only form of testing. It tells you nothing about behaviour change of the system unless that results in a UI change. 

📖 Thinking in Systems Quick primer from Headway on systems thinking but be warned this isn’t enough to get why it’s a useful way to look at things. So you’re better off reading the full book. Thinking in terms of systems might make it easier to understand the world a little better and maybe how you can tackle those big problems.  

25th May

📮New Post: Building a quality culture: Is it quality assurance or quality awareness? I’ve been thinking a lot about who does what in a teams lately and especially about automation and exploratory testing. That’s when the two different meanings of QA occurred to me again.

🗣 OnlineTestConf 2020: Testing Stories in Modern Times by Alan Page. The future of testing looks to be less about traditional testers running testing (even exploratory) and more coaching teams on what quality means and how they build it in. You might be able to sign-up still and get the download.

📰 Not even wrong: ways to predict tech “That is not only not right; it is not even wrong” – Wolfgang Pauli. Sometimes with testing and especially exploratory testing it can look like we’re just trying things and seeing what happens.  Which can be helpful in coming up with new ideas but is it something we should be doing all the time? Why are you doing what you are doing? What are you trying to find out? What theories do you have about the software and what are they based on? Are they facts, instincts or just because someone told you to

🐦🧵  All in or all out: remotes working is here to stay but probably not everywhere. Good thread on why it works somewhere and not others. Hybrid (some in the office and some out) just doesn’t work very well. From my experience the remote person either gets forgotten or just has a terrible experience trying to hear the people in the office. We tried group cameras, all sorts of mic rigs, always on cameras etc nothing worked to keep the remote people included. The only way it works is everything is remote first no matter where you are. That’s headsets, camera and chat clients for all conversations. It’s the main reason it’s working now as there is no other way to communicate 

📰 Chips and Geopolitics The product architecture and integration diagram (figure 5-1) can actually be thought of as an end users quality measure diagram. The end users in this case are business users and the quality metrics at play are good enough performance/features sets of the product being analysed. This could be really useful if you work in a B2B organisation and trying to understand how your customers see your product. If quality is value to someone then quality in this case is good enough performance and someone is a business users.

📰 https://kanyi.blog/2016/07/30/risk-at-sea the concept of “risque” as we understand it wouldn’t have made much sense to the 19th century sea going merchants. In their time it was related to the financial risque that they took by going to sea to transport goods. For which insurance was created to offset the losses made. 

🐦🧵How the podcast ecosystem works Podcast are open and essentially hosted by the creators (or system that does it for them) Spotify are offering something quite different to the open model. They’re intermediating between the podcaster and the users. Why? So you can start adding in targeted advertising. Much in the same way Facebook and Google do. But this will only work if what Spotify offer is actually better then what is out there. So they need to get podcaster onboard on one side (look better tools and ways to make money!) and users on the other (look all the best podcasters In one place no more hunting around!). Once Spotify can show they can target listeners the advertisers are not going to be far behind and Spotify can sit in the middle taking a skim. It’s called aggregation theory. The interesting thing about this is it’s usually a better experience for all those involved (podcaster, advertisers and users) unless the podcaster wants to build a direct relationship with their listeners…

18th May

📚 Leaders Eat Last via Headway App (Scroll to the bottom to find out what Headway is). There was some interesting ideas around brain chemistry and the idea of shellfish and selfless chemicals. With some citations and references I’d probably get behind these idea but this digest provide none.

Along with this the book has some good ideas and I buy into relationships being key to good leadership but it’s difficult to work out how much of the book is the author’s opinion and how much of it is based on research and/or experience. I don’t think I could recommend this book based on this digest. Which raises another question. Is this because of the author of the book or the author of the digest

⚗️ Agile Manchester: Tester Edition Summary of the talks I attended and why they are relevant to testers. Testing doesn’t always look like testing…

 👩‍🏫 Agile Manchester Overall: Peep show conference – My first virtual conference which was pretty much as I expected: 

  • 👍 Talks that start and finish on time and are easy to see and hear for everyone.
  • 🤷‍♀️ very little audience interaction during talks, passing opportunities to meet other people, see what others thought, breakup your usual week

You can find my very rough notes here… 😉

It’s almost like being at your own personal conference. You know others are there but everyone is in their own little booth watching the talks in isolation. A peep show conference. It’s not necessarily a bad thing just very different when compared to in person conferences. By the end I was very much screened out. Each talk for me felt even more full on then in real life and being sat in front of a screens all day had taken it toll for me. So come 6 o’clock I’d had enough and didn’t attend the virtual social events which may have given me the networking opportunities I mentioned above. 

The day after the talks  Having had some time to digest the talks the day before the following things stood out for me: 

  • Wipe developers machine regularly from fight code and team rot with continuous improvement 
  • Use forecasting to give predictions on when we’ll deliver from agile metrics for predicting the future 
  • What stories are you telling yourself from crucial conversations 
  • Document the implicit from leading a agile organisation through hyper-growth 
  • Let the participants drive the workshops not you from coaching from the back of the room 
  • Communication is the glue of our organisations this can be nurtured, don’t leave it to nature from code + culture ≠ delivery 

Now that’s not to say that was all there was from the talks. There was lots to unpack from them all which you can read above in my notes. For me the two standout talks where agile metrics for predicating the future and coaching from the back of the room. These are two areas I looking at right now. But still enjoyed hearing crucial conversations, leading a company through hyper-growth and code + culture ≠ delivery. Software teams in general would also get a lot out of fighting code and team rot which was succinctly delivered. 

11th May

If you want testers to be 💪 confident in the 🤖 automation then either 🎥 “show” them how it works or build 🤝 trust in the person doing the work. Better yet do both 🤖+🎥+🤝= 💪 💪 https://www.jitgo.uk/building-confidence-with-automation

 📰 The real lord of the flies What would happen if 6 boys where left on an island for a year. The twitter thread is worth a read too with some interesting facts about the original author of lord of the flies. 

🧪 So google do have testers! But they’re actually developers working on code level tests and tools; no exploratory testing in sight. They call themselves Test Engineers which makes more sense when you think of Software Engineers. One focuses on software the other on testing but both use engineering (code) to do their jobs. 

🔈Bad is stronger than good We focus more on negative things than positive. Which is probably useful if you’re living as a caveman and the negatives things can kill you where as the positive things mean you just stick around a little longer. Not so sure how helpful this is in office based situations. Original paper is worth a read too. 

8th May


🔈 The planning fallacy Why things always take way longer than anyone thought. The planning fallacy is a tendency to underestimate the time it will take to complete a project while knowing that similar projects have typically taken longer in the past. So it’s a combination of optimistic prediction about a particular case in the face of more general knowledge that would suggest otherwise.

📰 Product vs. Feature Teams A big telltale of a feature team is the product road maps with prioritised list of features that teams needed to deliver. I think a lot of teams want to become product teams but teams have never had the full autonomy led by their product manager to focus on outcomes. It feels like they get stuck grooming the backlog for the team rather then helping the team focus on what’s valuable to users and the business. Speaking of autonomy…

📰 Follow up to Spotifys failed Squads from last week: Spotify Vs Fitbit Spotify had a lot of autonomy but you need that for innovation. If you have too much control you end up with FitBit which delivered what someone in the company asked for but at the cost of autonomy. Which could have created new opportunities for FitBit via innovation. 

📚 The five dysfunctions of a team via the Headway app. You should read this book. Letting just one of the dysfunction occur can cause a snowball affect and open the door to the others. Start with building trust and accountability and then work step by step on the others to build well performing collaborative teams. Which links back to product Vs feature teams. How do you give teams the autonomy without is leading to chaos. Well one way is to avoid the 5 dysfunctions 

1st May

📹 How falling behind can get you ahead Kind and wicked learning environments sounds like a intriguing concept.  I think software development in teams is a wicked learning environment so what can we do to make it kinder? 

📖 The Coaching Habit via Headway Great introduction to coaching and questions. This is a book that is definitely worth reading rather then just a digest. The 8 questions that the author recommends are all themes that I’ve seen from other books so are not just picked at random. The reasoning behind the questions also backs up other theories especially from Coaching for Performance whose author is considered one of the founders of modern coaching methods.

📰 Spotifys failed Squads 🤭 “Spotify had teams it called squads because it sounded cooler (not joking)”.  “The Spotify model” was what they wanted not how it actually was and failed in parts when they tried to implement it.  

Building a quality culture: Is it quality assurance or quality awareness?

5 minute read

If you ask testers what does QA stand for most are likely to say its Quality Assurance and is typically described as providing confidence that some quality criteria will be fulfilled. Some people in the testing community believe that it’s actually Quality Awareness*. The thinking goes how can tester assure the quality of something if they never built it in the first place? All they can do is make your team aware of the quality. I agree with both explanations and believe that they are different sides of the same quality coin.

Read on to see what this means for testers and how it’s a useful to consider both in teams.

*I’ve also heard Quality Advocate and my favourite Question Askers, both fit this model of Quality Awareness.

Firstly some definitions:

What is Quality?

Quality is value to someone – Gerald Winberg

But who is that someone and what does value mean?

From the Lenses of quality on who that someone is:

…that someone could be their Products Owners (PO), the organisation they work for, the team they work with and their end users and all these groups of people could have very different views on what value means to them and even contradicting in some cases.

https://www.jitgo.uk/lenses-of-quality/

Again from the same post on what value is:

Each of these groups of people view quality with a different lens therefore see the same system differently to one another. We as testers should help our teams to see quality through these different lenses by helping them identify these groups and what their measures of quality are.

https://www.jitgo.uk/lenses-of-quality/

Simply put value will depend on the viewpoint of the person. Identify whats viewpoint that person sees the product/system through then you’re halfway there to working out what’s valuable to that person. If you take this a step further and see what incentives drive that persons viewpoint then you might identify whats valuable to them too. But thats not as easy as it sounds.

For any given team there are multiple members and stakeholders therefore they are likely to be a number of unique and overlapping quality attributes too. Identifying the key ones for each cohort of people is a valuable exercise for any team. It might help explain why some people are never happy no matter what you deliver.

What is Quality Assurance?

Firstly what does assurance mean from the Oxford dictionary:

a statement that something will certainly be true or will certainly happen, particularly when there has been doubt about it

One way to think about assurance is that it’s a promise that an outcome will happen so as to give others confidence. In this case it’s quality and as mentioned earlier quality means value to someone. Therefore QA or Quality Assurance means providing confidence in the quality of the product to stakeholders. This it is about certainty that an outcome will happen not a guarantee. You are saying that best efforts will be made and this is an assurances in making that happen.

What is Quality Awareness?

What does awareness mean from the Oxford dictionary:

knowing something; knowing that something exists and is important

interest in and concern about a particular situation or area of interest

This would lead to QA or Quality Awareness to be a person who is interested in quality (value), understands its importance and has knowledge about the quality of a product or system. To take this a step further someone who works in Quality Awareness understands that quality is value to someone, knows who those people are, what viewpoints they hold and possibly what incentives drive those views. They are then able to apply this knowledge to the system and subsequently increases their teams awareness of overall system quality. Essentially Quality Awareness is about building awareness of what quality is in a team, how it is affected and who it matters too.

Quality Awareness sits at the intersection of the team that produces the system, the domain in which the system operates in and users of the system.

Two sides of the same coin

Both are focused on quality but one is about improving the teams understanding of what quality means for their stakeholders. While the other is focused on maintaining (and hopefully improving) the quality of the product.

In this scenario Quality Awareness can improve Quality Assurance by giving it the metrics with which quality is being assessed on. In this model Quality Assurance can actually fulfil it’s job of providing confidence that the quality of the product is being upheld. Why, because it is taking into account who the stakeholders are and what is valuable to them. Then converting that value into a measurable metric which the engineering team can either:

  1. assess themselves against to make sure they are doing what they said they would do or
  2. provide the stakeholders the metrics to improve their confidence that not only is the engineering team doing their job but maintaining and perhaps even improving it.

The thing to keep in mind is not all quality values can be converted into an easy to measure metric. You can use proxy measures to give you an idea but some measures are always inherently subjective. On top of the this the systems we build are interdependent on other systems which are out of our control and can affect the quality of our systems. Therefore techniques such as exploratory testing can be very beneficial as it can help build a fuller awareness of what quality means for your product.

Back to Quality Assurance?

Does this mean we should go back to using QA again and naming ourselves the QA Team? No, we’ve come a long way in some areas of our industry and going back to QA teams might bring back all those old problems. Such as test team silos, testers being the gatekeepers and why didn’t we catch that bug?

How is this helpful?

Where this can be useful is giving teams another lens through which to look at their testing approach and think is this heading towards building assurance of quality or is this about raising awareness of quality. By separating out into these two camps you can see the value it’s actually going to bring and if its worth the investment. It might also help clear up who should be doing what and when.

Using this model of awareness and assurance could be helpful for testers trying to figuring out what it is that they want to do with their careers. Do you want to learn more about building team confidence in quality through test automation (Quality Assurance) or building a quality culture within teams (Quality Awareness)?

Agile Manchester 2020: Testers Edition

I’ve always found that tester representation at agile conferences to be lacking. It’s a bit like it doesn’t have the word test in the titles so it’s not for me. Personally I’ve always found a treasure trove of information from talks that are directly or indirectly related to software testing. Remember testing doesn’t always look like testing you sometimes need to change the frame with which you look at things to get the best out of them. 

Below are the talks that I attended with a brief summary of the talk and what it could mean for testers. 

Want the full unadulterated notes then see my personal notes.

Fighting Code Rot with Continuous Improvement 

by @garyfleming Slides http://bit.ly/fight-code-rot

Summary of the talk Good talk covering all the basic with keeping your system update and why. Well delivered and really useful for less experienced team members and a good recap for “they should know better” members.

For Testers For testers understanding what needs to be updated when can help them understand how that change could affect end users. Be proactive what do the release notes say for X, how do we use system Y. Building this knowledge takes time but can be really valuable in the long run. Start small and work your way up. Developers can help you but try and help by having specific questions for them.

Agile metrics for predicting the future 

by Mattia Battiston Slides: https://www.slideshare.net/mattiabattiston/agile-metrics-for-predicting-the-future

Summary of the talk: Forecasts will always beat estimates for non-deterministic projects (think all software projects). As they help you understand what could happen with a confidence rating. You’ve probably already got most of this data but knowing your lead times and throughput can help with this and some spreadsheets.
The key thing to remember is you need to talk to your stakeholder and make sure they understand what the numbers mean and how it affects them. Don’t just give them the spreadsheets and expect them to understand. 

For Testers: If quality means value to someone then value to people working in delivery roles is greater predictability with delivering our software systems. Understanding what these metrics are, how they are used and what affects them will not only enable you to have more productive conversation with delivery but also understand why they are important to that group. This will help you articulate risk better within your teams as you will be able to tailor the message to that specific audience. This will not only help you help them understand risk better but increase your value from just being the person that finds all the issues. This elevates you from being just a tester towards a test analysts. 

Crucial conversations in agile teams

How making it safe to talk about almost anything unlocks continuous improvement by Chris Smith. Slides: https://www.slideshare.net/chris_smith1976/crucial-conversations-for-agile-teams-agile-manchester-virtual-may-2020

Summary of the talk Really interesting talk by @cj_smithy at #agilemanc focusing around the book Crucial Conversations but bringing in ideas from the Chimp paradox, 5 dysfunctions of team, Radical Candor and generative cultures by Ron Westrum. Conversations within agile software teams are incredibly important (remember individuals & interactions over process & tools) so being better skilled at them is a great thing.

For testers We have conversation with team members all the time. Whether that is to find out information or to inform others about whats going on, its a core part of our skill set. Getting better at communicating verbally should be part of our personally development as testers. The resources mentioned in this talk would go a long way to help you build up that skill and help keep it sharp.

Leading an agile organisation through hyper growth

By Patrick Kua

Summary of the talk The company Patric was a CEO for went through some really fast growth over a very short period. The model he used was simple and acknowledged that it wouldn’t work forever so they kept iterating and scaling the organisation. Useful to benchmark your company against to see where you are in the growth of your organisation. 

For testers Understanding how a company develops from startup to enterprise is really helpful in in seeing what types of problems you’re likely to face. This can help you help your team understand how quality is likely to be affected when scaling and what they can do to mitigate it. 

Improve your agile coaching skills with a Training from the BACK of the Room

By Sabine Khan

Summary of the talk: Its called back of the room as you’re not using slides decks and you presenting but getting the participants to stand and present instead. Hence coaching from the back of the room. 
Really interesting approach to learning and using coaching skills in teaching others. The 6 learning principles are really quite easy to apply and can make almost any session interactive. This combined with the 4C’s gives you a framework to turn any learning topics into something more than just sit and listen. 

For tester needs updating: Need to help team members understand what exploratory testing is then why not do something interactive instead of just another slide deck. Teach them through doing and the key points might actually stick. 

Culture + Code ≠ Delivery

By Vimla Appadoo @thatgirlvim

Summary of the talk: Vim makes a great point in that just delivering through code and a good culture isn’t enough as this misses how that delivery affects users. Especially if the system has biases built in unintentionally.  She says we need communications as well. Communication to be able to link together all the parts of the culture of the organisation, systems, processes and people + the code can help us deliver the right things.

For tester: Testers help raise the awareness of quality within systems, but for them to be able to do that affectively they need to take into account the team, the business and users as well. The key skill to be able to do this is communication and helping to link together all the parts to understand the other. This is not to say that testers are the key to culture but on a smaller team scale they can have huge influence over what direction that culture moves in. Do the teams care about how their systems affect users or wait to see what happens? 

Building confidence with automation

To build peoples confidence with automation you first need to understand why you’re doing it. 

Why do we automate things?

If you look at automation in general the reason to do it is because we have some sort of repetitive manual task that we want to be able to do automatically. By doing so you would remove any inconsistency that could occur from doing it manually. This would also make the output of the process reliable and repeatable as and when you need it. In short automation can make processes consistent, reliable and repeatable. 


This usually leads to other benefits too such as the ability to scale up the automated process in terms of frequency and speed all while reducing costs in some scenarios. Essentially you can take advantage of economies of scale. 


The benefits of consistency, reliability, repeatability and scalability is that this helps the people associated with that process to have confidence in the output of that automaton. They can either see the process happening again and again or can inspect the output to validate their confidence in the process. You could even take it step further and automate the inspection too. 

But what about test automation? 

The above works well for say automating a physical process such as making a glass bottle. You can either see how the bottle is made or inspect the end product. But when it comes to test automation you can’t “see” the test occurring (or any software process for that matter) and the only output is likely to be a result: pass or fail. 

The only way to gain confidence in the automation is to either inspect the code (process) or your confidence is based more on the person doing the automation. You trust that they wouldn’t fake it or maliciously do anything wrong. 

If that confidence is lacking then the only way to feel confident that the system being tested works is to test the system again. Therefore any of the benefits gained from automation have been lost as you are now duplicating the effort. The biggest loss being the economies of scale.

This is by far one of the biggest reasons why tester in teams have very little confidence in the automation. They don’t know what is covers, how it works or even if it’s being done to a high standard. If your job is to understand and raise risks within the team then this almost leaves them with no choice but to test it again. 

Building confidence 

If you’re a developer or automation specialist then you have two options in improving peoples confidence in the output of the automation. Help them “see” the process or build their trust with you. Both of which will go some way to improving their confidence with the process.

Better yet, help them understand the principles behind the automation which if done with humility and compassion is naturally going to lead to those people trusting you as well. By helping them understand the principles behind the automation you enable them to work out for themselves what is and isn’t being automated but also to what standard it is happening to. This then lets them see where the gaps are in the process which they can raise as risks or work to plug them up. 

I’ve written about building a team understanding of unit testing which details how you can document your principles in a way that is accessible. You can use this method to document any team principle not just unit testing.  

Want to read more about automation than check out my previous posts on UI Automation what exactly is it good for and the unintended consequences of UI automation.

Working for home: Why routine matters

Manage your time

Now you are your own boss all those things in work that keep you honest are no longer there. If you want to sit with Facebook/WhatsApp open all day you can and no one would know. But this is also chance for disaster. If you don’t keep yourself in check then your work /life balance blurs into one big blob and either you’ll feel like all you do is work or nothing at all! One leads to burn out the other to demotivation (and on the extreme side losing your job).

You can also find yourself sitting in front of your screen for even longer periods than when in work. Those pesky in-person meetings, now on zoom, so and so asking your questions, now in slack, heading out for lunch with the work colleagues, just walk to the kitchen and back to your desk, random chats when heading to and from meetings/kitchen/loo all gone, need to chat to someone just fire up a video call. All of a sudden all those “distractions” in work have stopped and now your sitting hunched over your desk looking like Emma.

What do I do?

So what do I do? Well I use a time tracking app just to log my start and end times. This not only keep me in check that I’m working but also stops me over working now that no one else is managing my time for me.

I use Hours tracker for iOS which has a free and a one off £10 paid tier. Which makes it really easy for me to clock in and out. There are also additional features that allow you to automate that process based on location and time, but I just stick with start, stop and total times. There will be alternatives for android too just have a look around the app stores for one that stands out for you.

To make sure I’m getting up and moving regularly throughout the day I’ve started to make use of my smartwatch by using a 50 and 5 minute count down timers. Currently I’ve setup a shortcut as a complication so I can start and stop it easily by tapping on the centre timer link.

I also use my desktop calendar app with regular items coloured coded for easy scanning and todo list extensively as it makes it easier for me to see what I have to do and by when. Making my calendar open to work colleagues too means they can see when I’m free if they want to book things in with me which saves a lot of to and fro when organising meetings.

Why routines matter?

The great thing about doing the above to manage my time is that it builds routine into my daily work. Routines eventually become habits, which eventually become automatic and you spend even less time thinking about them and more time for things you do care about.

The key to success: Willpower

Road to success Photo by Vek Labs on Unsplash

The other potential advantage of offloading the work to these apps is that there is some evidence that doing this can help you be more productive as it can help limit decision fatigue and conserve willpower. This is when you have too many decisions to make which can lower your willpower at which point your more likely to take the course of least resistance. This can be whatever the default options are which have a tendency not to be the best ones for you.

For instance while you’re shopping you tend to be making lots of decisions (what colour, what size, what about this compared to that etc) so by the time you reach the tills your cognitive ability is pretty fatigued. This is generally when your offered upgrades, special offers and impulse buys. To which a lot of us simply say yes and out you go with a few extra things you didn’t even know you wanted.

Therefore doing things that help boost your willpower can be really beneficial such as exercise, other activities that help you stay positive and other routine building habits. Also knowing when your willpower is likely to be low is useful as you can switch up your default options towards things that are better for you e.g keeping fruit/veg snacks refillable water bottle nearby instead of sweets and sugary drinks

What makes willpower so important? Research suggests that it’s statistically the biggest contributor to academic success over intelligence , greater success overall and wealth. Willpower is your ability to do things even though there maybe no immediate or positive feedback but could result in a future gain.

Got any good tips for building routine and habits then let me know in the comments.