6 risk management strategies for software development
In the previous article in the series – Crisis strategies for building software, web products and online services” – we identified eight organizational risk management strategies for complex and chaotic times, aimed at not only keeping your business afloat during a crisis but positioning yourself to emerge all the stronger. These broad strategies included aspects of digital transformation and working in more agile and lean ways.
Table of contents
This second article is focused on the six specific risks to your digital product development projects, especially those risks associated with remote working and dispersed teams. Our solutions and strategies for overcoming these six risks are based on Boldare’s 16 years of expertise and practicing scrum, agile and lean startup methodologies.
Software Development Risk #1 – In-house development team suddenly unable to work
In the current situation, it’s entirely possible (maybe even predictable) that your in-house software development team will lose some capacity. Maybe (hopefully not!) team members have fallen ill. Maybe the remote working technology we’re suddenly all so reliant on fails. Maybe there’s an unexpected opportunity to scale up for a much bigger market and you just don’t have the in-house capacity. The big question is, who will finish your digital product?
The classic solution for stakeholders is to consider outsourcing to an external company. Whatever the solution, when you draft in extra resources (from an outsourcing partner or internally) to the project, you can face a number of issues:
- Keeping the focus on the business value – This is a key problem when the business value may be evolving due to project changes or pivots
- Communication can be complex - Especially when your team is not used to remote working, or are now working with new and unfamiliar colleagues.
- Knowledge sharing – Put simply, part-way through the project, you’re now in a position in which not everyone knows everything they need to.
- Prioritizing problems – Where is the team’s focus in these changing circumstances? Is everybody working on the right things?
How to deal with these kinds of issues?
At Boldare, we’ve found the key is to keep the project environment product-driven, with a three-way focus on the:
- business goals,
- the technicalities,
- and the people involved.
Forming scrum teams that are based on the business (not technical!) domain keeps the focus on business value. Furthermore, to boost efficiency in a difficult environment, we recommend a scaled-scrum solution, such as Nexus, an off-the-shelf option that uses scrum basics to solve problems of communication and coordination.
The need for knowledge sharing can be addressed by using cross-team events (for example, for product reviews and planning sessions) so that information on key project issues is heard by everybody at the same time, creating common understanding.
The key is to take the work step-by-step, ensuring nobody falls behind, and creating partnerships based on trust and shared goals.
Software Development Risk #2 – Remote working
Remote working is THE big issue right now, with many businesses tackling the issue for the first time on a large scale. There are two aspects to remote working risks.
- The first is when your in-house development team must disperse and continue the project remotely, probably from home.
- The second is when remote working is a given from the start, such as when you’re using external partners or subcontractors as part of the development team to build a digital product remotely.
1. In-house team working remotely:
The switch to remote working brings issues of security, infrastructure, and even team culture as working habits previously taken for granted are forced to change.
The foundation solution here is choosing the right communications tools to enable the team to collaborate over distance. Here at Boldare, we use:
- Slack and Google Meet for instant communication. Never e-mail!
- GSuite for collaboration on documents.
- Sprint Retrospective Tool (great for scrum-related events but also for much more!)
- Asana for organizational project management.
- Jira for organizing software development and project management.
- Confluence for knowledge-sharing
- Miro for building diagrams together, roadmaps and sketching online, etc.
However, tools by themselves are never enough. You also need agreed best practices and etiquette on how those tools will be used; such as radical transparency (everything is accessible by everyone), comms lines are constantly open for rapid exchange, and – importantly – using those tools for informal communications habits (such as everyone saying, good morning, or a regular shared coffee break).
We had used Slack internally but not with remote teams… I love how everything is in a common channel and everyone can see what’s going on.
Allan Wilson, Founder, CRS
2. Building digital products remotely
While the circumstances might be a little different, many of the risks are broadly the same:
- Lack of shared understanding – With external partners, this can be a difficult problem to fix and that’s why we recommend laying the foundations by beginning the project with a product discovery workshop. The whole team (internal and external) attends virtually to clarify and agree the basic business idea and product vision.
- Poor communication – For us, the key is radical transparency. You should have direct access to the developers and other members of the external project team (no gatekeepers!) with a regular, agreed comms structure, such as daily scrum meetings via video-conferencing.
- Incompatible methodologies – Waterfall versus agile, the big dilemma. Well, for us, 15 years of experience tells us agile is always preferable for software development but sometimes our clients need some support in using a new (agile!) methodology.
- Product quality – When using an external partner for the first time, the quality of the end product is a natural concern. The answer is close and regular communication (always!), working in short sprints to produce rapid product increments for testing and review, and also looking for a partner that offers quality assurance expertise as part of the team.
- Unhealthy dependency – The problem with buying in external expertise is that you can become reliant on it, rather than on yourself. Look for a partner that has strong values around knowledge transfer and support to avoid the problem of vendor lock-in.
Software Development Risk #3 – Management suddenly unable to work
Similar to Risk #1, what happens when the person or people managing the project are forced to drop out of the picture? This might be the in-house development team leader or the Product Owner representing the business needs to an external team. Either way, the project suddenly lacks an element of leadership.
What should you invest in to deal with this risk? The right management style is one that effectively makes the role of manager obsolete:
Starting the project with a product discovery workshop means everyone understands the product vision and goals, equipping them to make their own informed decisions in their role or area of expertise. In other words, the manager/Product Owner should never be the sole decision-maker.
Establishing a high-level roadmap and product release strategy for the project provides a clear direction for the project whether the ‘boss’ is there or not.
Direct access and radical transparency means everyone involved is used to dealing directly with the relevant individual on any particular issue. People are used to getting answers and creating solutions themselves.
Encouraging your development teams (internal or external) to be self-organizing avoids unhelpful hierarchies that can fall apart with the loss of a single person.
In a nutshell, empower your team and distribute authority!
We didn’t initially realise the importance of the product discovery workshop… Now I can’t see doing it any other way.
-Allan Wilson, Founder, CRS
Software Development Risk #4 – Shrinking market
During a crisis in which people are mostly off the streets, working from home as much as possible, the markets are likely to change in unprecedented ways. While it’s reasonable to predict a much stronger market for digital products and life online in general, the changes to the market for your specific, in-development product may not be so favorable…
Yes, new opportunities emerge but some products become obsolete overnight.
Faced with this situation, the main questions are:
- How to update or create products quickly and with minimum resources?
- How to find and validate new business or product ideas?
- How to find a creative business partner?
- How to minimize the costs of investing in a digital product?
The answers lie in the approach you adopt to digital product development. You need a process that quickly and accurately gets to the heart of your business idea, is focused on user requirements and needs, and is flexible enough to respond quickly to changes in the market environment. We recommend the following approaches:
- Agile product development – Development and delivery, and the response to any changes in requirements, are rapid. Teams are flexible and open to changes and opportunities, so they can pivot at any point in the project. The user (customer) is the highest priority. The process means the coding and development, design, and business roles all work closely and with a common focus.
- Lean startup – The build-measure-learn framework for developing digital products means progress is in the form of function-specific, rapid increments. Each product iteration is tested against market needs and the feedback informs the next stage of development, ensuring highly responsive project management. (For more on the benefits of the build-measure-learn cycle, see the first article in our Crash Course series.)
- Full cycle product development – This approach combines agile principles and the lean startup approach to address the complexities of building products in different business and market environments. With its different stages of development – prototyping, minimum viable product, product-market fit, and scaling - the full cycle method helps ensure your project’s development is matched to the stage of development of the relevant market. (For more on the Boldare approach, see our full cycle product development landing page.)
Software Development Risk #5 – Budget interruptions
Project budgets can be affected at any time in a complex and chaotic world, often without warning. It may be a necessary change in business priorities, a drop in company income, interruption to cash flow, or indeed anything that impacts the budget allocated to your digital product development. Unlike other risks, it’s difficult to reduce the likelihood of occurrence because a budget interruption by its nature tends to be unforeseen and is usually beyond the influence of a project team or Product Owner. However, you can take steps so that the impact on the project is minimized should this risk occur.
Agile and lean processes are by nature resource-efficient, including best use of the available budget.
Using an agile project framework, such as scrum, means project and product reviews and planning for every project sprint (usually a one to two-week period).
The lean startup approach to user testing gives your project solid feedback and data at regular points throughout the project; this data is used to confirm that your product is still on track to meet current user and market needs and within budget. If it isn’t, the methodology makes it easy to pivot the project, changing the direction of development to continue to provide value in the new circumstances.
Software Development Risk #6 – Partner unable to deliver
What if you are already working with external partners? They’re subject to any and all or the above risks too… As a provider of development services ourselves, at Boldare, we’re very aware of the potential risks you face by proxy via your external partner.
We recommend five rules:
- No vendor lock-in – Check your contract. Make sure you own the code once the product is done. Use open source or communal components when possible.
- Agile development – Yes, we keep emphasizing agile but that’s because it’s great for risk management! The product backlog used in scrum means that the most important, business-critical elements of your product are delivered first. So, if the project does come to a halt, it’s likely you not only have something, you have something useful.
- Continuous delivery – Working in sprints means that every one to two weeks, you have a workable product iteration; even if functionality is limited, it’s deployable.
- Knowledge sharing – A philosophy of knowledge sharing ensures that at any given stage of the project, you know everything there is to know: communication is direct, progress is transparent, and the capability of your own people has been improved.
- Asset sharing – You not only own but have direct access to the code. From a disaster recovery point of view, if your external partner is out of the picture, you’re not left empty-handed.
Surviving the storm
Digital product development projects face significant risk at the best of times. In the current situation of global complexity (and, at times, chaos) that risk magnified.
Much of that risk relates to the use of, and relationship with external development partners, together with your own people’s increasing need to work remotely. In this scenario, it’s clear that:
- A lack of experience with remote working can slow down or stall software development.
- Modern communications tools (e.g. Slack, Google Meet, GSuite, Sprint Retrospective Tool, Jira, Confluence, etc.) are crucial for keeping distributed teams (internal and external) in touch.
- However, technology and tools aren’t enough – agreed best practices and etiquette on how to use them are necessary to ensure you get the full benefit.
Those are just three highlights of the second webinar in our Crash Course series. The Crash Course webinars and articles are our response to the current global pandemic and reflects our firm belief that a digital transformation strategy is the best way to come out of this crisis thriving, and not just surviving.
Share this article:
