You start a software project with the best intentions, but things often don’t go to plan.
Hint: the solution is often using an evolutionary lifecycle, which you can achieve with Lean-Agile.
What is an evolutionary lifecycle?
An evolutionary lifecycle is a project management methodology. Work takes place in smaller 2-4 week increments, called sprints. Each sprint involves thinking, doing, testing, and reflecting activities.
Sprints give numerous benefits, such as:
- Just-in-time planning, which reduces wasted effort.
- Opportunities to reflect and learn.
- Promoting continuous improvement, where teams reflect on the work and identify improvements for next time.
- Chances to re-focus on the product priorities and goals with the help of regular user testing and stakeholder feedback.
And the most significant benefit of all is that the product can evolve as knowledge evolves from quick feedback loops. For more details about Lean-Agile, see our collection of articles that walk you through key aspects of it.
Let’s look at some of the pain points our customers could experience in their software projects and what you can do about them.
Pain point: Takes too long to launch
Example: Sam has been the project manager of the SuperSolver product for over three years. At the start, they chose the Waterfall methodology because most of them knew it. Sam and the stakeholders did all the planning and defining at the start.
When complete, developers began implementing the low-level infrastructure and then added each feature. In the testing phase, emergent work and fixes are required, so the deadlines are put back. Fred, the financial backer, is unhappy with the delays as he wants to see a return on his investment.
Solution/expertise: Methodologies where all the planning happens first and the testing at the end can increase project risks. Agile sprints give frequent opportunities to re-evaluate the priorities and risks, giving chances to reduce them. For example, early testing can often identify problems you might not find until the end of a project.
At the end of each sprint, teams create a potentially releasable version. Having this version gives a choice to release it early if deadlines need to come forward. Implementing features as “vertical slices” of working code means that users can see or test each part quicker.
Read more on reducing time-to-market:
Pain point: We didn’t know everything at the start, but now we’re stuck with old decisions
Example: Despite spending a long time making technical decisions at the start, Sam and the team discovered that their chosen technology runs much slower than expected. Sam knows this might put customers off using the product but doesn’t want to waste all the hard work. Migrating the code to another technology would be slow and expensive.
Solution/expertise: When you’re embarking on a new project, there can be big unknowns. This could be technology and architecture decisions, the communication plan, which features to include or do first, and which features users will value most. Early in a project, investing some time testing early prototypes in parallel is a good idea. Each sprint, you can review the evidence and narrow your choices. You can make an educated decision that reduces project risk without investing long-term time and expense into a single one that becomes non-viable.
Read more on dealing with unknowns:
Pain point: Something unexpected happened... and now we need to change things
Example: Two years into the development of SuperSolver, Covid-19 arrived. Jordan, a key stakeholder, had a brilliant idea to add a health sensor that could increase the target audience and revenue. Sam felt excited and knew they needed to capitalise on this opportunity before competitors did.
Solution/expertise: Similar to the failed plan above, sometimes opportunities arise that mean you want to make changes. The benefit of Agile sprints is that they allow you to change direction at relatively short notice. Planning the work that will go into the next sprint in a just-in-time way, and creating working versions each time, give you options for where to go next.
Read more on dealing with the unexpected:
Pain point: Development teams are overwhelmed
Example: SuperSolver was supposed to be fixed-scope for the first release. But stakeholders keep pushing for more features, and “surprises” keep arising from the development teams. The backlog is growing, and communication is poor. Sam keeps moving the deadline back, which adds pressure to get more work done faster. A development team lead, Alex, seems increasingly irritable and stressed. Her team have been doing overtime for months to try and get it finished, and she complains that “there is no end in sight.”
Solution/expertise: Scope creep, and emergent work often results in delayed deadlines. This can be hard on development teams, leading to burnout. It is not sustainable long-term and will likely lead to high employee turnover, sickness rates, or more errors.
Breaking the work down into short sprints helps teams focus on the most valuable work and identify work that is not essential. You can ask stakeholders, “If you could only pick one feature, which would it be?” to help clarify which is most important. And remove lower priority tasks from the sprint.
Retrospectives at the end of a sprint offer the chance for teams to reflect on how they can work more effectively. Continuous improvement can improve technical skills, processes, and team wellbeing.
Teams under pressure also risk compromised psychological safety. If there are urgent deadlines and stress, team members might feel less able to speak out if they spot flaws in the product. They might also feel unable to say no to pushy stakeholders.
Read more on reducing overwhelm in development teams:
Pain point: Customers don’t like (or use) what we’ve made
Example: Finally, the SuperSolver product was ready! It went to market, and users started to register and use it. However, daily usage numbers soon levelled and then reduced. Customer reviews had only 1 or 2 stars. Sam would cringe when he read the words, “Avoid! Too slow and difficult to use”. The directors told Sam they were concerned about the company’s reputation.
Solution/expertise: During development, regularly check that users want and need what you’re making. Even if you identified what users wanted at the start of the project, they might change their minds when they see it. Or need different things.
Sharing development versions with users can create a quick feedback loop. You can also run usability workshops. Prioritise the upcoming work based on these insights as you plan the subsequent work.
User feedback also gives reassurance to stakeholders that the product will be a success.
Including a UX person or a Product Manager on your team helps voice the needs and values of the user in planning meetings, backlog prioritisation, and user story writing. Keeping development teams thinking about the users they’re making it for can help them make informed decisions. We have Product Owners and Analysts in our teams who help with this.
Behavior-Driven Development (BDD) is another way to improve a solution. It involves considering new features from the users’ perspective and promotes a conversation about what they need up-front. Automated BDD tests can form “executable specifications”, which save time if your project needs requirement verification.
Read more on meeting customer needs:
Pain point: We have too many bugs
Example: When the development teams started work, they were keen to release SuperSolver fast. Enthused by Sam’s kick-off meeting, they jumped straight into coding, trying to avoid the delays of planning and writing tests upfront. And they put off doing user and automated testing that might cause rework and slow things down. However, once launched, the number of bugs found increased significantly, including some major ones. Sam was frustrated to prioritise maintenance releases over adding more features.
Solution/expertise: For a short proof of concept, you might not want to use Test-Driven Development (TDD). However, most projects benefit from improved quality of code, more bugs found early, and reduced time spent fixing bugs at the end. Automating these tests gives you a regression suite that quickly highlights accidental breakages when code changes. You can set up build server rules that prevent code that breaks other tests from being merged, ensuring good quality.
If you don’t already have them, create coding guidelines and review processes to ensure good quality, habitable code. Habitable code will be simpler and easier to maintain and update.
Regular software testing and user testing are also good ways to find common and usability defects. Users don’t always use a product as developers and testers predict they will.
Read more on reducing bugs:
Pain point: Release cycles are too slow
Example: Sam wanted to quickly fix the mounting pile of urgent bug fixes. Unfortunately, implementing, testing, and releasing them was slow and complicated. Even if only a minor code change was needed to correct one, different configurations required separate approvals and testing. It took over six months for a single fix to be released. Users were annoyed with the delays, and some switched to competitor products.
Solution/expertise: Use the benefits of test automation to reduce the release times required. A suite of tests that run automatically when the code builds can save much time compared to manual testing. Using living documentation to auto-generate associated documentation can also improve release cycle times.
Spend some time at the start of a project deciding how to manage updates. This is essential if your product might be in an inaccessible location or have no internet access.
Read more on reducing release cycle time:
Pain point: Documentation is a burden
Example: Previously, SuperSolver had not needed regulatory approval to be on the market. However, changing regulations means that it now needs to be compliant. Being compliant means a lot more documentation and evidence are required. Sam’s team must now write it retrospectively. Sam wondered if they had kept the old requirement and process documents up to date but thought they probably had been too busy to do it. It seems like a massive task, and the development teams don’t enjoy doing it. They say it can be a dull task at the best of times.
Solution/expertise: Living documentation auto-generates documentation based on the corresponding code and automation scripts. The goal is to document only meaningful or helpful information most efficiently. Living documentation can achieve this in several ways, including:
- Reducing the manual maintenance burden. Automatically include essential information such as test results, requirement verifications, and design decision documents or reference information.
- The documentation matches the code it lives alongside. For example, storing documentation alongside code in a Git repo. This gives added benefits like source control and review/approval opportunities for the content. If you change the code on different branches, the documentation will stay up to date, giving you flexibility.
- Improved communication. Hosting the documentation on a web server means that anyone can easily navigate the latest docs. The development team can quickly access technical processes and information. Stakeholders can view the project status and see the details. You can customise the documentation format; for example, an auditor might prefer a PDF with everything in it. Some stakeholders might want a dashboard or summary report.
- Possibilities. You can add scripts to include any other information you need. You could auto-generate a traceability matrix of requirements and test results. If you need to list open defects, these can be retrieved and then parsed using the API of the work management tool. Or you could include an automated system diagram of the source code.
Read more on documentation:
Make adaptation easier
Evolutionary lifecycle approaches like Agile can make a difference by adapting as circumstances or knowledge change. Even if you have gone down the Waterfall path, our Agile teams can still work within your framework and add improvements to your software development. You can find more about it in this post, where we discussed how Agile could work with Waterfall.
Are you looking to develop a new product or have an existing one?
For over 20 years, Bluefruit Software’s embedded software engineers and testers have worked with many different clients. Our work has included software development for clients producing products across manufacturing, scientific instruments, medical and more. No matter your project stage, we can help.
Did you know that we have a monthly newsletter?
If you’d like insights into software development, Lean-Agile practices, advances in technology and more to your inbox once a month—sign up today!Find out more