Fix your Software Project problems with Lean-Agile

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:

Medical device software: Four ways to cut your time-to-market

Plans v Planning: their differences, their value and how you can get them right in Lean-Agile software development

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:

Proof of Concept, Prototype, MVP, and MMP in embedded software development

How to optimise a whole project using The Four Quadrants

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:

Quality: the Lean-Agile way to accessible, safe software

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:

Why you need retrospectives for your project and how to use them

Psychological safety in the workplace

Burnout in Agile Teams – what are Bluefruit’s strategies to prevent it?

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:

How to bring User-Centred Design to your software project

Behaviour-Driven Development with Gherkin

What’s Lean-Agile, and how can it help you avoid project waste?

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:

How do you help people embrace TDD? (Especially if they don’t want to do it)

Keep it simple: why you should care about habitable code in embedded software and how to achieve it

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:

How your software project can benefit from test automation

Why you need living documentation for software projects (and how to do it)

How to improve reliability in software engineering

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:

What is living documentation for medical device software?

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.

Written by Jane Orme.