“The only permanent thing in this world is change.” – It’s a cliché most of us have heard a million times. But it’s a statement that doesn’t really go deep into our hearts. Having worked in developing software for the last ten years, I see the tendency in almost everyone I meet: we all want to fix requirements, demarcate boundaries and work with an unchanging blueprint.
But just like life, the most challenging projects have a life of their own. They grow, they mutate and they mature. And all your dreams and hopes and efforts at freezing requirements are shattered totally. Experience has helped me recognize the truth behind the words of Alan Watts (at least as far as developing applications and building products is concerned!):
Unless you are working on a rather simple project, you will have to face the reality of change at every point.
Well, here’s 10 things that are helping us successfully manage change in software product development, and we are sharing them in the hope that they will help you too!
The biggest mistake you can make is trying to stop change. It’s a natural tendency to get a clear set of requirements and freeze it, but that’s not going to happen. Especially, when you are developing products amidst stiff competition in a dynamic market.
I always remember these words from my Agile coach: "You can walk on water and build software really smoothly provided both are frozen." But when you do not have frozen requirements, it is the ability to identify the need for change and adapt to it that really counts. This shift in thinking is the key to a truly Agile team.
These words are straight out of the Agile Manifesto. While there are many who feel that Agile doesn’t work in real life, the truth is that it works well with a motivated team of ‘A’ level players. If you have that kind of a team, fostering interactions amongst the team and ensuring communication with other stakeholders is the key to success.
You need each member of the team to be aware of the needs and deeds of other team members, the clients and, if possible, the end users. This will nurture an environment where self-motivated individuals know the exact reason for why things are done and what the impact of their actions will be.
For most of us, the core task is building a working product that evolves rapidly and iteratively. By measuring value of output in terms of product requirements, you can get verifiable results. Also, when you focus on building portions of products iteratively, based on subsets of high-priority requirements, you create a feedback loop that helps refine the product rapidly at every step.
When you are working on a dynamic software product, there as much difference between initial requirements and final requirements as there is between Clark Kent and Superman! In order to deliver a competitive and successful product, you will need to collaborate regularly with your customer. As long as the focus is on the solution and not just the short-term objectives, and work together with a common desire to achieve a clear end-result, there chances of success are a lot greater.
At the end of the day, the success of the product will be measured by the number of sales. You need to hear from the sales and marketing teams and give them a product that is saleable. One of the questions that will always crop up is: how to prioritize features to be delivered. While there are various ways in which you can dynamically connect with the sales & marketing teams, the following process works well for us:
When you are working on a complex requirement, a complicated programming syntax may not work well. But mind maps that represent the different aspects – outcomes, events, sprints OR logic, scenarios, cases and flow – visually, are very helpful in simplifying things.
While the Agile approach depends on independence and initiative from all the team members, the need for close and daily monitoring remains. Unless there is an experienced leader monitoring daily activities, there is a chance of small problems turning into risks, and risks turning into issues. Using burn-down and burn-up charts is an approach we use to overcome this challenge.
Over time, I have realized that the right tools can make a big difference. So, take time to identify and make the most of tools that can help you at any stage. Also, customizing the tools to make them fit your specific requirements can also be worth the time and effort it takes.
At Cygnet, we love using poker to get an accurate estimate. Using poker, all the team members involved in the project and speak their mind on the estimate for a specific task. While the team may not get it right in the first or second iteration, they will get really good within a few iterations.
Activities review, code review and clean up need a place in your sprint. The same goes for things like performance tuning and DBA lookup. By keeping some room for these in the sprint, you make sure that you do not have a lot of technical debt.
These are some of the ways in which we (and many other software product development companies across the world) thrive while working on project with dynamic requirements.
Are you looking for a backend product development partner? Cygnet may just be the right fit for you. Let's talk
Free ebook: How to Guarantee the Success of your Product Marketing PlanClick here to Free Download
An email with the relevant details is on its way to your inbox.
We will be in contact shortly