During the time I have passionately pursued my career in software testing, I have been fortunate enough to work on various Agile methodologies which have allowed me to understand a number of pros and cons that need to be considered before selecting one methodology that will ultimately be followed.
Over the past few years the majority of the software industry as a whole has invested a significant amount of time and knowledge in understanding and shifting to a highly productive methodology called Agile. And why not? With the lucrative benefits Agile has to offer over the traditional models, it fulfils the need of the hour to switch to the more efficient methodology. Who doesn’t want to deliver the maximum in the least possible time? The doors have changed my friends and so have their locks; and optimization is definitely the new key to success in today’s world.
Even though many of these methodologies have influenced testing professionals around the world, I, on the contrary, had a few questions that none of the traditional methodologies were able to address. I therefore felt compelled to follow a new methodology called SCRUMBAN. But before I start off with discussing the ins and outs of ScrumBan in detail, we must quickly recall a couple of important aspects of two prevalent methodologies in the market – Scrum and Kanban.
So let’s start with what Mr. Scrum has to offer us:
Scrum introduced the iteration methodology which essentially crafted a path to deliver a huge product in small bundles called iterations. Unlike earlier times when testing professionals like you and me enjoyed a good hot cup of coffee while developers were still banging their heads trying to understand the requirements in order to develop the product, Scrum changed it all. It makes the testing professionals much more involved and hence more committed to the timely delivery of the product by involving them in the early requirement phases. This is how a Scrum board looks like:
A sprint can last for 1-4 weeks–stakeholders are consulted in order to prioritize modules in the sprint including discussions of estimation of the same. This process is followed by a daily talk called a scrum call or a stand up meeting to watch over the daily productivity. After the sprint is delivered, everyone reviews the scrum and then they talk about possible improvements for the next sprint. And that is what Scrum is all about – talk, a lot of it.
Let’s look at some of the flexibilities and benefits that scrum provided over waterfall:
- Instead of taking up the whole project and delivering everything together after a significant length of time, Scrum delivery entails small packets completed consistently in regular intervals. This helps it to adjust to any change in requirements.
- There is a daily scrum meeting arranged to discuss any road blocks so as to ensure that the team is on track.
- The scope of deliverables is confined within the sprint.
- There is more interaction between all the stakeholders, i.e. Dev, QA and business which helps in resolving issues quickly.
- Modules are prioritized in a way to deliver more useful and critical flows to the customer first.
- And most importantly, there is continuous testing of the deliverables to ensure the quality of the product.
Having all those lucrative benefits on the board, Agile started to believe that it was just perfectly awesome and nothing could out-perform its methodology; but this is when the villain of his movie entered the scene– “The Product Owner”.
Product Owner confronted Mr. Awesome and demanded explanation for a few points:
- Why do we need to invest my money on a scrum master?
- Even though scrum claims to be a flexible methodology, is it truly flexible or is the flexibility constricted by time in smaller iterations? Do testers have sufficient time to complete the stories within the iteration time limit or are they overloaded with unreal expectations within the iterations?
- If estimating the efforts required in delivering a project was a major concern in waterfall, why are we still estimating smaller stories to be delivered within a smaller time frame in Scrum?
- Why at times are some QE’s over loaded with work (some of them are working at multiple things at the same time) while others don’t seem to have anything to do?
- A major aspect of scrum is the ability to adjust to the changing demands of the client but can it really accept changes within an ongoing sprint? What if a high priority bug comes from the client in the middle of a sprint that needs to go be addressed immediately? Will you take it up and compromise with the scope of your sprint or ignore the client’s demand?
This left Mr. Awesome dumbstruck and speechless and allowed others to address the issues. Next came Kanban claiming to provide the solution to all these questions.
- It uses a pull methodology i.e. all the stories/issues are stuck to a board and then the respective Dev(s) and QA(s) pick up the ticket that they need to work on – one ticket at a time – move it to the next feasible state and then pick up the next one in line.
- It has made the complete process team-oriented and hence claims it does not require a scrum master nor multiple meetings hence saving time and money.
- It can address any surprise coming from the client at any point of time; all you need to do is stick it to the board.
- Since it is using the pull methodology, it has ensured that one QE works only on one issue at a time.
- And it claims to meet all expectations because it doesn’t set any.
Although Kanban was successful in outperforming Scrum at some points, it neglected some of the major positives that Scrum was offering. The criticism suffered at the hands of Product Owner included the following:
- With all the flexibility you extend to your engineers without any accountability opens the door for abuse–how will you ensure that your engineers are not abusing your flexibility and my money at a dominos or a pizza hut?
- If you don’t set a timeline, when would I really deliver? I can’t go to the clients at any random time—I do need to set expectations.
- And with no prioritization, what’s the use of investing time in testing non-useful or non-critical issues when we have many others that need to go out first?
So Mr. Scrum and Kanban got frustrated and asked the P.O. what did he actually want?
P.O. asked them if he could have a hybrid solution; a solution that can provide the benefits of both Scrum and Kanban and eventually meet the needs of all product owners, business managers, developers and QAs?
This gave rise to SCRUMBAN.
- So I started to use Scrumban in my latest project. Since the whole team was using it for the first time, there were a few hiccups that we had to face initially. To begin with, we put all of our sprint work on a board rather than using the management tool and started picking and moving cards (as discussed in Kanban) – this is what we understood Scrumban was all about.
- But the points that we neglected included: 1) We were still not doing anything significant during the majority of the sprint, 2) We were still estimating the efforts and 3) Even though we picked only one card at a time, the work was still not equally distributed. Essentially, we were still following scrum on a board.
- There were further problems as well. If something urgent came up from the client that needed to go out immediately, we were so packed with our timelines that we had to compromise with the scope of our sprint in order to deliver those issues. To address this specific issue, different people suggested different solutions—what we ultimately tried was to have a separate quality maintenance team that would be dedicated to addressing only the issues coming from the client. But this unfortunately backfired on us. The QE(s) in the maintenance team started to feel side-lined, discouraged and disconnected from the team, plus the knowledge of the project was scattered which caused further problems. So we finally came up with a solution that considered everything together in a better-planned process. We integrated a new board for the bugs coming from the client with the one that we had for our sprint.
We learned that in Scrumban, we must not hardbound the scope of the sprint, rather we should work towards the release date with a vision to deliver the maximum possible. Second, every QE should take up one card at a time, test it thoroughly and deliver it. We may end up not meeting the scope primarily for that sprint but instead of moving the leftover ones back to the product log, they can be carried forward to the next sprint and while the developers will be busy fixing/building new things in the next sprint, QE(s) will have time enough to complete the left over ones which will also keep them involved throughout the sprint.
Now all the QE(s) had equal involvement in the work and started to pick a new issue as soon as they completed their current ones.
To ensure the robustness of the issue, we stopped estimating the efforts upfront; however, the time spent on the issue was still logged after its completion to keep a track on our velocity for future references.
The results began to speak for themselves which greatly improved the team’s morale!
There was one other hurdle with our current approach that we had to clear. What if there were two issues of equal importance, one from the sprint and the other one from the client—both of which needed to be done at the same time? Who would decide which would be selected first?
Our Team Lead pitched in and divided the board that contained the client bugs into three different regions:
FIRE lane meant drop whatever you are doing, “this is a showstopper and we do not care if velocity drops, go fix it now!”
Prio lane meant as soon as you finish what you are doing now, please pick one of these urgent tasks
asAP lane meant to address these issues only if it does not compromise the scope of the sprint
Finally everything started to fall into place. We were able to build new features along with managing the bugs coming from the client without having to compromise the scope of the sprint. There was equal work distribution and every engineer worked only on one task at a time (Limiting WIP). Whatever we delivered was good quality. And the flexibility and responsibility that was offered to the employees helped in motivating their commitment towards the project.
Just some final advice:
Do not set unreasonable expectations. Work steadily at an effective speed. Even if you happen to perform better in a particular sprint, do not set an expectation to deliver at that level every time or you may risk jeopardizing morale when you cannot maintain that pace.
Testing with a sustainable level is perfectly ok because our ultimate aim is to deliver the products at an acceptable level of quality.
A few “cons” for this approach:
- Following this approach may at times result in a slower delivery than what we achieved in scrum but the product will be more solid.
- It may be possible that at times your sprint is full of issues coming from the client and you may not be able to deliver anything new—this is acceptable as long as what is delivered meets our standards for quality.
- Flexibility may make you lethargic, don’t let it do so. Be committed to delivering a quality product.
And finally, no tool is fool proof. If your Quality lead is putting up 100 fires and 50 prios on the board every sprint – the process is not problem.
About the Author
Siddhartha Garg I am a techie by profession working with QA Infotech: Your software testing partner as a testing professional for more than three years now. Outside QA, I am a woman and child rights activist by passion and an active blogger. Coming from a middle class family based on the outskirts of Meerut, I have always been fond of writing and expressing his thoughts. I started penning verses at a very young age. After completing my graduation from Amity University, Noida. I published my first book, In Love with Your Friendship, a story of love and friendship and its complications while my second book “The Silent Scream” which is a fight against a social evil of Child Sexual Abuse is publishing this December. Realizing that I could use my gift in the technical field as well, I have put my experience and pen to paper to jot down and share whatever I can using my experience in the field of testing with the complete testing community.