...regression testing is optional. What? The horror!!!
Back in the dark ages, with Scrum, we were spending about 4 days of each iteration regression testing. This product has lots of business logic in the UI, lots of drag-and-drop-type functionality, and very dynamic data, so it has never been a good candidate for automation. Our regression test approach was to throw a bunch of humans at it (see my Group Regression Testing and Chocolate post). With Scrum, each prod deployment was a full build, including about 14 modules, because lots of stuff got touched. Thus, we always did a full regression test, touching all the modules. Even after an exhaustive regression test, we generally had one or two “escapes” (i.e., bugs that escaped into production).
Now, ask me how often regression tests failed? …not very often. And, IMO, that is a lot of waste.
With Kanban, each prod release only touches one small part of the product. So we are no longer doing full builds. Think of it like doing a production patch. We’ve gotten away from full regression tests because, with each release, we are only changing one tiny part of the product. It is far less risky. Why test the hell out of bits that didn’t change?
So now we regression test based on one risk: the feature going to prod. Sometimes it means an hour of regression tests. Sometimes it means no regression tests. So far, it’s a net loss of time spent on regression tests. And this is a good thing.
We switched to Kanban in February. So far, not a single escape has made it to prod (yes, I’m knocking on wood).
This success may just be a coincidence. Or…maybe it’s easier for teams to prevent escaped bugs when those teams can focus on one Feature at a time. Hmmmmmm…
You realize you could have been doing this all along, right? But I'm glad that you've gotten focus by modifying the framework of how you work.
ReplyDeleteOne feature at a time! How novel! That's exactly what you should be doing!
Which of these teams is delivering faster? The one that multitasks and works on three things at the same time? (in whatever period of time you choose)
A B C A B C A B C
Or the one that works on one at a time?
A A A B B B C C C
Make sure you leave some time for some team retrospective time and for demonstration of your work to customers and folks from other teams. Kanban isn't explicit about these, so it's crucial to be disciplined enough to work on improvement and get feedback.
This is interesting. So what you are saying is that your development plans are built around focusing on small parts of the program at a time? Thus, the regression testing is confined? This seems ideal but often the development team is skilled in different parts of the functionality right? so you can't have a 25 man team all focused on one part of the application. How would you implement this with a large team?
ReplyDeleteIsaac, yes you got it. And yes, in my case the progs are still stubborn when it comes to collaborating with each other on the same feature, or working on a module that is not normally their's.
ReplyDeleteBut everything is relative. Better to have a 25 man team working on 25 features rather than 100, right?