Before some of you start freaking out, let me make this clear - no, it’s not the pot some of you might be thinking of :) It’s an abbreviation of “Problem on Table”, an activity we have recently started doing at XING AG for its testers.
As facilitator, I have experienced the benefits of POT method of problem sharing (and solving). I was first introduced with the idea at ITB tester meet-ups I participated in Pune/Mumbai and in order to facilitate such exchange for testers at XING, we decided to give it a try with some twist. And guess what? It worked really well!
How does it work?
The key idea of POT session is that testers come together and share their testing problems. This is done in order to get support from fellow testers who might have faced similar problems before or you find more testers facing similar problems and then work together to solve them.
The format of POT sessions I did in past used to turn out chaotic soon, because of lack of moderator control over discussions, too many topics being discussed at a time etc. And that sometimes used to confuse the problem presenter instead of getting solutions to the problems they shared.
Presenting "POT – the Lean Coffee style"
To make the exchange less chaotic and inclusive for everyone, we decided to do it in Lean Coffee way. And boy, it did wonders!
If you are aware of Lean Coffee and now POT then it should be rather easy to guess the format.
Set-up notes for facilitators:
Here are some simple rules we followed that worked great for us:
And that’s it. You are ready roll!
Our first POT- Lean Coffee style session went on for two hours with five minutes break in between and I am super glad that we had some much cool stuff to discuss and everyone had some or the other idea to solve their respective problems. That’s the power of teamwork, isn’t it?
The key takeaways from our first session:
In two hours of highly engaging discussions, below are some problems we discussed and the solutions we felt could help solve those. I strongly feel that many testers would face those challenges regardless of the organizations they work for and hence I am sharing the solutions we discussed, hoping that others with similar problems might find them helpful.
Problem 1: What happens when Tester goes on vacation?
A classic problem many Agile teams face in my opinion. So, when tester (who is generally only one person doing testing in team) goes on vacation or falls sick, the team usually suffers and tends to rely on automated tests or performs minimal testing which often results into big problem. What a tester can do to solve it? Or if I may say, what teams can do to solve this problem? Here are some ideas that have worked with some of us:
Problem 2: How to manage integration testing with different teams/apps?
If the app your team builds is just one part of several applications working together for your one business product as a whole, it often becomes challenging to plan out and maintain hassle-free deliveries throughout. And end-to-end testing becomes even more challenging under some circumstances.
Different teams are likely to have different notion of quality, different development methodologies, different business plans and thus, naturally different release plans. Things become chaotic when testers are left alone to solve such problems, or when such problems are identified very late in development of some feature with rigid deadline.
And who else can understand such problems any better than fellow tester from other team? Do you see some solution there? We did and I believe it helps. Here are some ways to facilitate that:
Some of the other issues we discussed were around pushing for bug-fixing, fixing high-bug-tolerance problem of agile teams, common pitfalls of agile testing, what real agile testing should look like etc. One of the suggestions from our experienced tester Dirk Meißner was to hire programmers who take testing seriously and have quality mindset. I feel that’s very good approach. Precaution is always better than cure, isn’t it?
So that was about some key things we discussed in our first POT-Lean Coffee style meet-up. And we are already excited about the next one. How about creating one in your organization and sharing your learning with us, just like I did? Let there be some coffee, some delicious cake and of course some Problems on Table. Enjoy!
Header image credit - wall.alphacoders.com
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!
With my experience as an Agile tester so far, one thing I see organisations still struggling with or trying to get better at are the estimations.
While thinking deeply about what makes our estimations go wrong I realised that there is still a lot we do in projects that we do not record, measure and consider as factors that matter. And that is probably why we are still trying to get better at estimates. And that is also probably why the ideas like #NoEstimates make sense and are getting popular.
A few thoughts on #NoEstimates first
At Agile Testing Days 2016 conference, Vasco Duarte made an interesting keynote around #NoEstimates. I admit, I do feel bit brainwashed by his ideas but I believe that NoEstimates is not about "not estimating at all". It's about doing estimates sensibly and without blindly following the tools that are being widely practiced.
And, in my opinion there is still some way to go till industry understands and starts practicing the key idea behind NoEstimates. Does that mean we should stop estimating right now and wait for an entire industry to on board with it? Absolutely not!
By the time this idea develops further, I think we should continue to make efforts towards doing better estimates. After all, the fact is that business needs some date to baseline their business plans with and I find it totally reasonable.
What's wrong with how we currently estimate?
I think the problem is not just with how we estimate (story points, T-shirt sizes for example) but also with what all we measure, how we measure and what we take into account from all those measurements.
I strongly feel that there is cause and effect relationship between things we measure and our estimations based on those. If we do not measure what all matters, our estimations are likely to be flawed. And honestly, it's high time that our industry stops measuring things that are easy (and cheap) to measure rather than those that matter but are difficult to measure.
What are those things that (also) contribute to poor estimates?
I can only talk about things that I have seen making an impact in my experience but I feel they can be very much present in your project environments too. Generally, these are short-lived impediments/side-tasks that we forget to record, measure and consider such as :
It's not that we totally ignore the efforts spent on all of the above but typically those cards remain on the dashboard only for the duration of the sprint and then are thrown in dustbin when sprint is over. What if we start recording, measuring and considering them for future references? Would it not help? Where is the problem if yes?
Where is the problem?
The problem, in the way I see it is that, there aren't enough techniques that would help people identify what to measure that matters and how to measure it. In order to measure things, first we need a mechanism to observe them, and record those observations in order to measure them. I feel that for a project-team as a whole, we currently don't have any effective mechanism to address this. This same problem had been haunting testing community badly (and caused great damage too) but I'm glad that in the form of Session Based Testing (and Management) the community found a sensible way to do it right.
Hey, but that's just about testing and test management. What about measuring things (like above) equally effectively for the work that programmers do? After all, estimations are for and from whole team (and not just programmers or testers alone) unless context demands it to be otherwise.
Thinking about the solution
I am wondering, what if we extend the key idea of Session Based Testing to programming as well? Yes, something like Session Based Programming?
If you are not from testing background and don't know about SBT(M) then I encourage you to read about it first. If you are a tester and still don't know it yet then please do yourself a favour and read it NOW!
Well, what do I really mean by Session Based Programming? Here is my proposal:
1. Development to be done in focused, un-interrupted and time-boxed 'programming sessions', typically of the length of 30 mins or 45 mins (short sessions) to of 80 mins or 90 mins (long sessions).
2. The way testers define mission and create charters for their test sessions (in SBT space), programmers may pick stories or tasks and can work on them in time-boxed way.
3. Typically, testers perform different types of session in SBT such as Analysis session, Survey session, PCO session, Deep testing session etc. Similarly, programmers may also classify the type of session they would be working on. Right off the top of the head, I would propose the session types like below :
These types can vary from project to project. (May be you think of new ones and let me know too?)
4. Keep the record of actual time spent on what type of session with challenges faced if any and store them to some central location.
And how do we estimate with these?
Once programmers spend enough time working in this way, over the period of time, they are most likely to develop realistic understanding of how many sessions of what type are likely to be needed to complete some story or task. This is because it is going to be based on actual experience and by keeping the actual time spent on so and so type of session in mind.
Let me give a small example. Assume that for some XYZ story, particular complex feature in your application roughly requires some back-end programming efforts, some front-end changes and testing. A programmer (and tester) who has spent enough time working on respective area in Session Based way may come up with estimates like:
BE programmer: 3 short back-end coding sessions
FE programmer: 1 long FE+BE pair programming session
Tester: 1 short Analysis and 1 long deep testing sessions
Assuming that short session in your team corresponds to 30 mins of time and long session to 80 mins then by calculating and combining above inputs, we can estimate the story XYZ to be taking roughly 280 ( 90+80+30+80) mins of work.
But wait, assume that historic record of time spent by team on Unplanned activities sessions, Bug fixing sessions, Deployment hiccups per sprint (of 10 stories on average) amounts to be around 200 mins (that is 20 mins for one story) . I would add this as buffer to initial estimate of 280 mins and would count the final one as 280+20=300 mins.
What is the benefit?
I think there are more than just one such as:
I feel that testing community has mostly been at receiving end whenever some new and shiny, cool thing happens (e.g. DevOps) and they are usually left to figure out how to "fit in". The efforts testers spend on these "fitting in" attempts are usually so high that they hardly get to contribute to the advancements beyond their own craft.
If testers are to evaluate and to contribute to software quality, then they should also evaluate and contribute to the quality of processes that affect them (and everyone else). Session Based Programming is my humble attempt to accomplish that.
I look forward to know how you find it. Feedback and criticism welcome :)
[On side note, I presented this idea in my Lightning Talks at Agile Testing Days conference- 2016 and got some good feedback, especially from Janet Gregory. We discussed to work on it together to take it further and I would like to thank Janet for encouraging me to do so.]
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.