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:

1. The key problem in my opinion is confusing Testing with Quality
2. Putting most of the efforts to achieve/improve/assess quality focusing only on the product
3. Caring about quality way later in the process. 
4. Reactive strategy i.e. to address quality concerns and risks after they are found in a product (which is too late and costly to fix usually)
5. Over emphasise and reliance mostly on automated checks that do not discover hidden risks or find new information. These checks only assert the known information. 

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. 

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?

The Lead Time graph for our team 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) reflected the positive impact.

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. ​

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 :

• Supporting changes by cross-functional teams
• Supporting changes/recommendations by architects or infra team
• Technical Debts
• Unplanned bug fixes
• Unplanned Functional/Technical investigations
• Discussions with other teams to solve certain problems or derive solutions

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:
​

• The first one being your estimates are likely to be better if not accurate, for the fact that they would be based on actual time spent on different sort of sessions (that also involve complexity). This is in contrast to popular methods where estimations are generally made based on feelings, rough ideas and perceived complexities.
• Since your estimations are done in the form of "number of sessions" (and not Story-points or T-shirt sizes), finding out approximate time to be taken is relatively easy and reliable as compared to standards methods of estimation where we don't necessarily estimate in time required and the relationship of that measure with time is hard to establish (rather not recommended).
• The idea of classifying the work in different types of sessions would force us to consider those types while planning the sprint itself instead of realising and considering them at latter stage and re-estimating the efforts.
• Focused, time-boxed and uninterrupted programming sessions can certainly boost productivity
• When otherwise overlooked things are measured, recorded and taken into consideration then Retrospective meetings in particular can be more productive and Team Leads or POs might get deeper insights into what action needs to be taken to overcome those short-lived but repetitive impediments.
  
  

I'm a tester but what makes me so concerned about programmers?

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.]