How to build AWESOME Teams - Part 1

Attitude towards Quality
I love exploring and observing team dynamics. There are a lot of knowns and unknowns that affect it. Individual personalities, their roles, who sits next to who, how you communicate, office space, tools, technologies, company culture, processes and many more. All of it have an impact at different levels for different teams. There are no silver bullets, no best practises, no certifications that can guarantee an awesome team.


I guess I am one of the lucky few to have worked with not just one but many awesome teams. To me awesome teams are those who - do whatever it takes to get the task complete, are high in morale, self-organised, trust one another, have a sense of owning the product, display a bit of we-are-awesome and more importantly have loads of fun.


At my last client site I consciously observed and noted what traits in us set us different to others and one thing that stood out from rest of the teams in the company was our "attitude towards quality" of the product.


We as a team cared about quality all the time, backlog refinement with PO's, story kick-offs, during dev, pairing when we tested, we constantly kept an eye on crashlytics, logs, support beta channels, what interest groups say, etc


We hated defect tracking tools because it hid bugs, we made the bugs visible on our wall, we would never let the bug count grow more than 5, every bug we find in any stage would be discussed and appropriate action was taken rather than parking it to visit later.


Our testing strategy and attention to quality soon started paying dividends, PO's, users, analysts, and others in the company started noticing it. This also, set us apart from the rest. We were a proud bunch, we were keen to demo our features, any chance of pushing the build to production we would do it, we constantly pushed ourselves to get better.
So in case if you want your team to be awesome give this a try.


Encourage good quality. I understand quality does not come cheap. There will always be a temptation to deliver a new feature over fixing some bugs. I also, understand if managers reading this feel a bit uneasy about such teams and the investment towards quality. I get it but never tell the team that the quality of their work doesn't have to be awesome.

Without awesomeness you don't get awesome teams.

Comments

Post a Comment

Popular posts from this blog

Exploratory testing, Session based testing, Scripted testing…concertedly

In my last assignment a mix of exploratory, session based and scripted testing helped won an award, appreciation by managers & stake holders at our organization. The quotes from our award certificate “ QA team has come up with some intelligent testing techniques to validate the product. The customer test team was not able to find even a single critical bug after delivery ” Though the award was a small one in terms of the award categories our organization have, it meant a lot to me and the team, because this was the first time the team used exploratory approach. The assignment was not pure exploratory or session based, in fact it was supposed to be scripted, but a mix of all three exploratory, session based and scripted testing helped us learn, enjoy, and meet our mission. The assignment started off with developing test cases. We wrote test cases based on the initial requirement document provided. We did come up with a large number of test cases, of which most were re-written, some ...
Read more

Regression Checks + Regression testing = Regression testing?!

One of the questions I find hard to answer when I use exploratory test techniques in my project is,”How do you run regression tests? How do you prioritise them? Do you automate them? Do you document regression test cases?” And then a bunch of questions follow. Let me define the context. I work closely with developers; we use either Scrum or Kanban - which ever best suits our project, product owner, business. We do not believe in individual metrics, blame games, stringent processes, and heavy documentation. All we care about is to deliver high quality software. This does not mean that there is no process, metrics or documentation. We have them all, but they are there to meet our needs and to help those who will come onboard to support/maintain the software. Regression Checks At the start of a story, testers pair up with developers to develop feature files using SpecFlow. Some call it Acceptance Test Driven Development and others Behaviour Driven Development [I am yet to figure out the d...
Read more

What do you do when you find a bug?

What do you do when you find a bug? Hold on do not answer it right now. Let me first set the context. You are part of an agile team. The developers sit opposite to you. You are testing a feature in a session. You are time bound and have the good habit of capturing notes when you test. When you now find a bug what do you do? Assuming that you have taken enough notes you go on to write a good bug description and may capture a screen shot, video of the bug and continue with your session. At the end of the session do you Open the defect tracking tool (wait for it to load), enter all the fields for a bug, upload necessary evidence and have the tool share the defects with your dev team? Or Open the defect tracking tool (wait for it to load), enter all fields for a bug, upload necessary evidence and then compose an email to the dev team with the bug id’s/descriptions? Or Walk to the developer share your notes; reproduce it if required, work together to identify the problem? I work in ...
Read more