A friend of mine always say the biggest problem with software is that bad software still works. But what about when software makes you sick? Or creates completely new businesses that profit from the strict and inflexible nature of software? I very much enjoyed this article in The New Yorker by @atul_gawande.
“…patience as a personality trait is modifiable. Even if you’re not a particularly patient person today, there’s still hope you can be a more patient person tomorrow.”
Me and Teddy Zetterlund had lunch last week and reflected on the challenges of working in big organisations. Later he sent me this excellent article by Niels Pflaeging outlining a new theory about the types of leadership (and influence) that exist in an organisation. I immediately started thinking about my situation and those around me and I’m definitely putting this theory in my bag of tools for Agile Coaching.
Sara [10:22 AM] It’s quite faschinating how much the role and identity of being a Tester has changed. I’ve had to change a lot in my “tester identity” these last 10 years.
Sara [10:22] Maybe I’ll write a book about it some day 🙂
Christoffer [10:23 AM] Yes, do it! 🙂 What would you say is the biggest change?
Sara [Today at 10:56 AM] Answering your question @christoffer (and trying to keep it as concise as possible, obviously failing).
My personal path was somewhat like: I started as a developer’s right hand, testing ready code, then moved towards being a tester in agile team, then test lead, then worked on a high level defining quality strategy on organization level, and then returned to the hands-on.
And as for the tester identity change per se (the way I’ve seen it which is 100% subjective), I think there was a very interesting metamorphosis the last 10 years. Testers did not want to be the “passive receivers” of developer’s work anymore, so there was a lot of talk about being an inspiration/guide/ambassador of quality. And that time created plenty of “empty” testers, the ones without strong knowledge and expertise, but with an ambition of some special knowledge and (at last!!!) power. This attitude couldn’t possibly sustain itself long. So naturally the emptiness started filling up with real expertise. But this time it was important to become an equal player of the development process. Which means testers having their own domain of expertise and at the same time share it with everyone else in the team. Not an easy task. But we seem to be managing.
Christoffer [2 hours ago] I notice it’s very common that people struggle in teams between having special knowledge which entails being responsible for all work requiring that knowledge and the teameffort requiring everyone to share/contribute their knowledge and expertise but not necessarily doing the work themselves.
Christoffer [2 hours ago] I guess it boils down to making sure people with special competence feel like they contribute even if it’s not their hands on the keyboard all the time?
Sara [2 hours ago] I guess it’s one aspect of it, yes.Another one I see is somewhat different value attached to different skills. For instance for developers the value is very clear. Code = product. Easy to see and measure, easy to be proud of. For the tester it’s a bit more tricky, because good product quality is not equally straightforward and rather undefined.
Sara [2 hours ago] And in itself testers best effort manifests in helping an organization and a team produce better quality. But just “helping” is not enough, it’s not fully satisfactory, it’s a group result. One also needs some individual result, and this is what testers are searching for — how to have impact on both group- and personal level.
Sara [2 hours ago] IMHO 🙂
Christoffer [2 hours ago] As a developer I used to think that too. Code = product. But as time has passed I’ve realized that Code is at best product. In a lot of cases it’s not. And that’s where developers today should feel like the testers you describe above as well. Is the work I’m doing adding value? Is it solving someones problem or am I creating more problems?
For good developers product is not necessarily code. Good developers solve a problem for someone. And testers can help them understand that problem by framing the problem in a way that’s understandable for both developers and the problem-owner. Using scenarios, scoping and challenges of ideas.
Christoffer [2 hours ago] However, developers have one tool that give them instant continuous affirmation. The red/green bar of a unit/integration test. For testers the affirmation is harder to find, like you say.
Sara [2 hours ago] Interesting about the developers point of view! We continue after lunch 🙂
Sara [1 hour ago] “Good developers *solve* a problem for someone. And testers can *help* them understand that problem..” — exactly my point you replicated here. There is a big gap in terms of satisfaction between “solve” and “help to solve”.
Sara [1 hour ago] So I think both linguistically and empirically we’re aiming to “developers and testers *together* solve the problem”.
Christoffer [1 hour ago] Sorry about that sloppy writing. My thought is good developers help someone with a problem or help them realize an opportunity. Sometimes they solve it for them with software but very often they help the person or organization realize it’s not a problem to be solved with software but rather it’s a tweak in process or just understanding the domain.
Christoffer [1 hour ago] I agree with your second note!
Christoffer [1 hour ago] totally
Sara [1 hour ago] Mhm, I see what you mean with problem solving/sorting as part of developer’s job.
Christoffer [1 hour ago] Much like the testers job of identifying if the software actually solves the problem or if it makes it worse.
Christoffer [1 hour ago] Our different competences aside we are very alike in our aims and struggles.
In the category Most Important Subject I have a hard time finding a presentation more relevant than Kimberly’s. An inspiring tale of what we did in 2017 to turn the climate trend from a negative one to a positive one.
In the category Most Useful At Work I choose Joshua Kerievsky (known from Modern Agile) and his talk about psychological safety as a pre-requisite for creating high performing teams. Showing some of the theories and highlighting concrete things to look for in our daily work.
The last from my Top 3 is Gojko Adzic talking about how our names make computers go bananas sometimes. And the problems you’ll face if your name is Bob Test. Hilarious and just pure entertainment! 🙂
