I get lots of enquiries from founders of start-ups who reach a certain growth point where they really need to start taking control of the quality of the work being produced. Their companies seem to reach a size and market growth where the focus on quality becomes a priority.
This is usually about the time when I get a call or an email and get posed the typical next two questions:
“How do I go about starting a new test function?”
and
“Where do I find a good Test Manager?”
This is a common mistake many companies make – they create many different functional departments with associated management structures (Dev and Test and Release Test and UAT etc etc) when the reality is the work doesn’t (or shouldn’t) flow like that.
My advice is always to “follow the work”, not what the traditional industry titles and literature may advise.
Follow The Work – Image
If you’re in the great position of building your team from the start then study your process and the work before designing the functional teams and the management that sits across that.
In my experience, after studying the work at a high level, people identify that it does indeed move between “traditional” functions such as Product > Dev > Test > Ops > Support etc.
It’s therefore easy to assume that functional departments, with functional management, should be created to service these handovers and processes. But this is a mistake.
Further studying will likely reveal that it’s at these boundaries in many organisations that the likely “quality” gaps are found and time is wasted.
Whenever there is a handover there is likely mis-communication, the breaking down and rebuilding of work and hand-offs between people. This takes time and is likely fraught with mistakes and missing information.
Sometimes it’s possible to make these hand-offs painless – sometimes it’s not.
It’s why so many companies work hard to break down these boundaries (Agile, DevOps, ServiceOps, Cross Functional Teams).
It’s why, refreshingly, a growing number of companies in our industry are creating environments where functional hand-offs are few and far between.
For many people though it’s scary to not have these boundaries and functional silos – certainly between Dev and Test.
It’s why so many people ask me how to create these functions in the first place (I always advise them not to).
It’s scary for people because many people, in traditional roles, often wonder what would happen to them in these new functions. That’s totally understandable. It’s scary to wonder what will become of roles likes Test Managers, Head of QA etc when these functions start to become part of a main Dev team.
- Will they still have a role?
- How will they personally need to change?
- Who manages testing now that Dev do some it?
So resistance appears.
At a test event a while back a Test Manager told me that he would “resist and fight agile to the death”. To the death! (I think he was speaking figuratively)
Why? Because he couldn’t see himself working in an agile team. So he resisted. And by all accounts he did a remarkably good job at this resistance. But it’s not what his business needs.
So why create these boundaries in the first place?
Some companies will never break down these silos which is good news for some Test Managers, like the one who will fight agile to the death.
The sad reality is though that many of these companies desperately need to break down these silos to survive and remain competitive. They are unlikely to do that with people who fight this change.
I did a talk about agile at a large financial services company a while back and I’d say about 70% of the room were shocked at what agile and DevOps looks like.
I got questions about the future of certain roles. I got statements about how chaotic it sounded and how it would “never work here”. Sadly, they were right. It would never work there….with that group of people.
For epic change to happen you need people to believe it will, and that it will be good. I told the execs that it was entirely possible to move to agile within their IT organisation – but not with the majority of their current team. Sometimes we have to face the reality that the people we’re working with are not the people who will bring about change. And that is often a harsh reality too far for many managers.
Other companies are breaking down these barriers. Good news for Test Managers who can adapt, not good news for Test Managers who cannot.
And some companies have the ability to never create these barriers in the first place…….and that’s a great place to be. And that’s why I always advise my startup friends to create as few boundaries as possible, to follow the work and never to go searching for a “Test” Manager.
What are your thoughts on the future of Test Management?
How are we creating the next generation of Test Managers – or as I put it – Managers who care about doing good testing?
Are the certification schemes helping or hindering our evolution to a new way of managing?
Image from Unsplash – by Joshua Earle
Edited and mashed together in Canva.
Great article, Rob. I have had very similar experience with many companies.
The bit that interests me is the fact that it’s fear of the unknown that, I think, often drives the reaction of many. Let’s be honest, that’s totally understandable. Imagine going up to professionals in any industry and showing them a ‘different way’ that turns their world upside down – you’d get the same response.
What fascinates me is the challenge of working out where the break point is with many of the people who are fearful of the change. Can they be persuaded otherwise? The challenge is then no longer anything to do with software development and is firmly entrenched in the world of psychology and human emotion.
I certainly agree with your underlying sentiment – the theme I try to embed with most teams I work with is simple, and to the point – stop seeing “testing” as something you do after “development” and embrace quality as a constant consideration.
Thanks for commenting Elliot. Absolutely nailed it – it becomes less about the job and more about the person. I think almost all of my work as a manager is more about the people and the psychology/behavioural economics etc. Good people know how to do the job, to keep up to date and to make things better. Good managers know how to get the best from people and play to their strengths.
And yep – testing is NOT a phase, it’s an activity 🙂
Thanks for the comments.
Rob
Good post and I agree with all of it.
My view on test organization and test management is, like you say, that testers should be “embedded” within the evelopment teams, a natural part of the process. And a test organisation with test managers, test leads, test architects, what have you should be in place across these teams to support them.
Testers take responsibility for the testing in the team and test management help them by cooordinating larger test efforts across teams and disciplines.
/martin
Thanks for taking the time to comment Martin and thanks for the insights. Support from managers is essential and yep – embedding people in the teams has a tonne of benefits.
Thanks again.
Rob
Rob,
Could it be you are talking about situation when company runs many projects that are not connected to each other and have a test manger who are part of each project. I wouldn’t call this role “test manager”, but rather “resource manager”, a specialized one.
If all they do is a single software product and they want to add comprehensive E-2-E testing to the tests each dev. team does to their developed components or have a single person across organization with specific skills like performance, security testing, automation, etc. I see how hiring a test manager is essential in that context, don’t you? I’ve been such a manager doing exactly 3 things:
1. Compile all the “quality related information” gathered by fellow testers into a single message and deliver that message to customer/executives/whoever don’t want too much details. Translate whatever customer message back to appropriate teams/testers.
2. Mange performance and test automation resources across component teams (well, actually I was the resource myself)
3. Do end-to-end testing myself and consult customer testers on doing them
Thanks for commenting Ainars – I’ve seen test managers at all levels in the process (resource, strategy, exec) that functionally cut up the teams – usually to make it easier to assign functional managers to. Sometimes it works, mostly it doesn’t. The work always flows across boundaries and in my experience following the work is the best way to improve things for the customer.
Thanks for sharing your experiences with managing work across boundaries. I don’t agree with needing a Test Manager performance, security, etc. I think you need a manager – but not a Test Manager. That’s the point of this article really – good managers will always be needed, but specialist managers are becoming less required. A good manager can manage developers and testers if you’re hiring good people who are specialists.
Rob
I am a tester that recently became a test manager (again). I don’t worry about my job because I’d be happy as a tester (again). I don’t worry because I’ve hired hungry (sometimes) young testers that are ready to learn when I pair with them. I don’t worry because it’s a full time job protecting the team from interruptions, problems, and politics. And I don’t worry because all jobs are temporary so why worry about it.
Hi Rob, really good post, thanks for sharing.
Your “follow the work” reminded me of when Don Reinertsen teaches of not focusing on resource utilization but on improving the flow of value.
I agree 100% with you that handovers between different departments create waste and a modern, lean organization will remove them towards a more collaborative work style. This, unfortunately, is not the only issue of a siloed approach to software development. In fact, once you have separate organizations (let’s imagine dev and test) they will optimize based on measurements within their boundaries and this always causes a sub-optimization of the whole system, difficult to identify and extremely hard to correct.
Many years back I was one of those test managers, faced with the reality of change I decided to adapt and rediscover a new role within my organization. I enjoyed the change and learned so much in the process that today I help organizations go through change. That’s why I tell the people that are going through a change, to acknowledge it, accept it and if the want to enjoy it, to BE the change.
Hi Augusto,
Thank you for taking the time to comment. Thanks for the insightful comment to – I love the BE the change part.
It’s great to hear from people who have seen this type of change first hand and now help companies to make it.
You’re spot on about the measurements – often the measures that the teams optimise towards are not aligned across the bigger system – makes it tricky improve the system for the customers 🙂
Thanks again.
Rob
I know that I am resurrecting an old post now, but I have just been introduced to this blog, and it contains a concept that I agree with and have though about hard for some time.
“…it’s at these boundaries in many organisations that the likely “quality” gaps are found and time is wasted.” (I think we can omit the further study will likely reveal – I believe this to be a fact already).
Once you accept this fact – or at least feel that it is worthy of further investigation – it becomes quite scary to see how many boundaries there are in (traditional) software development.
I characterise it as a huge and complex game of Chinese whispers (if you are in China, I apologise, I expect it’s called English whispers there?) – with each whisper point being an effective boundary to clear communication:
Business as a whole to the business representative to the project (known in Agile as the Product Owner – no established name for the role (to my knowledge) in traditional development). The whole business needs to ensure the business rep knows what they need, in order to communicate that need to the project.
Business representative to Business Analyst (often verbal supported with notes)
Business Analyst to Requirements (I know this sounds odd – but a lot can get lost in translation between the BA’s understanding and what they commit to paper and how well they write it. (As anyone who has tried to write anything of any length will know – it turns out that writing things down clearly is jolly hard to do).
Requirements to Systems Analyst / Systems Architect – no matter how well something is written, it can be misinterpreted.
System Analyst/architect to design documentation (insert your own preferred names for the layers of design docs that get created) – same problem as for the BA – the SA has to write it down clearly.
Design documents to developer
Developer to code
Code to unit test
Unit test to Component integration test
Component integration test to system test
System test to System Integration Test
System integration test to User Acceptance Test
UAT to Live.
And that’s the simplified version. (I have used traditional language for simplicity – not intending to start a debate on the validity of the different levels of testing or the possible existence of more).
What is the chance of a whisper going in one end and coming out the other the same? Especially as half the projects out there don’t do any quality checking at half these whisper points.
Unsurprisingly, perhaps, I see Agile (an approach that tries to address this problem head on, along with others) as a godsend.
Hi Joe,
Welcome and thanks for the comments. Sorry it took so long to respond I’ve since stopped contributing to this blog and have shifted over to http://www.cultivatedmanagement.com.
I’m glad this post resonated with you and it tied to what you’ve seen. And thanks for taking the time to leave a comment.
Thanks
Rob