Quality – is a team goal.

Quality.

Its an interesting word to try and define, but that is not the point of the post, so I am going to clarify in what terms I am using it. In providing software for someone to use, quality means that the application or program does what the user wants it to do, is as free from defects as it can realistically be, is usable, does not cause the user to get cross or frustrated but to satisfy their needs. I’m aware people will disagree, so i may take this up as a separate post!

In software delivery teams, Quality is often alluded to as meaning ‘there’s no bugs in the code and the acceptance criteria in the user story (I am using Agile as an example here) have been met’. It is also very often left as the Tester’s job in the team to ensure that Quality has been met.

I have a huge problem with this. Quality cannot be tested in, so what is the point in leaving the tester to find out if something doesn’t work as it should. Is that not the same as leaving the stable door open and then asking the tester to see if the horse in is there, and the raise the alarm if it has gone missing?

The most sensible things is to make product Quality a TEAM goal. Quality is everyone’s responsibility:

  • The Product Manager working with the team to promote quality in every task.
  • The Business Analyst in writing the user story must work with business stakeholder to question anything that would appear to make the user journey more complex than it need be, highlighting improvements in the proposals.
  • The Business Analyst in walking through the story with Developer and Tester to explain what is requires, and answer any questions, so there is a common understanding (the 3 amigos discussion).
  • Developers must write good code, fully unit tested and integration tested before performing a demo to the tester.
  • The Tester must exercise tests to cover the delivered code, to regression test, to perform exploratory testing around the story – are there any potential pitfalls or problem areas, and to execute performance and security tests.
  • The Team then perform a demo to the end user/stakeholder, and there should be no surprises. The delivered software meets their requirements, is robust and does not break!

It is basic common sense to not expect the very last person to look at the software to be the only person responsible for the quality of what has been delivered, unless the team likes to spend time rewriting code, missing deadlines and seeing a high turnover of bored and frustrated testers!

So, if you are reading this and am one of those testers who are expected to ‘do quality’ yourself, take heart. Things are changing, expectations are changing, and if your organisation will not accept the inevitable, then you have 3 choices: 1) Stay, and moan, 2) Give up and leave, 3) Stay and educate the team. Find a developer and BA who share your opinions on Quality. Work with them and use the success to show the rest of the team how much better and quicker the turnover was without rewriting and rushing to meet the deadline. Offer to work with the more reluctant team members, point out the issues that you would term as ‘quality’ issues, and they will start to understand and learn from you.

If you are reading this as a PM, BA or developer, please do not leave the tester in your team to bear the overall responsibility. Remember that in football, if the goalie lets in a goal, its a team failure – midfield and defence failed to do their jobs and left the goalie to do all the work!

Advertisements

Dress code

I’m switching to interview mode again for a couple of posts, as it is something I have been doing recently.

Today’s subject is around dress code. Should you dress formally for an interview or not?

My view is an unequivocal ‘Yes’. We may have changed so that wearing jeans and t-shirts are acceptable for IT workers who do not generally need to see customers, and there’s nothing wrong with that, but there are certain standards that should be upheld. When someone comes to an interview smartly dressed (blouse, skirt/trousers and jacket for a lady and shirt, tie & suit for a gent), then it creates a good first impression. They have taken the time to think about their appearance, and how they look. and have shown me the courtesy of dressing for a formal meeting. Interviews are not generally an informal chat (I know some can be), so should be approached formally.

Two people are meeting for the first time – they may have spoken over the phone, but neither know each other. One is interviewing another for a job – so a level of common courtesy is required.

Call me old-fashioned, but it irritates me when someone cannot be bothered to make the effort, and makes me wonder if the actually want the job they have come to be interviewed for.

Of course you can have a smartly dressed candidate who cannot do the job, and a casually dressed candidate who can do the job – but I would not want either. If that person needed to visit or meet a client, or present an important project report to very senior management, how do I know that they would dress appropriately? I could ask, but of course they would reply that they would dress formally when needed, which would lead me to ask why they were not properly addressed for an interview then!

There is one exception, and that is where they have requested beforehand not to wear a tie or suit jacket. I understand that if someone has a half day for an interview, and they are in the office for the rest of the day in a suit, people may guess they have an interview, which is not ideal, but an advance request is a must.

Common courtesy can be very undervalued – but not by me!

When Agile isn’t agile

Ok, this is a bit random, but it is something that has been on my mind for a while, and as the blog is about my musings, I felt it was time to share it.

The point of being Agile in a development team is to be able to be flexible – hence the name. But there is an irony here where Agile teams are not ‘agile’ if you follow the best practices for Agile teams.

I’ll give you an example – you have a 2 week sprint, the user stories are all written, confirmations added, stories sized etc etc. So you start off the work, and 3 days into the sprint, the business owner comes over and tells you that there is a game changer – either a competitor has done something that your company has to react to, or there has been a budget and the VAT rate has changed, or something similar that means that the team need to be ‘agile’ and respond to. The problem is that by following Agile, you are locked into that 2 week sprint, and the response back is that you’ll do it in the next sprint, which starts in 1 1/2 weeks and delivers 2 weeks after that, so there is a 3 1/2 week delay until your business can respond to whatever event it was that came about.

There is the option to cancel the sprint and start again, but that is disruptive, so the point here is that there is no agility built into the  process to be able to respond.

You can follow Kanban, which I believe can work well when a team is in a ‘maintenance’ mode, as stories that have not been started can be left on hold and others swapped in, however I think a team following Kanban needs a certain level of maturity – but that is for another post!

I’d like to know what your views are on this – do you disrupt a sprint or do you make the business owner wait until the next sprint?