Considering my experience and what I have been observing in the industry, there seems to be an increasing interest in the idea of Whole Team Quality. The idea itself is not new as far as I know but certainly, there seems to be more awareness and eagerness towards its implementation, lately.
Why is it needed and how does it help?
Well, if you are delivering a product as a team, it is natural that everyone who helps build the product is responsible for its quality, or is supposed to be. And for more on this I would urge you to read another article from me on this topic.
Where is the problem?
When I tried to figure out how different organisations and teams are going about Whole Team Quality, I realised that asking everyone in the team to test (or asking programmers to test) and automating as much as possible is what they consider Whole Team Quality to be.
I see several problems with that approach:
Sure I do support the idea of Whole Team Testing to help achieve Whole Team Quality but how do you go about it makes the big difference.
Over the last four years, I tried different ideas, did experiments in teams for succeeding with Whole Team Quality. I failed but I learned. I continued to try and eventually I would say I succeeded it in. Succeeded in achieving Whole Team Quality in a meaningful way. The way in which risks are found earlier (even before they manifest as a bug in the product) and the Quality is assessed/analysed/addressed/achieved on every level and by every individual in the team.
The solution that is working for us
Based on my experiments and learning, I would like to present the model and framework I have developed and am still experimenting with. It has given me and my team useful results so far and I would encourage you to try it too.
The model: QualiTri for three notions of Quality
Having deep philosophical discussions with Michael Bolton when he peer-reviewed my paper on Whole Team Quality, helped me formulate/conceptualise QualiTri. And this model further guided me to create the framework for its implementation.
Like I said before, focusing on the Product notion of the quality alone is not enough. To succeed with Whole Team Quality, it is equally important to understand Project and the People notion of quality. They are related and they do affect each other. That said, to deliver a quality product we got to be equally conscious about the project and the people notion of the quality.
The framework: Quality-conscious Software Delivery
The challenge was how to really go about implementing QualiTri model in a context. And thinking about it helped me formulate my goal to be to achieve the delivery of quality products by quality-conscious people using quality-empowering processes.
How to implement the 4E structure of QCSD can vary from context to context but below is how we implemented it in our team which has worked great for us so far.
Going further in detail of the implementation of 4E structure for QCSD framework would require a series of blog posts. It starts with creating awareness, convincing your team for the need of it, considering their inputs, evaluating the project context and creating the workflows/action items together with your team, and then committing for the efforts needed. It's a process that takes time. Plus it is highly subjective from project teams to project teams and their contexts. And hence I would rather stop here for now.
How do we know it worked?
Below you can see the Lead Time graph (solely for representation purpose) before and during an experimentation phase of QCSD in our team (based on the improvements we did in the processes, consciousness with which all people worked with and keeping quality of the product in mind).
I believe it was the first sprint in a long time, where we as a team finished all the tickets and pulled more, the so-called testing bottle-neck was minimal and the bugs reported that would make into the backlog or warrant some critical rework post-production were negligible.
Sure, this graph did not remain ideal all the time. Teams change, business contexts change too which affects the overall delivery and quality of the product we end up shipping. But if you know how to go about delivering a quality product by quality-conscious people using quality-empowering processes, I am almost certain you will do way more good than bad. And it's a win in my opinion.
See if you find it worth the shot. If you would like to borrow my help for consulting/implementing this idea for your team or organisation, it would be my pleasure. Just let me know.
"I am software tester. My job is to break software." , said one student in my Exploratory Testing workshop. I asked him to elaborate and explain me his techniques to break the software. He was silent for moment and then said he did not know how exactly to answer that.
I further asked about the last defect he found and how did he find it. He could explain that to my satisfaction. Then I asked if the defect was already there or something that he did introduced it. Student realised where I was coming from and admitted that he did not break software, he only helped to uncover the software which was already broken. Then I asked him once again to explain his techniques to uncover those already broken points and he explained that to my satisfaction again without getting frozen in between.
One of the important lessons I have learned from James Bach and something that I make sure to propagate in my discussions with testers is that, we (testers) need to be careful of the vocabulary we use to describe our work because it indeed makes big difference. With this little change, I have experienced the change in me in terms of how I perceived things before with the use of established vocabulary and after starting to choose my vocabulary carefully. That's not it, I have witnessed that when you help people to realise the same in a constructive way, they also make sure they help others to realise it. And this "chain reaction" of propagating that gesture is in my opinion, an important part of contributing to the craft.
I came across this thought-provoking post written by Maaret Pyhäjärvi (influential colleague in testing community I respect and admire ) and some of the arguments she has made, made me ponder upon my own attempts and experiences.
In her blog Maaret says:
Instead of changing the vocabulary, I prefer changing people's perceptions. And the people who matter are not random people on twitter, but the ones I work with, create with, every office day.
I totally support the idea of helping to change peoples' perceptions. I have made those efforts and have seen that taking effect. The approach is very much in line with Weinberg's idea of influence and that has always been my first approach towards changing something. However, the results in this particular case in my experience have been short-lived. I found people to be coming back to their initial understanding which was primarily shaped by established vocabulary and every once in a while I had to discuss the same thing with them again. Can I say my efforts were paying off? I guess not really.
What was and is the problem?
I realised that people that I had helped change their perception (mostly programmers and non-testers) got back to old vocabulary because other testers and stakeholders they were working with, were totally unaware of what they were talking about and why. Those people found it very frustrating to explain others their rationale behind using different vocabulary and eventually they gave up. I remember of one programmer friend coming to me and saying that he felt silly and stupid because the tester he was talking to was totally clueless of what he meant. And he finally said if testers themselves don't care about what their vocabulary should mean, why should he? And he was right!
The problem is, testers who understand the problem with established vocabulary are very less in number as compared to an entire lot of project stakeholders who use it. And testers who make an effort and help others to change their perception are even less.
And this is why I personally see the problem with "living with" some established norms which need revision. I think it's a high time that we strongly disapprove of what we do not believe in. Because it badly affects all the efforts made by people who care. When we know about problem with things and still decide to live with them, our awareness about those problems becomes pointless or less effective if not.
It is not just about people around us
The other day I watched this humours video by AIB on mass technical recruitments where they pick two gardeners towards end of recruitment to fill their quota and say, "Let's put these two on manual testing. Who requires talent for that anyway?"
That was very difficult to digest for me but at the same time, I could not blame the producers of that video because our established vocabulary is not their problem. They just presented the widely established (and mistaken) perception of our established vocabulary.
If we as testers don't care enough about changing something wrong just because it is established, we are letting others shape wrong perception about our profession and that is a silent killer. One of the leading testing tool company recently tried to showcase "manual testing" as outdated, bad testing and proposed their tool that supports Exploratory Testing as a solution. Major part of our industry still considers testing = manual testing = bottle neck and hence thinks of eliminating testing all together. But in reality what they want to get rid of is bad testing only and not manual testing or testing as such. If it is not us then who else is supposed to care about these problems and make efforts to solve them? And I don't know how best we can stop it other than getting rid of the labels and classification which is adding a lot to confusion.
In my opinion, we are responsible for how we let others shape their understanding of us. And no matter how hard we try to do it with people around us, there will always be people beyond our scope who will undo what we do. If we keep collecting the karma of living with established vocabulary and do not make deliberate efforts to change it, it is most likely going to haunt us and our generations (if at all we survive).
It is now up to us whether to collect that karma or to cleanse it. Cleansing sounds reasonable to me but I am still looking for more options . What if we do both?
Nothing beats the pleasure of talking testing with old friends on cozy afternoon of weekend. Even better if it is long weekend and weather is awesome (I must tell you I have fallen in love with Spring in Germany).
I met Pratik last weekend after quite some time. Apart from working together on Tea-time with Testers, Pratik and I have also worked on setting up and running Testing CoP under TCS-Cisco relationship. Pratik is now setting up Testing CoP for his new team and wanted to brainstorm around things we did in past. Instead of keeping our notes just with ourselves, I thought I would rather share them in this blog so that others can benefit too.
Before I jump onto the outcome of our brainstorming, I would like to talk a bit about my personal experience with Testing CoP.
After TCS, I took up an opportunity with Barclays Investment Bank (GTC lead by Keith Klain) and there I was privileged to work with awesome testing leaders like Leah Stockley , Kshitij Sathe, Shrini Kulkarni and Sudhanshu Bodoni. During my tenure at Barclays, I worked as Test Strategy CoP Lead and then Testing L&D CoP Lead under Innovo8 program. Apart from that, I was teaching RST full day workshops and running Lean Coffee style testing meetups with awesome bunch of testers in the organisation.
All above activities that I got to perform have helped me understand testing even better and most importantly, the experience has taught me the skills and lessons for successfully leading CoP. I value those lessons a lot since CoP set-up is generally different from typical project team set-up and each of them require sort of different skills to lead.
That said, below are some lessons learned we feel could help one working with Testing CoPs. However, I must say that they are based on personal experience and others' experience can differ.
1. Start with having a clear goal in mind
Working with CoPs can be tricky if you do not have a clear goal defined. The big part of it also depends on why your organisation or unit wants to start CoPs at first place. Is the purpose to stimulate communication and collaboration? Is it being done to foster innovation? Is the end goal to enhance productivity and building skill sets? Is it about creating reusable components? Or is it as broad as establishing an intellectual work/testing culture? Also keep in mind that an organisation-wide CoP goals may not clearly tell you what they mean for the individual CoP you are looking after. If you are to lead CoP you must understand the bigger goals and be able to define the goals for your own CoP that are aligned with them. At the same time, keep in mind the dynamic nature of CoPs and be open for shift in focus as community evolves. The challenging part is not to let the group get too much dragged away from original goal but keeping them motivated at the same time. There is a way to address it. Let's talk about it bit later.
Indeed it is possible to start from no clear agenda and then letting the CoP evolve. But I personally feel the danger of running into chaos and getting into situations that are difficult to manage with that approach. Of course, you can work with other members of the CoP and come to the common conclusion of the goals for your CoP. Again, this is not as easy as it may sound. There might be conflicting situations, differences in opinions, disagreements on action items, lack of participation, motivation issues and what not. More on that part later...
2. Know your success criteria
Another important part is to be able to measure the success or effectiveness of your CoP. One may argue that CoPs are meant to be informal, ever evolving and all but it is hard, rather pointless in my opinion to run CoP without any measures for success. Wenger-Trayner in their book on CoP mention that, "It may be difficult to attribute with 100% certainty the activities of a community of practice to a particular outcome. You can, however, build a good case using quantitative and qualitative data to measure different types of value created by the community and trace how members are changing their practice and improving performance as a result." And I totally agree with it.
As a Testing CoP lead or member, you may want to understand what practices testers are currently following, what are current challenges and what changes they did from inception of your CoP. That will tell you what impact your CoP is having and the value it is creating. A classic example from my experience with Barclays' CoP was that we saw testers adopting Context Driven Testing and RST practices in their work. Switching from traditional excel based format of test case writing to mind-maps and ET charters was noteworthy. With CoP in TCS-Cisco, we noticed more and more testers taking active part in online testing forums, writing testing blogs, participating in competitions, creating reusable components and coming up with solutions that were never discussed before. As a matter of fact, we created "Tea-time with Testers" magazine for global testing community by taking inspiration from the work we (me and Pratik) did there as CoP leads.
3. Be the change you want to see
From personal experience, I can say that motivating others and inspiring actions is key factor for the success of CoPs. Throwing ideas is other thing and proposing ideas with practical experience around those is a different thing. The latter is more important for CoP since "Community of Practice" is essentially about people with practical experience of what they come together for as apposed to "Community of Interest".
To be able to lead CoP or to be an effective member of it warrants you to have hands on experience of solutions you propose or ideas you pitch in. The more experience you have the better it is for you to help others. You can not just expect someone to present at a conference or write a testing article or implementing some new testing practice without you having done it yourself first.
Most importantly, people in general don't like to be told what to do (thanks Leah for this important tip) as they have intelligence, experience and opinions of their own. And that's quite natural. If you want people to buy your ideas, you better demonstrate them how you did things, what benefits you gained and how you solved problems on the way. That way, most of the open minded people would at least try your suggestions out before turning deaf to your proposals. Remember, it's about also about people, community and not only about your own personal choices.
4. Be a People Person (and not a person liked by just few heavy-weight people)
Even though it is of Practice, in the end it is a Community and it's about people. As mentioned earlier, a lead of a CoP may often need to deal with conflicting situations that may prevent members from contributing their best . Some of the reasons for these barriers as per (Wasko & Faraj 2000) are egos and personal attacks, large overwhelming CoPs, and time constraints. I would add petty politics and favouritism to this list.
For running a successful and healthy CoP it is important that one connects with people very well, understands their preferences, listens and values their opinions and rejections alike. The better connected with people you are the more likely you are able to affect their participation in CoP in positive way. Mapping knowledge and identifying gaps is one key problem CoPs can solve and a 'people person' is likely to be well equipped to make it happen for they will know "who knows what" or "who can solve xyz problem" or "who can be the right person to make something happen". The best thing you can do as a lead is to give right opportunity to right person and not getting tempted to give it to someone just because you like them more. Be transparent and care for everybody's contribution, your people with love you.
Sometimes leads also fall into trap of keeping only heavy-weight people happy and with that pressure they expect other members to support them. This causes more bad than good and is a great recipe for stopping evolution from happening. There is very good reason why Kipling says, "walk with Kings—nor lose the common touch" . Listen to the wise men :)
5. Care to connect with the Community outside
Just knowing about people and practices within organisations is not going to help much if you want your CoP to truly create some difference.
Be it for leading a CoP or becoming its influential member, your connect with outside community (the global community if possible) is going to empower you like nothing else. Connect with people/communities outside, see how they are solving similar problems, learn from their mistakes, see how they are making something happen, know what is their criteria for success, what resources they are using, can you borrow something from them? Can you make use of their expertise to serve your CoP's interests? Perhaps you can invite someone from outside world to conduct a workshop or deliver a guest lecture? There are endless possibilities here....all you need to do is caring about your own learning and community connect.
If you know outside people in person then even better but knowing about work done by some expert can also help you make a stronger case for your proposals. Read articles, participate in community forums/chat groups, attend conferences, join webinars..there are endless possibilities here too. If I need to give examples, my experience with Weekend Testing sessions gave me great insights for running test sessions and introducing new testing concepts. Because of our personal connect, James Bach did some guest appearances over skype for our teams and local meet-ups and that inspired testers to great extent. My voluntary experience with teaching BBST Foundations through AST connected me with several passionate testers worldwide and we still help each other with ideas when needed.
The global testing community is the best community of practitioners I have ever seen and you will never run out of help should you ever need it, that is assured.
6. Make it Bottom-up but also a Top-down thing
If your intensions are good, efforts are sincere and have powerful friends in your organisation then there is nothing that can stop you from doing good. Understand what big people sponsoring CoPs want to achieve with it, especially with CoP that you work with. Ask them how you can help them solve their problems together with awesome bunch of people in your CoP. This would not only help you to align and priorities the goals for your CoP but also it will help people understand that their contribution (no matter how big or less) matters to the organisation. And this motivation is far more powerful in my experience.
On the other hand, try to bring big people in your CoP meet-ups or important event sometimes. A small pat on back of your group will make miracles to happen, I tell you. I still remember some occasions when Keith Klain (who was GTC's Global Head then) found time from his busy schedule and spent time with our Lean Coffee group. The impact of that interaction lasted for longer period and it helped us gain better clarity of what was expected from us. Needless to mention that such interactions help you crack some hard nuts without having to behave tough on your part. Try not to burn the bridge with people because you are going to have to work with them in the end. Leave such problems for big people to handle. Their attention to your work is enough to solve some tricky conflicts.
These things appear small in nature but I recommend you to try it and you'll thank me later for this tip.
7. Don't make promises you can't fulfil in your capacity
It's hard to motivate people but not entirely impossible. What matters is your ability as a lead to understand what an individual takes motivation from.
In order to keep people engaged and motivated, leads sometimes make promises for tangible returns such as promotion, pay raise or bonus. Don't make such promises unless you can really make such decisions or influence them any way. Instead, find out what motivates people by spending more time with them. Extend your engagement with them beyond formal meetings. Build personal connect. Seek for people who are motivated by intangible returns like reputation, self-satisfaction and self-esteem, networking opportunities aimed at interactions, learning and sharing. And try to make them visible so that others also take inspiration from them.
8. Identify your own motivation and be true to yourself
On top of this everything, make sure to identify what motivates 'you' first. An early access to information sometimes makes people want to do things and their interest/passion usually fades up once they get what they wanted (pay raise, promotion etc.) or when they realise it's not going to happen for them. There is nothing wrong in getting motivated with tangible returns but please also make sure that your passion does not die regardless of returns you get.
In my opinion, it's passion that makes a big difference. Keep doing your work sincerely and good things will happen to you sooner or later.
Well, that's all I could recreate from the notes of our discussion.
From my experience with leading CoP for over five years I can say that one needs to be jack of all trades and master of many to be successful here. Some of those skills are relatively easy to acquire but none of them can be acquired over night. Certain things can be learned only through experience and over the period of time.
You got to be passionate and be patient at the same time, and that has been my biggest take away whilst working with CoPs. I hope you find these tips useful in your adventures around CoPs. Don't hesitate to reach out to me if I can be of any help or would like to discuss. Good luck!
A passionate & thinking tester. Trainer & student of the craft of testing. Father, Foodie and dog lover. Chief Editor and Co-founder of Tea-time with Testers magazine.