{"id":4617,"date":"2022-06-01T12:30:23","date_gmt":"2022-06-01T10:30:23","guid":{"rendered":"https:\/\/proshore.eu\/?p=4617"},"modified":"2024-04-03T01:10:32","modified_gmt":"2024-04-02T23:10:32","slug":"tackling-turnaround-changes-during-software-development","status":"publish","type":"post","link":"https:\/\/proshore.eu\/tackling-turnaround-changes-during-software-development\/","title":{"rendered":"Tackling turnaround: how to handle changes during software development \u00a0"},"content":{"rendered":"\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t

When you\u2019re 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.<\/p>\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t

\n\t\t\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t

Proshore Scrum Master, <\/span>Milan Khanal<\/span><\/a><\/span>, 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\u2019s also highly experienced in using Agile processes to help stakeholders stay aligned with their goals, and enjoy great value and product success.\u00a0 <\/span><\/p>\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t

\n\t\t\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t

Why change happens in software development<\/h2>\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t\t\t\t\t
The first thing I like to validate with the client is: do the changes that you\u2019re going to make add value to the product we are going to make?<\/div>\n\t\t\t\n\t\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t\t\t
\n\t\t\t\t\t\t\t\"\"\t\t\t\t\t\t<\/div>\n\t\t\t\t\t\n\t\t\t\t\t\t\t\t\t\t
\n\t\t\t\t\t\t\t\t\t\t\t\t\t\t
Milan Khanal<\/div>\n\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t
Scrum Master, Proshore<\/div>\n\t\t\t\t\t\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t\t\t\t\t\t<\/div>\n\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t\t\t\t\t\"\"\t\t\t\t\t\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t

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.\u00a0<\/span><\/p>

Typically, there\u2019s 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.\u00a0<\/span><\/p>

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.\u00a0<\/span><\/p>

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?\u00a0<\/span><\/p>

Successful change management needs negotiation around decision-making and what\u2019s most important at that time for the product\u2019s development. Any change that can be validated creates a win-win situation for the product owner and the development team.<\/span><\/p>\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t

\n\t\t\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t

Ways to handle change when developing software<\/h2>\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t

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.\u00a0<\/span><\/p>

In acknowledging a change request, it\u2019s important to know where it came from and why it\u2019s 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.\u00a0<\/span><\/p>

With a clear change management process in place, there\u2019s 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. <\/span><\/p>\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t

\n\t\t\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t

How to approach big changes to software products<\/h2>\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t\t\t\t\t
When a change makes sense, it gives you value, and there\u2019s not too much distraction from the roadmap, we accommodate it \u2013 because we understand the competitive environment.<\/div>\n\t\t\t\n\t\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t\t\t
\n\t\t\t\t\t\t\t\"\"\t\t\t\t\t\t<\/div>\n\t\t\t\t\t\n\t\t\t\t\t\t\t\t\t\t
\n\t\t\t\t\t\t\t\t\t\t\t\t\t\t
Milan Khanal<\/div>\n\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t
Scrum Master, Proshore<\/div>\n\t\t\t\t\t\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t\t\t\t\t\t<\/div>\n\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t\t\t\t\t\"\"\t\t\t\t\t\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t

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.\u00a0<\/span><\/p>

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. <\/span><\/p>\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t

\n\t\t\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t

Accommodating changes in staffing<\/h2>\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t

Changes to staffing also impact the development of a software product. For that reason, it\u2019s important to conduct thorough off-boarding as well as onboarding when developers leave and new ones join.\u00a0<\/span><\/p>

Following a professional process, it\u2019s 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.<\/span><\/p>

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\u2019s expected that a new developer on a product won\u2019t 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 \u2013 such as missed bugs.\u00a0<\/span><\/p>

With a new client or change in client personnel, it\u2019s advisable to spend the first week investing in the internal development team and getting them onboard with the client\u2019s expectations. A kick-off meeting helps you to gain perspective from the client\u2019s side and their perception of the product and its competitors.\u00a0<\/span><\/p>

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.<\/span><\/p>\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t

\n\t\t\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t

Agile development \u2014 built for change<\/h2>\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t\t\t\t\t
Change is welcome, but there has to be negotiation on deadlines because a change request and the pre-agreed work to be done for a sprint, cannot be completed simultaneously.<\/div>\n\t\t\t\n\t\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t\t\t
\n\t\t\t\t\t\t\t\"\"\t\t\t\t\t\t<\/div>\n\t\t\t\t\t\n\t\t\t\t\t\t\t\t\t\t
\n\t\t\t\t\t\t\t\t\t\t\t\t\t\t
Milan Khanal<\/div>\n\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t
Scrum Master, Proshore<\/div>\n\t\t\t\t\t\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t\t\t\t\t\t<\/div>\n\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t\t\t\t\t\"\"\t\t\t\t\t\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t

Taking an <\/span>Agile approach<\/span><\/a><\/span> 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.<\/span><\/p>

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, <\/span>Agile software development teams<\/span><\/a><\/span> are set up to handle it.<\/span> Whatever the reason, change needs to have a measurable and realistic impact.\u00a0<\/span><\/p>

During a sprint, it\u2019s 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.\u00a0<\/span><\/p>

It\u2019s 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.<\/span><\/p>

There are also a few other ways to negotiate change requests. Firstly, they can be prioritised according to their business value and technical difficulty \u2013 using methods like MoSCoW analysis.\u00a0<\/span><\/p>

Another approach is to allow all changes as long as they don\u2019t violate the sprint goal. It\u2019s also good practice to check whether the proposed changes impact the project scope, budget, schedule, quality, or risks\u00a0\u2013 and whether they should be implemented ASAP or added to a product backlog.<\/span><\/p>

The bottom line for software development teams is to be adaptable to change requests, with minimal impact on development team members.<\/strong><\/p>\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t<\/div>\n\t\t","protected":false},"excerpt":{"rendered":"

When you\u2019re 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…<\/p>\n","protected":false},"author":11,"featured_media":4917,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[18],"tags":[25],"acf":[],"_links":{"self":[{"href":"https:\/\/proshore.eu\/wp-json\/wp\/v2\/posts\/4617"}],"collection":[{"href":"https:\/\/proshore.eu\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/proshore.eu\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/proshore.eu\/wp-json\/wp\/v2\/users\/11"}],"replies":[{"embeddable":true,"href":"https:\/\/proshore.eu\/wp-json\/wp\/v2\/comments?post=4617"}],"version-history":[{"count":16,"href":"https:\/\/proshore.eu\/wp-json\/wp\/v2\/posts\/4617\/revisions"}],"predecessor-version":[{"id":15199,"href":"https:\/\/proshore.eu\/wp-json\/wp\/v2\/posts\/4617\/revisions\/15199"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/proshore.eu\/wp-json\/wp\/v2\/media\/4917"}],"wp:attachment":[{"href":"https:\/\/proshore.eu\/wp-json\/wp\/v2\/media?parent=4617"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/proshore.eu\/wp-json\/wp\/v2\/categories?post=4617"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/proshore.eu\/wp-json\/wp\/v2\/tags?post=4617"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}