Continuous Customer Feedback

There are many ways for continuous customer feedback. In coding deliverables, you can demonstrate how the solution works so far and monitor the usage to get actual data on the end-user experience. It’s proven over and over again that faster feedback loops are essential to optimal deliverables – and to improve business performance. Go read Accelerate.. again! Here are some of my tricks for the non-coding deliverables as a staff-level testing consultant.

Provide Continuous Training

One task I have is to help others manage the testing activities. It’s usually people fresh out of Uni – as long as there is curiosity the rest can be learned. The way I usually do it is to have an intro session, break down the first few steps and then have recurring meetings to align and dig even further into the tasks. My outcome as a leader is to make them self-reliable in doing the tasks. The usual struggle is for me to sit on my hands and to pause more.

Simon Koerner suggests these five ways to lead when not in charge:

  • Be proactive
  • Motivate those around you
  • Look beyond your job role
  • Recognize others
  • Share your knowledge

Continuous Test Plan Alignment

I’m currently leading a testing activity to deliver some IT services to company A. There’s a huge contract that stipulates all the mechanics of delivering these services. And for each testing activity, there is a good old-fashioned test plan document that needs to be delivered and approved by company A. (sigh)

The old-fashioned way would be for me to prepare the document in detail and forward it formally. If you have to write too much down and debate the documents over and over – it might be an organizational maturity issue, but it’s most likely a people problem and a trust issue.

Recently I have started stating that the test plan will be presented continuously. At my weekly meetings with the Customer A test responsible persons I present the current draft of the document. This way they see it being developed step-by-step and we can align – and the approval will be a formality in the end. I prefer this way of working – but have also failed where the customer expected detailed hand-overs and I preferred to work entrepreneurially to set things in motion.

Limiting Contracts Replies to a Few Pages

When working with large IT services contracts it’s unfortunately customary that there are requirements for the content and headlines of test plans and other test documents. These content requirements are often straight out of old templates listing testing deliverables, testing types, and physical conditions for the testing activities. No test documents will be approved if there are sections missing, as the list items are contractual minimum requirements. No one wants to be non-compliant with a contract based on a missing headline in a document somewhere.

The contract authors and their lawyers would probably argue that it provides business value – at least in the sense of comparing competing companies submitting for the contract. That best-practice templates are market-leading. Yet, the case is over and over again that best practices will only give you standard solutions that are not tailored to you.

In the year 2022, it’s so awkward that you have to address physical rooms and equipment as a required element. Sure if it’s special in this case, by all means. But usually, it probably isn’t that important. Preferably we should make situational aware test plans – but if your content isn’t as innovative I recently wrote a reply in a big contract tender for customer B reply that solved this in a good way.

For the contract, customer B requested a maximum of 4 pages – where we had to elaborate on what we would advise the customer and our experience in doing so. See we don’t need 100 pages to convey a quality narrative. And based on our reply they could still evaluate and score us on how well we understood their situation.

Continuous customer feedback succeeds when we show that we understand the customer.

On the Shoulders of 112 Giants

In my book “Goal-Aligned Test Strategies,” I draw extensively on the work of others. This is a reference post to further credit my reviewers and to list the 112 references in the book.

Special thank you to Lonnie for my writing evenings and to Simon Wardley for finding a path.

Reviewers and Feedback

Continue reading

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
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

DarlingsPetsCattleGUID’s
New projectFixed date
Existing delivery speedScheduled
Quarterly
Test Environments, internalRepeatable
Test environments with integrationsCraftedSome existing know-how
Environment InfrastructureHosted data center practices
Test dataKnown 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

DarlingsPetsCattleGUID’s
Test team collaborationGrowingPervasive
Test leadGrowing
MentoringEnabling
Domain know-howGetting there

Test tools and approach

DarlingsPetsCattleGUID’s
Test activityExplore integrationsConfirm internal requirements
Test casesExisting can be updated.
Test case reproCreate 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:

  • 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:

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.

#269 – We Have Outsmarted Ourselves Again

Links from my talk at “map-camp-use-case-edition” Nov 2021:

Blogposts:

Photo: Kimiya Oveisi on Unsplash, https://unsplash.com/photos/rzsBKBb96HA

#266 – Retraining Yourself for the Future

The local university college has a big sign outside saying: “Retrain Yourself for the Future“. The thing is – what is offered is at best years behind the current practice in the industry. If you certify towards a body of knowledge, you forget about the learning journey and only on the outcome. Innovation yet happens in many ways – and industry practitioners are only one form to train for.

Continue reading

#264 – Create Situational Aware Test Plans

From the endless discussions on the proper content and contexts of a test plan, it’s apparently still needed – but what goes in it? Let’s create situational aware test plans inspired by Wardley Mapping.

ISTQB template-based test plan documents are in my personal opinion no longer industry best practice. First of all it’s bloatware. While they intend to be a springboard into considering what is relevant we have ended up with 8 page templates – where every single of the 20 topics are required information. While it looks dazzling – it’s like frosting puffed with empty calories.

What most people delivering effectively software are using is 1) modern test automation and 2) modern test case management tools to lead and manage the test activities. And there is clear research on what 24 factors correlates to high-performing teams. It seems to me the templates have been frozen stale since 2012 – and are hindering us more than helping.

Continue reading

#263: There is a Model for your Trouble

Often directors, managers and other decision makers talks about an advanced challenge they have: What can we automate, who should automate and what tools to pick. There more and more I listen, the more I hear – they have not applied any models of the problem at hand. And there usually is a model of the problem space already. Any old model is preferable over no model at all. But it can be hard to see in the middle of chaos.

Continue reading

Hunches and Hard Truths

Recently I was in a network call on the use of automation and machine learning in detection of skin issues (EDB 5.0 in Danish only). Similarly I was reading about automation in the legal space. Both these stories align with the struggles we see in the discussions around how much we can automate. We can model it on this simple continuum between hunches and hard truths:

Continue reading