I have no time to learn

A common sentence I hear from my fellow testers especially when I ask how they keep themselves updated and how they learn about a new technologies are “I don’t have time after work”, “I don’t take work to home”, “I do my work and go home and relax”, or “after work is time to relax or have fun, not to learn”. In the same time, there are many testers I know who are out there learning, managing work, and managing personal life and then also share their knowledge with others via blogs, webinars, conferences etc.

If you are person who do not like to spend your personal time on learning, keep updated with the outside world from your office, then this post may not for you. If you are seeking ways to keep up, then welcome!

What’s the secret of being relevant?

I have started a Twitter conversation asking the same question. No one method is the same. What works for you will not work for another. Individual experience, priorities and interests is playing a big part.

I have received some fantastic responses, which you may find helpful.

I totally agree. No one can force you to learn unless you really want to do it so. If you really want to do it, then you will find the time that you don’t have. Balancing the work and learning will come naturally. And also, not many people think we learn at work but we do.

 

I can relate to Anna’s response. I share me between being a mom, work as well as a house wife. I am fulfilling the expectations of a being those roles as best as I can as many woman out there. Finding time to read a blog is sometimes is hard. However I am sure finding a “me” time is not that hard if that’s your priority. I know many people read on the train, listen to podcasts while they run or while you are working out in a gym, read blogs while you are waiting for a meeting to start, using lunch hour to keep themselves updated, join webinars or go to meetups. There are wide variety of options and possibilities. It’s up to you to find out what is best for you and your commitments.

 

Thanks Bill. Above is great advice. I know sometimes I can go in to a rabbit hole when I want to learn about something and get lost on it. Or I get really overwhelmed by the amount of resources I have to refer or by the amount of new things that is out there for me to learn. I am sure there are people out there who can relate to this. I really have to start practising above. May be I can share my experience on a later post.

Sometimes I am in a dilemma on what to learn – especially with technology that is out there. Some technologies I have to learn to proceed with work vs the technologies out there that I am interested. Investing work time on work related and invest personal time for the things I like to learn? But that is not always practical isn’t it? At work, I have weeks that nothing but meetings. Sometimes I block my diary to get some time reserved for me but that is not working with all the priorities, broken builds and “we really need your input on this”. I always struggle with investing my time to learn technologies. Sometimes I take my laptop out after my kid go to sleep and we have dinner to do some experiments. I know it doesn’t work for everyone but it’s an option.

The above is a fine way to conclude this. The passion should come from you, your priorities. You always can make it interesting as Neil mentioned.

You may feel that your manager has the responsibility to sort out your learning. It’s like you wait your manager to sort out your career as well.  I have heard people telling their managers “you didn’t help me learn or help me develop”. Every story have two sides yes but if you want to learn something, why you have to wait until your manager sort that out for you?

It all depends on what you want to do? Do you want to build yourself, be relevant and be the drive for your career and knowledge? Then I think the above conversation may help you.

I really do!


The complete thread : https://twitter.com/bhagyagdm/status/873416019712323584

Advertisements

The need for testing strategy document

In a recent meeting one of my colleagues asked me why we don’t have a test strategy document. I asked why we need one but I didn’t get a straight forward answer.

I personally do not like to have these kind of documents. I am sure these documents may help in other teams / companies but for the last 14 years these documents were more of a burden than a help or guidance.

First of all, what is a Test Strategy? It is basically defining how we are going to test the application. What sections does it contain? In high level,

  • Document review and approval process or people
  • Scope
  • Test approach or different levels of testing and by whom
  • Environments the application will be tested
  • Tools be used
  • Release process
  • Risks
  • Other process like defect management, etc

Almost all the test strategy documents that I have seen in my previous experiences and the templates online shows a section for definitions of each test type and who own each section. For example, Unit tests by Developers, Feature tests by Developers, Acceptance test by Testers, Performance test by Developers etc along with what is a unit test, what is a feature test etc.

Some can say, this is assigning responsibility. For me it’s encouraging a division in responsibilities. A division between development and testing teams. Becomes a waterfall method and push the responsibilities over the wall. You may disagree with me here. However, my thoughts and my behaviours are a reflection of my own experience.

As modern teams, we expect development and testing functionalities to be working together. Pair when possible. Open discussions and collaboration on how the product quality will be assessed. There for I do not want to introduce these definition documents and encourage the division of responsibilities. Sometimes people find comfort on these definitions and role association. This can be harmful if you are expecting the teams to be working together.

If you are working in a free thinking, dynamic team who know that they should be flexible around definitions and roles and responsibilities, then you can have a test strategy as a guide document. But if your teams are not there yet, there can be confusions of who do what and when and these type of documents can limit their thinking. If not having these type of documents will help the team to be independent and flexible, then definitely that’s where I would go for.

Sometimes teams can get hung with the document and as well as quote the document out of context. For example, in your test strategy document you have defined that test environment should not have live data. If there is a situation, that you have to have live data in on lower environment, someone can say, it is defined in the document and we can’t so we can’t. Deal with the issue in a different way. The different way can cost time and money and the data that is coming from live have no sensitive data. But yet because the document say so, it is not possible.

You may think this is an extreme scenario. It is actually not. I have experienced this in several occasions. As agile teams we are fast paced teams. Sometimes we have to be creative in dealing situations and the whole team should come together. The document can isolate test teams and let the rest of the team go “It’s not our responsibility. We have done what we are asked for”. I have being there, many times. What we say is no finger point but the first question anyone will ask is, how come this slipped testing? Not, how come we missed this as a team? May that question should be documented in the Test Strategy?

If you have test strategy documents, how frequently are you keeping them updated? Or have you created them so generic so the document is valid for all purposes? Once we had a 60+ pages power point document that no one in the team read, or used. But it ticked a box. The management wanted a test strategy and there is a test strategy. Nothing beyond that point.

The document sometime can limit the communication and creativity of the team. Instead of have ad-hoc discussion about how we test something, teams can refer the document and make their own assumptions and interpretations. This also can discourage people to try different tools and techniques. I had being questioned trying out a new tool just because it is not mentioned in the test strategy document. When I update the document, it had to go through the long list of approval process which I had gave up trying the tool.

Does no test strategy document mean, the team doesn’t have a strategy? Team doesn’t know what to test, how to test, what tools to be used and what environments to be used?

I think testing strategy restricts teams and their capabilities. It can depend on what type of a project / product you are working for. If you are working in a critical application you may need one to define all the complexities. Others should learn to collaborate. What’s the word? Be agile about it…

So who should have a test strategy document?

  1. Teams that are new to Agile practices
  2. Teams who have less experiences team members who need guidance over best practices and process
  3. Teams that works in different geographical locations

Above mentioned situations do need a strategy to guide the team and make sure the team is evolving / practicing a defined process. However, these documents should be used for short time until the teams understands the process and value. Then it should be open for discussion and changing according to the team / project / product needs.

My final thoughts to summarise above is,

Testing strategy is Testers should collaborate with Business Analysts on requirements gathering, estimations and story writing. Then collaborate with developers on pair automation while executing their exploratory testing skills. Occasionally use a written document or guideline to support the teams who need direction but later encourage them to start discussions and create team level work methods.

So what about the test plan? I have listed my thoughts about detailed test plans in here.

Glad the interviews are done

Why do we conduct interviews? Why we not hire people just by looking at their CV? Because you need that personal interaction before the decision has made.

Recently I went through the process of interviews. It was the time to finding a new team member. Yes, I have done interviews before but this time I have documented my experience.

The interview process I followed was,

  • Initial screening of the CV
  • Phone interview
  • If the phone interview was successful or I am in doubt over how the phone interview progressed, I called them for a face-to-face interview
  • On the face to face, I have spent a half an hour discussion with the candidate alongside another two of my colleagues who represent development and business analysis. This gave me an idea how the candidate will work with the team.
  • Then I asked them to test a section of our application with me as a pair testing activity. Talked about what they would do, asked questions and explored the application. It was an excellent opportunity for me to understand their testing skills.
  • There was another task on whiteboard to write the high-level plan or code to automate a simple section from the application. This was their opportunity to show their knowledge and understanding on automation.
  • Take an IQ test as a part of the company requirement.

So yes. The whole process was time consuming. However, it helped me to know the candidates better.

I had a clear goal from the beginning. I was looking for a candidate who is passionate and excited about testing. Someone who is open to learn. A fit for the team as a whole not just testing function. Good communication. Automation experience was just cherry on the cake. I always believe that automation is not testing but a tool to help testing. Therefore, I had no plans to be strict on the automation experience.

I interviewed almost twenty people via phone and face to face.  Some of the unforgettable characteristics were,

  • Attitude

Some given us the impression that they really did not want to be in the interview. They spoke over us when we wanted to clarify things, did not wait the question was completed, no smile and not joined the friendly chitchat before the interview. It might be the nervousness but it did not come out well.

  • CV is not represent the exact skills and experiences

When there were automation knowledge in the CV, I always asked a question or two. Of course, I have asked the most basic question to start with and if they show potential, I asked bit more. For my surprise, candidates with impressive automation skills on CV, struggled to answer and said they had never worked on such. So why the experience was in the CV? To get through the selection process?

  •  Question time not used effectively.

Question time shows the interviewee their personality. Candidates can ask about the role, about the team, career progression etc. Not everyone showed this enthusiasm or make use of the opportunity.

  • Demands

Apply the job via the advert and when the internal recruiter call the candidate to arrange a phone interview, they ask for a higher salary than what defined. The job advert clearly mentioned the salary range. I always say no to such candidates because I feel what they do is not professional.

The main characteristic I saw in most candidates were, they are not thinking outside the test script. As for them, the business analyst should write the acceptance criteria and the testing team follow it to the point alongside other scripts. My question to everyone was “what if there is no requirement or documentation. How would you test? What would be your approach?” About three people said they would do exploratory testing. Rest said, no there should be some documentation to learn about the application. When I ask them what their understanding over Exploratory testing, their definition was close to ad-hoc testing than what Elizabath Hendrickson had explained in “Explore it”.

Why does this happen? Is it because companies not invest on people as much as they should? Is it because people not invest on themselves? Of course, these candidates will find another job. Companies who want scripts followers will hire them. I felt sad for them because they are missing so much that happening in the industry. In the UK, we have a fantastic testing community. Why are they not taking the advantage of it? Lack of knowledge or lack of enthusiasm?

The interviews helped me to see through the candidates and gave me an idea of their managers. I think managers have a bigger role to play in helping their teams than just get the work done. We work with different cultures and diversity levels. No one rule applies to all. I have met few managers who genuinely interest in helping their teams to grow within the team/ company and in the outside world as well.

In my mind, it is unfair to limit people’s potential because managers think they will leave otherwise. Well, people will leave anyway. However, I think I will be a very satisfied manager if I know that I truly helped the person who is leaving than hold them back.

Lego automation workshop by Richard Bradshaw

This year, I had the opportunity to attend Lego automation workshop at Test Bash hosted by Ministry of Testing. The workshop has been running for 2 years and I have heard many positive comments about it. Obviously, I had many questions  How can someone learn about automation with Lego? Are they using Lego mechanics? I have only seen Lego Duplo on tweets, they are just big blocks; can they be used for automation? How automation and Lego will joined up together?

 

The workshop was about automation theories. We had to pair up, one became the robot/program, and the other became the programmer. There were five challenges, which had their own learnings. I paired with Yuki (@k_k710). We were given different images of shapes to build, and the programmer had to write instructions so the robot/program could build it. It sounded simple. However, it had its own complexity. Language had to be simple, should be understood by the program, assumptions needed to be set, etc.  Then the robots had their opportunity to run the program. Pick Lego from different locations, bring them back to the table, and fix them as of the instructions and compare with the original picture. Robots were robots. They could not think. Therefore, the robots bumped in to other robots. Different sizes and colours made them confused. How to fix, how to compare. Long instructions got them confused. Things got complex when we swapped the scripts with other teams. Some found that the instructions were difficult to understand because they were very technical, or assumptions were not clear. Whether raised concerns were issues or not. Next, we were given more complex images, we had to then refactor the instructions build the new shapes. On top of everything, we had to keep the instructions simple so the mindless robot can execute them. What we had to remember was that robots could only see what we told them to see. They could not decide anything by themselves and could not see anything that we did not ask them to look at. Lesson learnt. Thank you Yuki for being such a great robot!

 

Did I enjoy being part of the workshop? Yes. Was it instructive? Yes. Was it memorable? Yes. Was it entertaining? Yes. I believe these are the characters of a successful workshop.

 

So what did I learn? What made me think? Reminders that I needed?

  • Fine details on a script will make a difference
  • Give the robot the ability to voice what’s happening – logs / messages
  • Define how detailed each test should be. More detailed, complex they become.
  • Experience in writing code makes a difference
  • KISS – Keep It Simple Stupid
    • Start tests simple
    • Improve later
  • Complexity emerges but
    • We are learning while we code, and we explore
  • Who do you want to be?
    • A programmer; thinking about design and code, or a
    • A coder; who just writes code
  • What do you want to do?
    • Check – Does it do what exactly you asked it to do?
    • Test – Think logically and be critical
  • Give people the space to figure things out. Let them learn than instruct
  • Make sure your code is understandable by others
  • Get away from the IKEA effect
    • I built it, so it is fantastic!
  • Utilise the code and improve re-use

 

Richard summarised the workshop with following image. He gave many examples from his experience for each point. He mapped the points to what we experienced that day.

 

I agree with the points he raised. One thing I realised was that I knew these things. I had experienced these things as well. I also knew I should adhere to these things. However, do I practice them? Do I know why I should practice them? Do I understand the consequences?

 

The workshop was targeted for everyone. Anyone who wants to understand the complexity of automation were welcome. I saw a clash between the novice and experience. Yes, we can learn from each other and see different point view. However, this can make some participants get a bit isolated or drift away. May be this workshop could be promoted for beginners and then extended it to experienced audiences. This might help each audience to focus on what they wanted to learn than try to find things to learn and enjoy the workshop at the same time.

Well, that is just from my point of view.

Why you should go to the workshop? It gives you a different perspective. You will learn about the basic automation concepts, use different programming languages to reach your testing goals, using different methodologies and best practices. You can attend the workshop to get a good understanding of them by simple exercises. Learn and share! I highly recommend this workshop; I hope you will enjoy it as I did.

How I broke free from script testing

I became a tester without any training. I was doing testing as part of “Making sure what we deploy to live is working” as a sub section of my day, job and I loved it. I decided that subsection should be my job and I applied to become a tester without ticking most of the boxes in the job description.

At that time testing as a job was not popular in my country. So naturally, I used the online guidelines. They were talking about documented test plan before the development, doing testing development phase, make sure test scripts created and followed as it is.

My main task was to create test scripts in my first job as a tester. I felt bored as all I did was going through a web site and write test scripts. When I found issues, they went to a backlog where they will looked at later. No date given. Nevertheless, they were live issues. Some issues can cause customers not fulfil their journey. I suggested that we should start testing with what we have developed than waiting for the last minute. My thoughts are very unpopular because the tech lead/team manager did not like me coming up with new ways of working also not adhere to the process they are committed. They also commented on my lack of experience as a tester. I left the place in 3 months, as I was not enjoying my work.

I started questioning my decision on changing to a tester. I felt lost. In my next job, I started asking questions from a developer mind-set. Fortunately, there were right questions to ask and that helped the team to think. I created test scripts and shared with the developers but kept some scenarios for myself. I guess I wanted those failed scenarios. I wanted to make sure I clear myself as a person who finds the cleverest issues. Be the cleaver one. It paid off. While a new section develop, I just wondered in the application. Came up with situations that are clearly not behave as wanted or a missing requirement.  Not everyone impressed as my issues was delaying the project. However, I was so satisfied with my job. Company closed due to financial troubles and I was on job-hunting again.

Meanwhile I did ISEB beginners course. It helped me to understand some concepts and open few doors to experiment.

Next job required script writing as well. Nevertheless, I slowly moved away from it as the script writing and updating them so much of my time. Slowly I negotiated with the PM and used the scripts as a guideline. As a basic test to provide some documentation that, he needed. One thing I realised is some testers in the team did not know the application well enough to explain it to someone else. They used to follow the scripts and they did not know anything outside the scripts. I did not like the fact. I wanted to wonder around the application and learn about it. How it works and affect with different inputs. I learned so much about the application and found issues in the same time. I was able to explain the application and discuss the functionality with others without a problem.

I practiced the same in my all other jobs after that. People were not happy about it first but I gave them results. Therefore, I was able to walk away from scripts slowly. When there is UAT I had to create scripts as we wanted the people who do the testing to follow exact steps. No room for users to wonder around and find issues. My objection to this dismissed in all projects that needed a UAT.

In current job, when I first started I needed to write teat scenarios for each story. Of course, I did not like it but did not raise my concerns as I was more adjust to the country, people and their practices. Later with my confidence grow I stood up to my beliefs. Wrote a line or two of what I test to make sure I remember what I have covered. I have commented on this several times but I did not change as my manager wanted. She was a project manager and not have any experience on testing. She made sure she read about testing online and make sure I followed the same. However, she slowly gave up following me up with what she read and I got things my way.

Later I read that what I was doing was a flavour of Exploratory testing and I was right to get away from scripts and scenarios. I read the reasons behind the decisions. Nevertheless, I know I am still not doing the Exploratory testing on the right way. Which I am trying.

Lesson learnt was to follow your heart, show results and slowly break away from things that take away your time for documentation and reporting.

Think differently when working with distributed teams

Distributed teams. We all working with distributed teams. Whether it’s in different countries, different cities in the same country, different floors in the same building, and different teams in the same floor or working from home. All count as distributed.

What issues do we face? There is a lot! However, when we start to discuss the issues, we always see the negatives and we talk about issues caused by the other side.

What we can do to correct this? We go hands on the air and say they should do this and that. Yet, we never think what might they think? What we can do to help? What behavioural, thinking and communication changes we can adopt?

These discussed in a Testbash workshop where Steve (@sjwatsonuk) and I attended. We recreated the workshop in our company as a pilot. Due to its success, we did it again to a different set of people and it got all positive feedback. Positive feedback for the workshop is brilliant. How positive the people feel at the end of the workshop matters. However, how much they practice the learnings is a question. Which we hardly get any feedback.

I am fortunate that most of my team was in the pilot program. From the next day onwards, they started to discuss how they could do things different. Now they are thinking differently. Take actions to include the nearshore team more in team discussions. They see why this is important. The nearshore team ran few retrospectives from their end and as well as conducted few stand-up sessions. Progress…

I believe if we think open-mindedly, we can collaborate successfully. Distributed teams created to deliver more work with a high quality while maintaining the costs or reduce cost. Everyone is part of  the project success. Build trust not pointing fingers, build communication openness on both sides so no one feel left out, build environments where everyone can ask questions and give answers to make the product better. Give constructive feedback and encourage it to come from every team member disregarding the location. Learn about their culture and try to help them to connect with you. Specially, praise each other when do well.

Have you ever worked from home? Was it easy to connect with your team virtually even you know them? Can you find people when you need an answer? Have you deliberately picked up work that you can do without the need of anyone else when you planning to work from home? If you are getting frustrated with your team when you work from home for one day, how your other teams might feel when they have to go through it everyday?

I am working with Abby (@a_bangser) who is one of the original presenters of the workshop, to deliver the same workshop in Helsinki for European Testing Conference. An exciting opportunity to help more people build empathy towards each other.

Remember, we all distributed to each other and small change of thinking can make a big difference.

Sometimes its good to ignore the rules 

Yes. Sometimes it is okay to ignore rules, think from a different point of view. This may cause you issues and criticism and temporary failures but as long as you have a plan, it should be all right.

This is my journey on implementing a regression test suite in current project, how I solved different hurdles. I have broken many rules but now I believe it is a success.

When I join, the project there was acceptance tests embedded to the code. So as the unit tests, feature tests and integration tests. Those acceptance tests not cover user journey but more of a single function. All different tests are based on one code base. Acceptance tests were running in TeamCity as well.

I spoke to the team and then start adding tests to the acceptance tests because I felt it is not enough. However, it was making the code build too slow and maintenance get out of control. Why? It was one code base. When acceptance tests fail, the tests were either ignored or made to pass. Tracking them was difficult.

Therefore, it was a failure. I was discouraged and almost given up!

Then I asked the team how they feel about me creating a separate test suite. Seniors objected because it will make a duplicate code, unnecessary maintenance etc. I felt disappointed and discouraged again. I maintained an Excel sheet as a check list for different functionalities but wasn’t happy. Testing had become a long process when it come to build pick and deployments.

Few months later, I started creating the test suite without telling anyone. I copied some of the functions from the main code base that I can use and build up on it. It came out as exactly I planned. I started using it for checking the releases. So far, all happening in my local machine. Then I showed it to the team saying this is what I have done. I even used the test suite against live environments, which had not happened before.

Only few impressed. Same arguments came. I mentioned this is only maintained by me so it should not be any overhead to rest of the team. It will be in the common repository but I do not want the development team to update it because I would like to have a control of what goes in and out!  Did they agree? No. They were telling about what happen if they change the modules that I have copied. My tests are independent from their code base. I just ignored all their concerns for their displease.

Some helped me setup the build in TeamCity and the team started to see results. Build picking and deployment times reduced. Issues caught up front in areas that was not thought of… Stage 1 succeeded.

I wanted to discuss the tests and its coverage with the business but the tests are very technical. Therefore, I wanted to do BDD format. However, all the documents I read and all the courses/workshops I went to told that BDD is a way of communication and it should start from the business and the teams talking to each other. I agree yes.

However, our team was doing most of these things. We are having open discussions with the Product owner. The business analysts are writing the stories in a Given, Then, When fashion .Doing changes from top to bottom will be troublesome. Many people do not want to change how they work unless there is a perfect valid reason.

Therefore, with a help of a contract tester we changed the existing test suite to use SpecFlow. Introduced BDD to the Regression tests and converted all tests. Detailed SpecFlow reporting and tests running in multi-thread mode the reduce overall time impressed the team. They now backing us with having a separate test suit.

When mobile tests needs to be done, it was easy for us. We expanded the tests to different devices to different break points with ease.

Then I showed the test suite to the product owner. Taken him through few scenarios.He was clearly impressed on what we have achieved. Now I am working with some editors to understand what scenarios I might be missing from their point of view. Involving the business with testing was great.

Now I am working with the business analysts to see how we can work together with the BDD scenarios. Whether I need to change the language that I used in the feature files or they need to change theirs or whether we can meet half way. We are going to try it on a small functionality change so there will not be less impact.

There is long way to go but I am happy the way I have made an impact without playing by the common rules.

Therefore, I think it is good to break rules now and then. Well it worked for me so far.

London Tester Gathering Workshops ’16

I had a chance to join by LTGW in June 2016. I took my time in writing this blog because I wanted to see what I would remember after sometime. I normally blog as soon as I come out from a conference but this time I thought to wait and see.

LTGW is different to other conferences because it is only contain workshops. Many interesting workshops. Personally I had went through the list of workshops several times, made my mind, changed it, went through again, changed it to original and changed again. That probably explain how interesting the list of workshops were.

Tony’s (@tonybruce77) power of asking questions workshop was a highlight. Asking questions is easy but asking the right question is difficult. One of key point I remember is that we should ask questions not only for self-benefit but for the benefit of others as well.

Yes true. Many times, I have asked questions where they benefit me but sometimes I have asked questions to make sure the person who explains the situation had thought about them too. Many occasions I have seen people build up conversations based on the question I have asked. I have not thought that the conversations that build, ideas that triggered and areas that discovered are results of a simple question. Sometime your question can be the answer. It is always better to ask the question than being scared of it.

Then I went to another session on Mentoring by Tony and Dan (@DanAshby04). We had discussed about what is Mentoring, Coaching, Teaching and Leadership. In a summary,

Mentoring is about to grow others skills, Listening to others and share experience, provide continuous help on need basis, guiding, encouraging and help

Coaching is about transfer of skills, problem driven, not on going, maximise skills, and have an end goal

Teaching is a structured program, delivered one direction, share Information, inspire, and evolve

Leadership is about being responsible, Delegation, Representation, Accountable, Inspire, Motivate and Organise.

It was nice to see the difference of each sections as sometimes mentoring and coaching described in the same manner.

Both above workshops filled with interesting videos and fun exercises.

I was in two other sessions thinking I should have gone to a different workshop one workshop was too basic for me and the other one did not make any impact on me.

Other than that, it was a great.  Thanks Tony for the free ticket! It was an amazing experience.

LeanCoffee style online meetup : Experience report

My first LeanCofee experience was with TestBash in 2015. It was before the conference start and I was very excited about the concept because it gives everyone a voice.

I wanted to introduce this to my company but was not able to do it for a while because I was looking for ways to do it online as most teams we have are distributed.

Leancoffeetable tool was introduced to me by the weekend testing group. It is not the most advance tool but it does the job. I trailed it by myself several times before introducing it to wider group.

We have a QA chapter in the company and I wanted to introduce LeanCoffee to them just because only few people raise their ideas. The rest are not actively participate because either they are not interested or they do not know how to contribute. However, I believe everyone have their unique experience which worth sharing.

The introduction went well and people wanted to try it out. So we dedicated a one QA chapter session for LeanCofee.

First, we thought we will do the leancoffee with four small groups and then feedback to the chapter but we had issues with number of people who wanted to join the chapter itself. So finally a one big LeanCofee session online, facilitated by me.

We got participants from differently businesses across company and from different geographical locations. In a normal day in the chapter, someone will do a demo or a presentation about a new tool or practice so this time it was time to share. We heard voices we have not heard before. Current issues the testers face in their own projects and want to know how others will react. What to do? Seeking information that we thought everyone is aware but not.

Meanwhile the discussions I have created a mind map for each point as well. This shared later as the meeting notes / summary.

Topics discussed,

  • Can developers help with testing in scrum?
  • How to get developers to do more unit testing?
  • How to plan testing when there is no documentation?
  • How to encourage testing community to engage more in RBI?
  • What value QA chapter add?

1.5hrs passed quickly. There were number of issues we have not addressed due to timing constraints. Nevertheless, we achieved a lot.

Feedback was fantastic. For me, it was a great experience. People share their ideas and experience to others who need help is what a chapter should be. That is what we achieved.

Most of all they want to do the chapter in a LeanCofee style from now and that I call as success…!

Recreate Building Quality in With Distributed Teams

After attending an exciting and educational workshop in Brighton (read more), Steve (@sjwatsonuk) and I decided that, we should recreate the workshop for our colleagues in Reed Business. I am very grateful to Lisa (@lisacrispin) and Abby (@a_bangser) who not only helped us with sharing all materials but with plenty of encouragement as well.

Since we are a big organisation with many different projects, we thought to stick to the projects that we are in as the pilot. We also included members from a team who deals with internal clients as well. The presentation tweaked but the rest of the workshop was as it was originally.

The teams were well mixed up and distributed over different floors (we were not able to book the rooms in the same floor). We took the liberty to mix and match people and that they work with majority of people that they do not know than the number of people they know.

We got two excellent and exciting helpers as well. Saima Poorghobad and Michael Lopez (@lopezma) was continue to support us by showing thing that we have not noticed. Fantastic!

All started well on the workshop. Steve and I had a plan but not rehearsed a thing. Therefore, we thought we would improvise as things go. We got people to talk. They came up with the issues that they face with working with distributed teams. Everyone was facing the same issues such as communication, culture, language etc. The examples we gave related to each business. We also mentioned the internal teams that support different projects that have a different level of distributed team challenge, which normally overlooked.

Then two teams sent away to different rooms with their tools. Straight away communication issues bubbled up. Lync was not working properly. Sound quality not there, video not working.

In the team I looked after as the Product Owner (PO), rushed to get in to work without even looking at the schedule. They wanted to get things done. Therefore, the inception and planning sessions were almost wasted. Many assumptions made. They did not ask me the right questions in the beginning until I clearly said I am not happy with the work they done. Offshore was asking what my favourite colour was than asking the right questions. Then they all started asking what my requirement is for each individual piece of work than one person dedicated for that – because of not planning the session and not assigning roles. Offshore team tried to gather the requirement with the work that they assigned but it was harder. Therefore, Lots of frustration! Time pressure! People running up and down! It was chaos!

In the retroactive it was highlighted that product owner did not have any bandwidth to answer all questions. I hinted saying I would be happy if one person talk to me than all. It was fascinating how teams forget the basic roles under pressure.

Another thing I observed was that the offshore team were trying their best to get the attention from the onsite team but they all busy either talking to me or colouring away. The offshore contact had to talk very loud several times and to shout to get the attention. Also later, I have to know that they were there with less or no work for most of the second sprint.

Everyone came back together and discussed the issues that each team faced. Offshore teams were frustrated and was very vocal about the whole thing. Then we decided to give additional 5 minutes to the teams to decide how they want to do the next sprint from the challenges they have/had. That was something Steve and I came up at the time so the people can learn the importance of planning and communication.

There were team members who wanted to talk to me and gather requirements while the planning, share information and retrospective sessions. This shows how people want to get on with their work than making sure they work as a team and achieve a common objective. Alternatively, let the others do the communication while these individuals busy with the ball rolling. Either way it was not helping the team.

The third sprint was a success. Steve and I took 2 minutes holiday and done a change of mind on a requirement. Teams did not seems to mind it at all. The requirements gathered for most of the work so they were caring out the work. How great is that!

Later we talked about the culture differences a bit more. I talked with my personal experience. As I speak about how other side of the table might be thinking I saw some eyebrow raises, nodes, note taking, and look of surprise. I might have invoked some thinking and awareness.

At the end, there was real light bulb moments in most people on how to do things differently. We asked what they would do differently and things like make sure communication issues (technical, non-technical) resolve sooner than later, involve product owner with offshore discussions, gather / clarify requirements early, make sure the offshore see the bigger picture and be more understanding are some of the things came out.

Well, all workshops we have people who think it is a waste of time, as they know the subject better. We had couple of them and they had given us negative feedback. One response was that, that person already knew these challenges and nothing new. Well in my point of view, everyone knows the issues but how they react to solve the problems is the key.

Two negative feedback against 21 from 23 participants. I take that as success!

 

Next, we have to collate the feedback and present to a wider group and who knows we might be able to take another group of people the same journey and help them to build quality with their distributed teams…

We learned a lot how this could improve. Such as dedicate someone else to coordinate the timing, bit more descriptive in the inception, bit more organised with the rules and do some adjustments to the schedule.

You still reading? Great… Few more lines…

Finally would like to thank Steve for encouraging me to do this workshop and made me believe that I can talk in front of many people without making myself a fool. Great co-host to work with. In addition, Saima and Michael was so helpful and given us fantastic feedback. Could not ask for more enthusiastic helpers than them. We were very lucky.

In summary, it was a great experience for us and as for the participants. Looking forward to recreate the workshop and of course looking forward to learn more.

If you like to read Steve’s experience you can find it here.