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 😄
🕸 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.
📮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…
📚 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.
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.
🔈 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
📹 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.
📚My New Reading list
- Digest of: The five dysfunctions of a team
- Some interesting ideas in this one
- Will follow up next week
- Book: Teaming- How organisations learn, innovation and compete in the knowledge economy by Amy Edmundson
- This is a long one so maybe some time before I share anything
📖 The Fearless Organisation – AKA what is psychological safety. Really interesting book written by someone who has done a lot of research on the subject over 20 years. As humans we are constantly controlling and regulating others perceptions of us as we feel that we could be risking them thinking negatively about us. This is known as interpersonal risk. Psychological safety is the belief that an individual can take interpersonal risks without it being held against them. Psychological safety exists at the group level and changes depending on which group you’re in. (Full book)
📱What is Headway app? I’ve been reading summaries of some books through Headway. No way as good as reading the whole book, but OK to get a digest of things I’d like to read but not going to get the chance. So far so good but what if you read a digest of a book and don’t agree with it. Are you disagreeing with the author of the digest (who you have no idea who they are) or the author of the book? 🤔I will indicate if I’m basing comments on a digest or a full book.