Agile: Handling Big-Bang changes in the sprint

This post covers some of the approaches you can plan to handle the Big-Bang changes during the sprint. It may be that some of the ways may not fit exactly to your requirements but you can definitely relate and plan it the best way and to handle the impediments with the right approach in those scenarios to minimize the waste, lean way.

Big-Bang Changes

The term big-bang changes here refer the changes to be done in the critical modules of the application which may be infrastructural, network, integration, data storage layer, service modules or even may be the UI changes.

Sometimes it is hard to predict such changes but once it has to be made then the best way is to plan it the right way.

Different Approaches

There are different ways to approach such changes. Lets say you have some web application and there are some critical changes to be made which may break the whole application if not approached right. What would you like to do, pick each layer separately and make the changes or pick one functionality at a time and keep the application in working state. Lets have a look at few approaches:

Do-it-in-vertical-slices approach:

Pick the technicaltask and implement the task in parallel with out integrating it yet. Once the technical task is complete and concept is well proven and working fine, integrate it with one functionality at a time, making sure the integration works fine for one and in continuous approach in an incremental way do it for the rest, making sure the application is still intact and not broken.

Do-it-in-horizontal-slices approach:

Pickone functionality at a time, including all the layers and make it work from top to bottom. The idea should be not to break all other functionality and keep the application in working state.

Do-it-now approach:

Forget about the existing architecture, just scrap it and start working from scratch. This approach may lead to broken functionality, impediments to all others.

Do-it-in-phases approach:

Implement the new changes separately, plan to work the new changes co exist with the old functionality. Plan the move over to new changes in phases making sure the minimum impact on the application. This approach include through planning for move over.

Setting Expectations Right

Technical changes are one thing but there are still few things as a team you need to take care before actually jumping into the things. You need to thoroughly work with-in the team and also with the product owner, analyzing the impact of the changes and setting the right expectation for both the team and the product owner.

Team

Whatever approach you plan, try to keep in mind that you should try to have the minimum impact on the existing application. If not possible, plan the changes over few sprints so that the application is always intact in running condition. Another important thing is to plan that you also continue to develop few new functionality so that you at least have something to demo apart from the different technical tasks to accommodate the changes.

Now the big responsibility here comes to the team that how the team work together in collaborative environment to make it work. If everyone starts picking the parallel tasks, the impact once everyone is done will be huge, the integration issues will pop up in huge number. Even if you divide it that way, plan in a way that the dependent tasks are done first and till the time other team members are done, the functionality should be ready to integrate and test.

Another point to work out as a team is to keep the morale, focus, motivation etc. up for the team. Such big changes may impact such things in a certain way, work it out the best way for the team.

Product Owner

The product owner and the respective shareholders should be well informed and in loop for the impacts of any of the big bang changes to be incorporated, after all the final decision is with them to make. Make it clear that such changes may result in lower velocity and productivity from the team. The changes may also result in some of the broken functionality, team won’t be able to deliver in one sprint and stuff like that.

Big Bang changes may result into

lower Velocity

lower productivity

less business value delivered

team less motivated

team less focused

failed sprint

How to screw it

start working on changes with out analyzing the side affects

check in broken code

keeping team out of loop of changes

having broken functionality

no test cases, at least none passing

whole team start working in parallel

Things to keep in mind

build is never broken

all test cases passing

minimum impact on existing functionality

communicate the impact of changes in advance before check in.

plan to deliver some new functionality also along with fixing old ones

Few Examples

Lets take examples of some critical changes in the different layers and see how you can approach to such changes.

Data Storage Layer changes

Lets say you are building some enterprise application for some time and in one of the sprint you come to know that the team will have to use a specific data model, may be already existing production data model.

Now, you can either directly change the data model to production schema and start fixing your domain model and test cases for the new data model. Another approach can be to do it in slices, I mean plan that the impact of changes to new data model should be minimum on the application at any stage. You plan to change over the data model over some sprints.

Service Layer Changes

Lets say you need to change the service layer or dao layer completely in one of the sprints. It can be new implementation of the service layer or may be you want to develop plug-in architecture for the application.

Now, either the whole team start working in parallel and each team member start making changes for one of the services or another way is to plan the changes required properly to have the minimum impact and making sure to have the application in running state all the time. See which of the above approaches fits best for your case and plan it accordingly.

One of the things that is required for both of the above examples it to have the test cases in place before going for the changes. Before implementing the changes make sure you have the test cases in place to be sure that the changes are working fine.

Plan It Right!!!

If you are lucky, anything may work for you but still if in case you fall in such situation plan it the right way.

Some of the things may sound very trivial here and people may even say that is what make sense and if you do it any other ways then you have problems somewhere, well that is the whole idea to emphasize on the point that sometimes even trivial things becomes huge issue if people start ignoring those.