Tackling turnaround: how to handle changes during software development
When you’re delivering software development at scale and at pace, unforeseen changes to the product or personnel can have a real impact on product delivery. Like it or not, change is an integral part of software development. The real trick to success is how you handle it.
Proshore Scrum Master, Milan Khanal, has worked in software development for over 7 years, both as an engineer and a manager. Taking projects through from ideation to the production phase means Milan has a position of oversight and influence over the end product. He’s also highly experienced in using Agile processes to help stakeholders stay aligned with their goals, and enjoy great value and product success.
Why change happens in software development
Change is a fundamental aspect of software development: markets change and competitors release new features. Every software company has different expectations for their product, its timeline, and how the roadmap should run.
Typically, there’s strategic placement of particular developments within certain calendar months. But it’s common that as development gets underway, new features and new content become a priority in response to the market or competition.
With technology rapidly evolving and through ongoing conversations with key stakeholders, new priorities for the product can emerge. With iterative development, clients can get a minimal viable product (MVP) much faster, and this often prompts the realization that other features and content can be added.
In software development, change is expected. But before implementation, it needs to be validated. For example, does the value of the change offset the impact on existing development work? Is it worth pushing back the change to allow for the completion of current priorities in the roadmap?
Successful change management needs negotiation around decision-making and what’s most important at that time for the product’s development. Any change that can be validated creates a win-win situation for the product owner and the development team.
Ways to handle change when developing software
Getting change management right is a delicate balancing act. When a change request is received, the first step of the process is to validate the changes with the deployment team. This is in case what the client is requesting is either too time-consuming for the timeline, beyond the reasonable scope of the current sprint, or likely to lead to significant technological issues.
In acknowledging a change request, it’s important to know where it came from and why it’s important to the business aims. Seeing the vision and the business case for making a change, as well as its goal and the reason for making it, are crucial. It helps to alleviate pressure on the development team when they can see how a change fits into the overall work to be done.
With a clear change management process in place, there’s also the opportunity to consider pushing changes back until other priorities are completed. Fortunately, taking an Agile approach means development teams can be more responsive and incorporate changes within the next sprint cycle. This also requires clear communication between the client and the team in order to maintain the correct priorities.
How to approach big changes to software products
Major changes should not and cannot be rushed. This is because if a team is halfway through a sprint, adding additional work will mean that nothing will actually get completed. It makes much more sense to put it into the next sprint plan once the current sprint goals have been met.
This helps to alleviate pressure on the team and enable them to finish one set of goals before starting on the next. Bigger changes also need to be broken down into smaller chunks so that work can be completed iteratively, which means faster delivery of key functionality for the client.
Accommodating changes in staffing
Changes to staffing also impact the development of a software product. For that reason, it’s important to conduct thorough off-boarding as well as onboarding when developers leave and new ones join.
Following a professional process, it’s important to manage knowledge transfer so that no important information is not lost. New developers need onboarding on technical stacks, which might mean giving sessions one to one, building-up team connections, providing access and reviewing experience in regular meetings.
In terms of onboarding, no matter how experienced they are, a new developer needs to get used to the system, other team members, the product, and the client. For that reason, it’s expected that a new developer on a product won’t initially provide the same value as the existing team. They need time to embed. However, an effective strategy to get them involved and adding value from the get-go is to get them to go over quality assurance because a new perspective can shed new light – such as missed bugs.
With a new client or change in client personnel, it’s advisable to spend the first week investing in the internal development team and getting them onboard with the client’s expectations. A kick-off meeting helps you to gain perspective from the client’s side and their perception of the product and its competitors.
By maintaining open communication channels, developers can talk directly with the client and each other in order to get the best guidance. At Proshore, we encourage this connectivity and flexibility, so we become colleagues rather than a separate outside team. After all, the success of a software product is also our success as developers.
Agile development — built for change
Taking an Agile approach gives development teams the mindset they need to iterate at pace, in a culture of quick wins and failing fast. Often, the barriers to dealing with change effectively are less about delays and deadlines and more about onboarding clients with Agile ways of working.
Sometimes there is a market need to make changes to a product, and veer off slightly from the roadmap journey. And sometimes there is a need based on funding. Either way, change often comes from competitors or developments in the market, so we expect it to happen. Thankfully, Agile software development teams are set up to handle it. Whatever the reason, change needs to have a measurable and realistic impact.
During a sprint, it’s essential to minimise change. The project design phase should give enough monthly direction to create focus and improve team output. Too many changes requests further down the line creates lag.
It’s also important that software companies determine specific goals for what they want each month. If there are too many stakeholder ideas, filter them down and focus on the ones that give the most business value and create an MVP which can be marketed, and then iteratively developed further.
There are also a few other ways to negotiate change requests. Firstly, they can be prioritised according to their business value and technical difficulty – using methods like MoSCoW analysis.
Another approach is to allow all changes as long as they don’t violate the sprint goal. It’s also good practice to check whether the proposed changes impact the project scope, budget, schedule, quality, or risks – and whether they should be implemented ASAP or added to a product backlog.
The bottom line for software development teams is to be adaptable to change requests, with minimal impact on development team members.
The Ultimate Guide to TypeScript Development
TypeScript for Startups: Building a Solid Foundation for the Future
JavaScript vs. TypeScript: The Future of Web Development
