The Sweet Spot

Out of all the years testing... there were these moments where everything aligned perfectly and as a result, my features were implemented, tested and stabilized in record time. These moments I am calling 'the sweet spot'. (Note: made up the term "the sweet spot")

My definition of 'the sweet spot' is:

• when you have the right developer with the right tester, and they are both working on the same feature at the same time.
  

Sounds simple... but in reality it's pretty rare.

People these days are all hyped up about scrum, like its some magical solution to shipping faster. Its so complex (so many rules), that people think it must be the answer... eventually once you follow the path, you will see the light!? Lots of wishful thinking... and its missing the crucial key of what ships high quality products... the the emphasis of 'the sweet spot'. (yahoo one more rule to add!!!:)


What happens when you are in "the sweet spot":

1. Developer checks in code. The Tester and Developer are now in the sweet spot. They are both working extremely close. They go through this intense cycle of fixing and entering bugs as fast as they can. Both are 100% working on the same feature.


2. Developer fixes all bugs found regardless of severity, no punting/postponing/no backlog. They do not work on anything but bugs in the same area that the tester is working in. Developer does not fix other bugs in other area.


3. Tester is focused on testing the same area the developer is working on. They do not postpone testing to do automation or tools or writing test cases etc. They start pounding on it right away. They test from unit to integration and all the different testing themes.


4. Managers - life is easy for the managers. They just need to sit back and watch. This is the most stress free time for a manager. Their one responsibility is to make sure the dev and test keep the sweet spot going by removing external factors that could risk a context switch.


5. If someone asked the developer or the tester what they are doing, while in the sweet spot, both should be able to answer for each other. They are so close, they can finish each others sentences.


6. The Sweet spot should continue until the dev and test consider it done. Where both of them think that it can't get any better. Bug rate has slowed down to just a trickle.


7. Spike in bug count.


8. Time span from bug being entered, to fixed, to verified is very short. (Fast turn around)

Results of "the sweet spot":

1. Any feature that goes through the sweet spot is no longer a risk. You can check it off. Sure there might be minor issues, integration with other features that were implemented later. But its no longer an unknown, 80% or 90% should be working.


2. You can move the dev and tester to a new feature set to work on.


3. Two brain better then one. If you put an average dev with an average tester, and they go through the sweet spot... you WILL get ABOVE average results. Speed and stability will be way higher.

How to help line up everything such that "the sweet spot" can happen:

1. Dev and Test should be physically close together. Ideal is that they can talk to each other with out having to get up from their seats. (not a must, but boy it makes a HUGE difference)


2. Pair up the Dev with a Tester. State that they are a team. All information(meetings,emails) about the feature they are working on, they both included- no filtering.


3. Tell the developer and tester what should happen when the code is checked in.


4. DO NOT time bound the sweet spot. Commit to finishing - while incoming rate is high let them stay in the sweet spot. Reason it's ok not to time bound is because 100% of the tester and developers attention is on the product, it won't drag on because there are no other distractions all external factors are filtered out. AND another reason not to time bound is because if you cut it short, we all know it comes back under a different title...'bake time','integration phase', 'stabilization phase', 'code complete phase'... its that span of a couple of months before ship... where testers are finishing their testing they should have finished earlier but could not because it was time bound.

For the visual people out there... i made a super diagram of how things should go in Paint!!... when things went well for me in the past, its because it has the exact same flow below!