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?
At the the recent “Online Test Conference – Fall 2020” a workshop reminded me to look at the problem. And it’s always a people problem. Which got me thinking later on in the program – what’s this talk trying to solve?
Continue readingWe often discuss where the “testing people” fit into the organisation – are they part of a delivery team or an enablement team independently of the delivery teams? The Team Topologies model enables a discussion about this challenge and a guidance on what goes where and why.
I can see the benefits of having a central Test Center of all the testing people – and, on the other hand, having them spread out in the delivery units. I work in an IT services company, sometimes a project does not require full-time test attention. So we work on a range of customers, at the same time. On the other hand, sometimes projects lasts for years and years – and the testing people become dedicated towards a specific company IT stack and delivery team.
Notice that I use the term “testing people” to cover testing specialists, test analysts, automation specialists, test engineers and test managers like myself. Besides the moniker “testers” in the blog title, I try to avoid calling us “testers”. First of all, “testing people” do more than testing and secondly other people do testing too.
The Test Center I’m in is an organisational unit of “test consultants” of various of the mentioned roles working for various of projects. But considering the “whole team approach to quality“, the Test Center unit sounds a bit .. off. Would it be better to assign everyone to a delivery unit? – What would be the reasoning behind what goes where where and why?
I have found the Team Topologies model, which identifies these teams:
The model identifies three modes of interaction during the flow of change:
Based on this model the dedicated testing staff should be part of the stream-aligned delivery unit. While everyone working ideally to enable the team – testing coaches etc – should be part of an enablement team, aka. a center/unit/group/staff team for enablement (Accelerate the Achievement of Shippable Quality). I read into it, that the enablement team’s primary focus would be to build self-reliance in the team and get out of dodge. A key principle in Modern Testing.
How “testing people” could fit into the other two teams (Subsystem & Platform), I would have to consider a bit more. The testing activity is in both, and the Enablement team also facilitate (testing) into those two team modes/units. So perhaps it’s not that different. What do you think?
The findings of the model also aligns with the “Product Team” and “Competence Team” of this article (in Danish): Hvilke karakteristika og udfordringer har dit team?
Reality, though, is a bit more complex. Even the Team Topology Model – is just a model, and wrong a some point. It is though still useful in enabling a discussion on where the testing people fit it, and why.
Even before there is an “system development life cycle” – testing in the form of thought experiments and evaluation can take place and add valuable information to the context.
My test management tasks are often about the next thing coming up. Bids for outsourcing agreements and application development often comes with a large document of test activities to be answered and elaborated. In this role I am the the subject matter expert (in test), and while have to write the tender reply for my domain. Sometime down the line the bid materials becomes an actual project, but by then I’m onto the next thing.
Sometimes I draw an analogy to the Secret Service advance team arriving two weeks before the president, setting up protection and identifying gaps – while then moving on to the next location before the president even gets there.
Another example of advance work for test people, is where the organisation uses frequent releases of systems. While the majority of the test effort is put into the release currently being tested, some effort must go into looking into the frame of the coming release. In the coming release the test manager can look for headlines to test, review initial high level design and find flaws and conflicts in the release content.
Sometimes I draw the analogy to the blue and gold teams of US nuclear submarines. While one full crew is out sailing/delivering, the shore team prepares, trains for the next big push.
Testing early can also be in the form of running simulations on various business case scenarios. Business simulations is all about experimenting and evaluating. For novel solutions prototyping, wire-framing and user experience activities helps develop minimum solutions to be tested for viability by the customer.
In the article “Continuous Testing in Dev Ops…” we see testing happening during Plan and Branch. In the article “A Context-Driven Approach to Delivering Business Value” testing can help establish viable market, match to vision and in identifying business risks.
testing related to revenue generation may focus on functionality or regulatory compliance; testing related to revenue protection may focus on maintainability or legal defense; testing related to supporting revenue may focus on business process improvement or cost reduction.
Testing is a lot of things – also outside the SDLC.
[ Recognise and Acknowledge Your Skills | Ministry Of Testing – The Testing Planet | June 2013]
The below model is directly inspired by the Vancouver Agile Quadrant introduced in “Agile Testing: A Practical Guide for Testers and Agile Teams” by Crispin and Gregory 2009 based on the original matrix from Brian Marick in 2003. It consists of four primary branches – as seen on the illustration. It is not a matrix or a table, but four directions with each their cloud of buzzwords. For specific contexts a mind-map will be a better choice of illustration – try drawing your own competencies.
We are setting up Dansk Workshop on Exploratory Testing (again) inviting testing people to join the banquet. We all test the software, the hardware, the context, the project, the environment the performance, – to give the decision makers information. We need testing people to have all kinds of backgrounds
| This is what the C-D-T is about | Also know as the exploratory testing and the muh muh | further more know as a jam |
Let me tell out about the invitation to the Context Driven banquet in another way: There once was this man who had a great fortune and many talents – and wanted to celebrate. They walked to their friends to invite them to come for the fiesta. One friend just landed a new job – but they where not yet as equal as the others. Another just had a new minivan, and had to test drive it (pun intended). But there where room for more at the banquet – so the invitation is sent to the insecure, to the un-educated, to the start-ups and the emerging thinkers, to the bloggers and the twitters, the black swans, the unicorns and the dancing monkeys….
[ Paul Gerrard | Will The Test Leaders Stand Up | The Testing Planet issue 10, Page 4, March 2013 , Paywall] paraphrased:
There are five broad choices for you to take if you are a test lead or test manager:
It’s probably 6) All of the above
If praise, recognition, promotions always come to a few staff members – the usual suspects – you have a hero culture. You have a hero culture – even though you might think you have a team culture. You can call it a star team all you want, if not the team gets the stars but the heroes, you are not walking the talk. Would you build a software relying on only a few persons? “He got hit by a tram” – is a true story, and it is happening again in software projects. If you only give credit to those that pull out the big fires, you will nurture big fires. You get what you reward….
Sure, recognize the stars – but spread the goodwill. Even heroes needs help. Make every team member feel that they contributed. Try when you lead to reach out to everybody over the course of the project/months days. Recognize them all and say thank you.
Once I was a leader at a children summer camp. Every evening we would make a mentioning of the fun stories of the day. Obviously some of the kids where more “fun” than the others, but we kept a rooster to make sure all were mentioned – perhaps just with a little thing. It meant a lot to be mentioned, even for something silly…
Keith Klain put’s it this way in The Testing Planet 10 – Leadership issue: “Leadership in Testing – What really Matters”: I want my team to take ALL the credit because they are the ones doing all the work! I would rephrase this to: I want to praise the teams I help succeed, but I also need to know that I am part of the team that get’s the praise ;-).
Strip me of all my power, my titles, my roles – and hand them to those that need it to have the courage to stand up, or that needs it to grow. I know I stand on the shoulders of software testing giants (like Keith), I may not reach high compared to them – but I can still lift someone else up, so that we together reach even further. We all have to start somewhere…
Praise people, recognize people, say thank you. The trick behind it is a simple application of behavioral analysis – you get what you recognize: Speak about the good deeds, ignore the bad – but set the line on the ugly. Simple example: If you give your screaming kids candy in the supermarket, they scream to get it next time. Say “no” if they take candy. But what ever you do – praise them for helping daddy shopping. And that goes for adults too! 🙂
I lead many kinds of people indirectly – I coach, mentor, suggest, encourage, question, challenge – and test:
The most important leadership tip I have is to say – Well done, thank you! I know it is your job occasionally to work on weekends and nights and evenings – but thank you, it made a difference to me. I know you will be helping me for a day, and still have to do your “day job”. I recognize you – I see you. I know Suresh said “Jesper encouraged me to go beyond my regular assigned tasks and contribute more to the organization.” Thank you Suresh – I appreciate your effort. Boys – I know you are supposed to learn to do your home work, but good job anyways on completing it today.
4 Reasons Why Culture Is More Important than Strategy | Om at kunne udsætte sine egne behov | Do what you say – say what you do | They are just people |
And thank you for reading 🙂
Being a thought leader is not about being a “boss” – neither is it about being a “manager”. Leadership is not only at monthly or weekly meetings. It is leadership to talk openly and often to those you lead, and go “visit their desk” – also just for a chat. Good leaders create a room for dialog, trust, mentoring and practice.
Leadership is about behavior – not attributes – nor properties. Management in itself is a structured process – perhaps very complex, but yet structured around planning, measuring and decisions. You can manage by Excel, but you can never lead by Excel.
Come to think of it, management can be somewhat automated, setup as routines, macros that verify and tricked by events. Management by bean-counting spreadsheets can be executed anywhere and can be setup as a commodity. True story – you can buy “Outsourcing management – as a service”
Outsourcing management as a service would require strong blend of skills in areas of program management, service management and relationship management. PMOs must own “outsourcing management as a service” and evolve these skills to implement and mature the competencies, and to derive maximum value from outsourcing initiatives
Leadership in comparison is more bespoke, and require a range of tools, tips and tricks – based on context and on the people in the team. Similar to testing and checking, we need to consider both activities – but also learn the difference between them.
So stand up, apply a little courage and be a thought leader in your own right. Stand on my shoulders if you like – it would be my privilege to support you: Establish yourself as an expert or thought leader!
—
#BigSelfishPun – the title of this blogpost and the below screenshot is from an internal presentation by Henry Singer, http://henrysinger.blogspot.com/ from September 29, 2011 called “Blogging for business“, where my internal blog was used among others and an example of good use of a global collaboration tool.
Complexity is a Matter of Perspective 