By Nolan Ramsey – Senior Manager, RAD Solutions.
Our lead rapid application developer at Mendix Solutions explains the problem of bugs whilst creating software, and how he has managed them in a rapid application development environment.
One thing that is inevitable in agile software development is that you will create bugs in your software. The question becomes how and when you deploy fixes for them.
Each client has differing levels of change control processes that need to be considered when dealing with these fixes. You want to eradicate the bugs as quickly as possible, particularly if they are preventing the end users from completing their work, but you don’t want to affect current main line development. I’ll give you a process I use that seems to be working best after much trial and error.
I typically ask my users to leverage the ‘Feedback’ widget in the applications I build to send screenshots and descriptions of whatever they find in the app that doesn’t work as expected. Some clients use a central Help Desk and have others triage the problems. The key is to capture the issues so they can be prioritized.
When scoping out what to put in a sprint, depending on where on the continuum the application is in its life-cycle (e.g. Early development vs. In Production), I’ll increase the buffer to allow for time to address found bugs. One thing I’ve learned with Mendix and Rapid Application Development versus traditional Waterfall SDLC projects is you want to keep the rate of change high so as to keep the user’s engaged and ultimately satisfied that their needs are being heard and addressed. You don’t want to receive a bug report only to report back that it will be in a future release months down the road. This will cause additional data to get corrupted while the bug exists and workaround processes get developed destroying the integrity of the application (and you!)
That’s where the idea of the Bug Branch comes into play. Here’s is what has been working for me:
- Create your sprint with a buffer based on your velocity and rate of bug finds. For Example, if you are in Production and you are spending 20 points out of 100 points per sprint on average addressing bugs, built the Sprint with 80 story points so you have that 20% buffer.
- Features get worked on in your main line development.
- At the start of a Sprint, you will have just pushed the last Sprint to Production. Create a branch line of that release and call it “Bug Branch”
- When prioritized bugs are found, add them to the current Sprint, stop working on your mainline (unless you are multi-development team then divvy it up) and address the bug in the Bug Branch. For the record, prioritized bugs are ones that are stopping the users from performing their tasks, not things like a mispelled word. You have to use some discernment with the users to prioritize effectively as you don’t want to stop mainline development for minor issues that can truly wait.
- After Unit Testing the bug, I will typically release the “Bug Branch” build to Production as a Hot Fix each night if there is something to release.
- If it breaks something else (because it doesn’t get regression tested in this mode), it just becomes a new bug to address. This happens rarely.
- When we finish the mainline development near the end of the sprint, I merge the current Bug Branch (which is what is in Production at that time) into the mainline and QA testing begins. Automated testing is nice in this scenario but rare. Run your scripts and makes sure the new and possible affected old features get addressed.
- When QA passes push that to Production and repeat by creating a new bug branch from that release.
I’ve experimented with a few different processes as I figure out how to work in SCRUM teams. This seems to work out best as I manage Sprints in two week intervals and the users get to see problems getting fixed everyday if need be while waiting for their new set of features. If you push to prod too often it can cause just as many problems as not often enough. That is why this process has tended to work out the best because people are willing to wait a bit for new stuff, but they tend not to be as lenient about broken stuff.
How about you? I’m interested to learn how you other RAD developers manage your releases and address bugs versus mainline development? Chime in the comments!
If you would like to find out more about Mendix Solutions head over to www.mendixsolutions.com . To discuss our previous projects or if you have an idea that you would like to explore please get in touch.