Does Lean software development work in regulated environments?
How to stay lean through governance, assurance and planning.
Lean Software Development is designed to deliver software quickly, build knowledge within teams, and allow decisions to be made at the right time.
Regulated environments have rules and processes that can feel anti-agile at times, but assurance, governance and compliance cannot be ignored.
Governance is often seen as a blocker by engineers and becomes something that will be done later.
In practice, staying lean in regulated environments means considering a few key things: involving governance early, building assurance into your development cycle, iterative planning, and communication with stakeholders
Governance and assurance need to start early
Start governance in discovery phase
Governance is necessary to ensure products are legal and safe. I’ve seen multiple projects stumble or fall because their intended data processing would not satisfy the Information Commissioner’s Office.
Part of your discovery should be understanding the types of data your product will handle and why you are processing it. Engaging with governance early ensures you are building an appropriate high quality product from the start.
Producing a DPIA is an iterative process until it is concluded, just like your data model and should evolve alongside your product design.
Plan assurance into your release process
Assurance processes are often overlooked in planning but they are mandatory for your product. Technical teams sometimes think the last responsible moment to engage with assurance is the few minutes before release.
If you hear tech leads saying “Why do they need to know this? I’m confident in our tests, why do they need a test report?” this is a sign that the assurance process is not integrated into your development lifecycle and needs to be communicated more effectively.
Assurance should be involved from the very start of your process. Light touch meetings and discussions over architecture will maintain an open dialogue and ensure smooth compliant delivery.
Lean needs planning and stakeholder management
Lean still requires planning
A common issue is that teams think Lean means no planning required. Unless you work in a place where everything outside of your team works reactively and perfectly, you need to share a plan with others. Yes, the plan can and will change. No, you won’t meet every date that is in the plan, but other teams will at some point need to know what you are doing and when.
Get Policy Meets Code’s stories in your inbox
Join Medium for free to get updates from this writer.
Sometimes technical people forget that other teams are planning for real world logistics, not software releases that can be postponed or rolled back. Examples I have seen where the software team had no idea of real world impact:
- Launch events, where people needed to book venues and send invitations.
- Logistics of moving equipment.
- Teams recruiting people to support the launch.
- Training required for staff to use the system.
- Engaging Pen testers.
Planning in Lean allows the plans to change but other teams often just need to know an approximate date and more importantly when that date moves.
Customers need input on scope and features
Lean delivery can involve cutting scope as the team learns about the problem it is solving. However, removing features at the last moment is often due to planning more work than was achievable. I have seen teams frame this as the lean process at work, focusing on the highest priority items first.
Transparency to customers and stakeholders is beneficial in this situation. Bring others into the decision making, explain the changes to scope and treat it as a learning opportunity for the whole team.
Lean does not remove external constraints
Lean does not remove time constraints
In real world software development deadlines are not always flexible. Lean can still work for your team alongside a pragmatic approach to road-mapping.
Whilst deadlines can feel frustrating in your Lean team, compromise and collaboration across your organisation is important.
Lean does not remove financial constraints
Lean teams cost money to run, just like any other team. Recruitment, contracts, cloud services, laptops etc. all cost money and take time to source.
I have seen teams where mob programming is used very frequently, to ensure knowledge is shared, but it is being shared among high cost short term contractors and scope is being cut as a result. Engineering knowledge sharing does not always have a good return on the time investment.
Finances still need to be a major consideration in the choices that you make. Especially as your regulated software is probably solving an important problem or your funding is from public money.
Conclusion
Lean is a powerful methodology for improving software delivery, but it is often misunderstood in regulated environments. Governance, assurance, planning and financial constraints are not obstacles to Lean delivery, they are part of the system in which the software exists.
Teams that succeed with Lean in regulated environments recognise these constraints early and build them into their delivery process. Governance starts in discovery, assurance is planned into releases, and stakeholders are kept informed as plans evolve.
Lean does not remove organisational realities such as deadlines, budgets, or compliance requirements. What it does provide is a way for teams to adapt, learn, and deliver value within those constraints. When governance and assurance are treated as part of the development lifecycle rather than external blockers, Lean can help teams deliver high-quality regulated software more effectively.
Do you have experience using Lean in regulated environments? Please share your experiences below.
