Communicate Curiosity

A “testing mindset” of inquiry applies when you are a principal tester or even a senior advisor in testing. Asking open questions and approaching a challenge with exploration proves better than command and control. People are people – be mindful of where they are.

Currently, I’m involved in an extensive change program for a company. It’s not your usual agile feature factory but more about the technology stack needed to run a 3000 people company (payment, finances, etc). While testing professionals could be onboarded – their learning curve would not scale – not even being equipped with all the heuristics and testing vocabulary in the world. As it is a one-off, automation wouldn’t scale either.

Fortunately, most applications have a system owner (or product owner, or manager in charge) and usually a team around maintaining the application. To some degree, we could frame these teams as stream-aligned teams. The experts in testing the applications are the superuser – hence they do the testing.

Trust must be extended before it is given

Rachel Happe – @mastodon.social/@rhappe

One such team is the XYZ team anchored by a VP-level manager. A colleague and I had been trying to communicate with them to align on the testing needed but had met reluctance. They would not have time to help us. We discussed the matter and realized that we needed to approach them differently. Since the change program was such a fundamental shift for the team, they had already considered the implications. They were already testing and thinking about the impact. We just had to trust them – and build on what they already had instead of imposing specific ways of working.

Without requiring them to earn it first, tell everyone who works for you that you #trust them implicitly. From that point forward, just ask them to never give you reason to withhold it. (In my experience, most won’t).

Mark C. Crowley

Communicating curiosity can be a little thing like “Remind me, how does XYZ work” or simply “sitting on your hands” during meetings that you would previously fill with questions and requests. The tables of the great program test lead are turning, it’s about being an enabling function for others to succeed. Similar to the freedom you should give your growing up kids – it’s about leadership.

Writing a Book in 30 Evenings

As mentioned I have written a book. Looking through my notes I have around 30 versions, one for each significant session of working on it. I have been asked to share tips on writing a book, so here you go, Simon. The key lessons are:

1. Set a Recurring Time and Space
2. Unique Content – Reference the Rest
3. Storyline and Flow
4. The opposite of passive voice is not an aggressive voice
5. LeanPub’bing

Set a Recurring Time and Space

One of my book’s themes was moving something from a hunch to a hard truth. And the same really applies here. When I finished my master’s degree while working (back in 2002), I had two slots a week at a “study office”. From that, I learned that not all study days are equally productive “on paper” – but that’s ok. Each session had its purpose.

Similarly for my book project. I set a weekly evening booking in my Calendar – family chores were arranged around it. After dinner, I work start working on the book and work for 2-2½ hours. I used my personal computer in my work-from-home setup.

Unique Content – Reference the Rest

There is so much great content out there already, my focus was on writing about my experience and my vision of better test strategies. But to do that I needed to stand on the shoulders of others to set the scene and describe the techniques I applied.

While writing I did want to bring in loads of existing content to elaborate and provide a foundation for my thinking. While editing I removed most of it, partly because I didn’t want to sound like a high school book report (thank you for that one Tristan). What I did leave in were quotes, recommendations, and listings of the work of others. The book is full of footnotes directly on the page (as compared to end notes) to highlight everyone in context.

Storyline and Flow

Initially, I outlined the chapters and subchapters and it was important to get the right “flow” and storyline into the content. My base model was inspired by “Situation, Complication, Question, Answer” from the guide “How to present to executives” (StaffEng Book) and similar lessons on taking the first steps.

• This is the situation and challenges
• These are the techniques, we can build on
• These are the first steps, where the techniques are used

One thing I have worked a lot on is the flow of the text: Sections would be 4-6 lines long, with empty lines in between. I also worked to reduce “dangling lines”, so no two lines would linger into the next page. No pages should be text only, so quotes and illustrations are important for readability – as well as making the book content visible. Lastly, I worked a lot on having one section end with words that tap into the next section.

The below recommendation is cool, I could have done that too.

15 years ago my PhD advisor taught me One Weird Trick for editing your own writing. Edit **back to front**, paragraph by paragraph. I still use it and it still surprises me how well it works. When I get my students to do it, it often blows their minds. Try it!

— Arvind Narayanan (@random_walker) October 16, 2022

The opposite of passive voice is not an aggressive voice

Often I started my “book evening” by reading the book from the start all over again. As I’m not a native English writer, I installed Grammarly and paid for the premium version for a period to rewrite phrases that were in a passive form. Fun Fact: the opposite of passive voice, is not an aggressive voice but an active voice.

Have proofread quite a few books for my friends in space. Couple of Stage Mom top tips:
– Avoid colloquial language for global readers
– Know your audience. If for beginners, use footnotes or end notes
– Don’t overuse passive voice
– Tell stories from your experience! pic.twitter.com/sehtnM5bRx

— Tristan Lombard 🇺🇦 (@TristanLombard2) October 2, 2022

The tool you use to write your book isn’t that important. I used Google Docs with embedded Google Drawings, others might prefer Word or other editing platforms. The biggest challenge in publishing was getting the embedded pictures in a resolution that could be printed by the print shop. The book exists in a printed format – but it’s primarily an electronic book.

LeanPub’bing

Self-publishing on LeanPub is intuitive and easy, it also has tools for incremental versions, previews, and updates. Let people sign up for it in advance with price suggestions. That allows you to set a price on the book based on audience-based quotes.

They also have a great system for coupons. I have coupons for those that helped in preparing the book, those I have referenced, and those that participated in the virtual launch. Let me know with the phrase “LeanPubbing” if you want a coupon too.

Taking My Own Medicine

Recently I had the chance to apply my own templates to myself and my active project – as I had to mentor a new test manager. I was challenged in explaining how I read the upcoming IT environment project. After looking into resources for new test leads, I realized I could take my own medicine.

Photo by PhotoMIX Company on Pexels.com

A year ago, I created a new test plan format – the Situational Aware Test Plan. While mind-maps and one-page test plan canvases exist, I wanted to elaborate using the evolution principles from Wardley mapping and stop writing test plan documents.

The table structure is there to provide guard rails for the elaboration. I will use the Darlings, Pets, Cattle, and GUID -mnemonic as headlines. Our strategic decisions emerge as we use the worksheet based on the current situation and state. The strategies will be the decisions to push a field in the grid to another state. 

Delivery and Situation

	Darlings	Pets	Cattle	GUID’s
New project	Fixed date
Existing delivery speed		Scheduled Quarterly
Test Environments, internal			Repeatable
Test environments with integrations	Crafted	Some existing know-how
Environment Infrastructure			Hosted data center practices
Test data		Known but cumbersome

While this project introduces new test environments, there is an existing environment with a quarterly delivery pace. This is a classic example of the core chronic conflict of pursuing both: responding to the rapidly changing competitive landscape and providing stable, reliable, and secure services (DevOps handbook introduction xxv) as elaborated on Align your Test Strategy to your Business Strategy.

The test team allocated beside me and the new test lead is a new junior and senior tester. We are in the same team, and most are even in the same office. So collaboration will be collaborative and pervasive, with a focus on helping the new people grow.

The test team

	Darlings	Pets	Cattle	GUID’s
Test team collaboration			Growing	Pervasive
Test lead			Growing
Mentoring		Enabling
Domain know-how		Getting there

Test tools and approach

	Darlings	Pets	Cattle	GUID’s
Test activity	Explore integrations		Confirm internal requirements
Test cases			Existing can be updated.
Test case repro			Create new repository

As mentioned in the blog post about visualization, we can now use the map to discuss why we need CT and ET for the project. Based on the project’s layout, I would advise having an expert exploration of the integrations and more standard scripts for the known construction of the internal environments.

Why Do We Fall, Master Bruce?

… So that we can learn to pick ourselves up, Alfred! I was recently reminded of this quote from watching the “Batman Begins” movie with my 16yo. I really needed that reminder. Then I read the two blog posts by Beren on “Those who Failed” and “Versus the Endboss“. Let’s put it out there that we fall – and fail to remember that we fall.

I had been part of a large project – but had read the culture all wrong and we had failed hard. For a number of reasons and maybe mostly for systemic reasons. The team expected one mindset and one way of tooling – we provided another one. Even with all my best intentions and know-how of change management, this crashed. As Hannes elegantly put it, we had cycled too far ahead of the team:

Something I learned trying to be a change agent: it is kind of like team cycling. If you want to help your organization forward, going too far ahead of the group will only wear you out. Riding in front of the group absorbing some of the air resistance is much more effective.

— Hannes Lindblom (@HannesLindblom) April 21, 2022

• The team expected minutes of meetings and agendas, we worked for making things visible and shared
• The team expected testing to be checking the requirements, we worked for testing to support critical decision making
• The team worked political with back channels, we worked open and power-lifting
• The team participants had agendas that didn’t align with the project’s purpose
• The team expected all things equally important, we worked by priority and deadline
• The team expected detailed test cases to be approved at all steps, we provided intentions and purpose
• The team expected detailed handovers, we worked entrepreneurially to set things in motion
• The team expected an error-free lead, we worked knowing I wouldn’t remember everything

At one point I was arguing that the team needed to read Hofstede’s cultural dimensions theory – to read up on the different cultures we would be interacting with (our customers). In retrospect, we should have used it on ourselves first of all.

Hofstede’s cultural dimensions theory

It’s a little more detailed than Westrum – and even Westrum might have helped. That is if we had been able to articulate the conflict well in advance. Perhaps a senior hire should have spotted the signals beforehand. As an outsider, I relied on people telling me things. I couldn’t hear or see the back-channel communications. This is a struggle for many staff people when switching roles:

People underestimate how much of their success is simply that they’ve been working at the same company for a long time and know the people & culture.

A recipe for success in switching companies as a senior hire is entering with a beginner’s mindset. When you don’t it’s painful. https://t.co/RJceWwKmm5

— Dare Obasanjo (@Carnage4Life) April 23, 2022

Blogged: Why Success is Often Elusive at the Highest Echelonshttps://t.co/6JnAs5BEXy

TLDR:

– innovation is hard without the right support structure and context
– execution is hard without being well-versed in the culture
– culture often has a steep learning curve https://t.co/AR2LtUpk27

— Cindy Sridharan (@copyconstruct) April 25, 2022

Initially, no one from the operations organization and latest implementation opted for the leading the activity. As we had no playbook or project plan (only the produced artifacts) – I made a scrum-board-inspired work tracking system. Perhaps I should have used a Wardley map first of all as recommended by John Cutler in “TBM 18/52: We Need Someone Who Has Done “It” Before“

What is Wardley Mapping doing for us here? It is letting us explore a more nuanced view of the problem space. Instead of treating things as one problem, we break the problem apart into a bunch of capabilities. When we do this exercise we typically find:

Not everything is an existing playbook. Not everything is a new playbook.

To solve new problems, we need a foundation of stable playbooks. For example, to solve that crazy new problem, the team might need a foundation of trustworthy data.

Yes, you can break things apart to see them better. But you’re also dealing with the whole thing.

But then again the team would probably have stalled over the very concept of a strategy map. People are weird. No matter how it looks at first, it’s always a people problem. And even if you do try to take the first steps – your steps could be in the wrong direction. Even Master Bruce will fall in that situation.

A Story About Lifting People Up

This article is a parable, it’s not a traditional testing post. But as with all parables, this is a story to reflect on. It comes with all the best and noble intentions. [TW: semi-religious content].

There once was this person named Zach. Well, the name is really not so important. It could have been Dilek, Kim, Brie, or Latoya. Zach’s job was to collect fees among the community members – a service job for the benefit of the community. It could, as well, have been removing spam, sorting, and organizing content. And onboarding new people to the community. Menial work, which could be a hassle to the others – yet important for the community to run.

Reflection: What glue work gets taken for granted where you are?

But, there is no doubt Zach had cut some corners along the way. After all, that’s just the way business was done sometimes, thought Zach. And because of that, the fancy people of the community ignored and dispised Zach even more.

To make matters worse, Zach was not as tall as the others. You could say, that Zach didn’t have the same attributes as many of the others. And that made Zach feel further diminished and small in the eyes of the community. And that probably added to Zach’s cheating. Nothing Zach did was ever really recognized.

Reflection: who is putting in an extra effort to be seen?

One day a superstar and thought leader was present in the community. Everyone in the community gathered around and engaged. There was a buzz going on and Zach wanted to be a part of it. But it was still a burden for Zach to engage. Zach had to make an extra-extra effort just to catch what was going on.

Suddenly the superstar called out: Hey Zach! I see you. I will come to join you where you are. And so he did. The superstar joined Zach, the menial fee collector. Zach pledged to be a better person and has been since. Zach is now sharing surplus energy with the others in the community and has made up for the wrongdoing previously done.

Reflection: Are you meeting people where they are? How can you lift people up that are not seen?

Tester Aided in Two-Digit Million Dollar Deal

Yes indeed. It has happened for me in the last couple of months. While my role is not tester anymore (but advisor in testing) – it just wouldn’t make the headline as click-baity. Sorry for that, though it does help to prove the point that testing specialists can be a part of bids and tender teams. A testing mindset is needed even before there is an “system development life cycle”.

The Dealing

In the context of bids and tenders the testing activities are mostly about technical writing around how the testing will happen when the dealing’s done. It’s not so much about finding issues – but more about a coherent analytic viewpoint. The customer of the deal often set up “requirements” that the supplier must answer and is scored against:

• Elaborate on a test strategy
• Elaborate on the suggested test process
• Describe relevant testing documents – don’t overdo them!
• Describe testing types and environments in use
• Describe test tools and approach to automation

If you don’t reply to all “requirements” you get a sub-par score, so being able to find information in the organization is key. The contractor uploads the final documents to the customer and the content is evaluated. The evaluation is usually a balanced scoring between the individual reply documents and the price point. Often price wins, even if the scoring of the (testing) documents where at 100% score.

More and more often I see outsourcing contracts that requests 10-15 test phases. It looks like someone has simply thrown the book at it, and not considered if it is an infrastructure project, a software development project or COTS implementation or – what on earth, they actually want to learn from the testing.

So how do you go about to be in on deals like this? – business context and a seat at the table seems key.

Business Context

First of all you need to be part of a company that cater to this size of deals. The deals I have been involved recently have mostly been about national IT solutions for public and semi-public organisations. The national government rarely have their own IT divisions but hire outsourcing companies to develop new solutions, maintain existing solutions along with hosting and cloud journeys. The more you add into the deal the larger the sums rack up. And similar if it’s a eight year contract for full IT operations, devices/laptops, support and application management services – the deal sum easily ends around the ballpark amount in the headline.

It’s probably different where you live and where you work. You might work on a consumer facing app that is paid pr subscription or perhaps in a team that develop a specific business-to-business product. And that’s cool – context matters. But I know even product houses have to go out and close deals with their business customers ever so often.

A Seat at the Table

Being part of bid and tender teams can be a key role for individual contributors in the staff levels. Staff levels are the senior and principal testing roles – that do not have management responsibilities. The term comes from the book “Staff Engineer: Leadership beyond the management track by Will Larson” and well as from “The Staff Engineer’s Path by Tanya Reilly“. The former book has some excellent chapters on getting a seat at the table and staying relevant there.

While having the role does not guarantee you a seat in the bid teams, neither is a staff role a prerequisite to be in. What matters most is probably management’s willingness to step out and let the experts in on the details. This could also be work that was done by heads of testing and managers of testing. Though as manager you should really focus on servant leadership and let your testing pro’s aid in closing the deal.

Photo by Pixabay on Pexels.com

#268 – Who Brings in New Knowledge?

Well, if you are reading this – there’s a good chance it’s you. Especially if you read this with the intention of sharing this with your team. I hope you do, obviously 😊. But perhaps it’s unclear whose responsibility it is, to bring new knowledge to the team. Is it always the team manager job – or is it a dedicated person that by role, or by habit, that bring in new knowledge?

Photo by William Fortunato on Pexels.com

Implementing Change – First Steps

TL;DR: Stepping into the deep water – have a few supporting first steps.

Photo by Francesco Ungaro on Pexels.com

Inspiration: Ministry of Testing Bloggers Club August Challenge and My three step recipe for overcoming procrastination

A More Advisory Role

Over the last year I have looking to work myself out of the test manager role and into a more advisory role. And by April 2021 I was given the formal title change from Senior Test Manager to Senior Advisory Consultant.

I have had the title “Test manager” probably since 2008, so it’s been a while. In the companies, where I have been employed, the Test manager title has never been with line management (hire/fire). Rather it has been similar to a project manager, with a focus on the testing deliveries of a project, release or program.

I will still be leading test activities, but my role for the future will be more about enabling someone else doing the testing or someone else having a testing problem to solve. There are plenty of test activities done by people in non-testing roles – it’s the activity that matters.

Something About Leadership

17yo: Dad, do you not know how old I am - and what I can do myself? 
Me: Oh, I know buddy. As you are learning new stuff, I am unlearning to help you

While this quote from my kitchen about a week ago, as all to do with the young man learning the ropes of life and me unlearning to always to help them and their 15yo sibling out – there is an key parallel to leadership and building self reliance in teams. My role these days are less about direction and (micro)managing a team of testers on a project, more about enabling others to succeed with their testing both in the delivery teams and in the board room.