Change Management in Agile software Development Cycle

It may sound like a paradox although it is well known that change is constant in software development.

Business requirements evolve and vary with customer needs and the market itself. The old question “what is going to be next” is rapidly transformed into “how do we adapt fast enough”. Seen from the business perspective it is a step in the roadmap. This needs to be supported by technical aspects that will have an impact on marketing, sales, operation, distribution or other business departments. When that step is going to be taken application development efforts have to answer properly and this usually means in a timely and budget-friendly manner.

efforts have to answer properly and this usually means in a timely and budget-friendly manner.

Then there is a product that has already been released to the public that needs a boost or even a product that is still under development that needs to be modified to fit the new business necessity. At this point is where Agile Software Development makes complete sense to maximize the value that will be returned to that business, being a time-efficient approach that is utterly adaptable to evolution. SCRUM, one of the main set of practices in the Agile world, is especially suitable for this kind of situation.

There is a timebox defined where the effort of the team is applied to develop a set of prioritized requirements (user stories). The whole cycle is interesting enough to have its dedicated discussion, however, the point is that SCRUM practices define a given amount of time to perform certain work that will result in a product that is expected to add value. At this point, there probably is a long list of upcoming requirements already in place and ready to be developed when the business needs a change and consequently redefines the priorities of a product that is still under development.

So what does this situation mean in the Agile Development Cycle?

That will depend on two main variables, is there a project in place? Or is there a dedicated software development Team?.

Project in Place

As there is a limited scope in a given time with a restricted budget, changes have to be identified as such to find the best mechanism to apply them lowering the impact to the planning. This is feasible, especially when business, stakeholders and project teams are well aligned. The timebox for each iteration in development (the sprint) allows the ability to plan for changes in the short-coming future, as short as the next iteration in the plan.

Prioritization of requirements must be done. In the next Sprint, the agile software development team could be completely focussed on the new feature to develop. Although, if the new requirement is accepted as part of the scope then a modification in time, budget or resources must be made or even the scope itself (again) removing a feature with a similar impact that is, allegedly, adding less value to the business needs. If the later is performed then the risk of affecting time and budget tends to be lowered.

The dedicated Software development team

This case is particularly appropriate to manage changes as it is highly likely that the backlog is already in place and an Agile Development Cycle, comprised of requirements that are already prioritized towards the business needs and therefore the application development team is focussed in adding the proper value. In this situation, the changes should be placed into priorities, by the product owner (another SCRUM methodology role) in agreement with the business, and the team will develop accordingly.

In this sense, it is recommendable that if the changes are going to be applied to perform them in the next Sprint instead of the one currently in progress (if given the case), otherwise it may be disruptive to the development process and cause the loss of the current work in progress. Unless it is strictly necessary interrupting a Sprint in progress should be avoided.

Finally, If changes are frequently requested by the business, and that is the real dynamic of the business, then other agile software development approaches accommodate this kind of situation. This is a subject to expound upon in another post.

Contact us to help you with your Agile software project.