Scrum: Handling Big-Bang Changes in the Sprint

October 8, 2009 | Author: PM Hut | Filed under: Agile Project Management, SCRUM

Scrum: Handling Big-Bang Changes in the Sprint
By Jaibeer Malik

This article 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. 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 UI changes.

Sometimes it is hard to predict such changes but once they’re inescapable the best way is to plan it the right way.

Different Approaches

There are different ways to approach such changes. Let’s 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. Let’s have a look at few approaches:

Do-it-in-vertical-slices approach

Pick the technical task and implement the task in parallel without 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

Pick one functionality at a time, including all the layers and make it work from top to bottom. The idea should be not to break any 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 and have them coexist 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 a few issues as a team you need to take care before starting the implementation. 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 expectations 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 a few sprints so that the application is always intact and in running condition. Another important thing is to plan that you also continue to develop few new functionalities 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 members and how they will work together in a 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 stakeholders 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 up to them. Make it clear that such changes may result in lower velocity and productivity from the team. The changes may also result in some broken functionality, the team won’t be able to deliver in one sprint, etc…

Big Bang changes may result into:

lower velocity
lower productivity
less business value delivered
team less motivated
team less focused
failed sprint

How to do it wrong:

start working on changes without 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
the whole team starts 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

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

Data Storage Layer changes

Let’s say you are building some enterprise application for some time and in one of the sprints you come to know that the team will have to use a specific data model, maybe already an 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

Let’s say you need to change the service layer completely in one of the sprints. It can be a new implementation of the service layer or maybe you want to develop plug-in architecture for the application.

Now, either the whole team starts working in parallel and each team member starts 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.

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.

Jaibeer Malik has more than five years of experience in the software industry working on different domains and has been extensively involved in all the stages of the software development life cycle. He is a Certified Scrum Master (CSM), having practical experience of using and implementing the Scrum and distributed Agile methodologies. HHe is currently working with Xebia India as Senior Consultant. His professional experience has been mostly with Java, J2ee technologies. Jaibeer’s blog can be found at http://jaibeermalik.wordpress.com.

Share this article:

Related Articles

This entry was posted on Thursday, October 8th, 2009 and is filed under Agile Project Management, SCRUM. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

No comments yet.

feel free to leave a comment

Comment Guidelines: Basic XHTML is allowed (a href, strong, em, code). All line breaks and paragraphs are automatically generated. Off-topic or inappropriate comments will be edited or deleted. Email addresses will never be published. Keep it PG-13 people!

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

All fields marked with " * " are required.

When Reality Hits - Project Managers Roll With It

When IT Is Your Company’s “Piggy Bank”

4 Key Things a Project Manager Must Do

Essential Project Management

8 Traits of Top Project Managers - Part 1

Agile Project Management - Engaging Your Customer!

9 Tips to Avoid Traps in Project Planning

Why Projects Succeed - Executive Sponsorship

On Customer Participation in Agile Projects

A Project Charter for Lazy Teams