A common way of describing risk is using a likelihood vs impact metric. For example, there is a very low likelihood of an asteroid big enough to wipe out the earth actually doing so, however, the impact would be very high.
Many tools give you a lot of granularity when describing risk, one tool I used recently, called Kivue (which is a crock of shit), used integers. Likelihood = [1,2,3,4,5] (what is a likelihood 4, how is it different to a 3?). We used actual words and threw away two of the integers to make it more useful:
1 – Unlikely,
3 – Likely,
5 – Definite
There were also integers for the impact, so we used actual descriptions for those instead:
0 – No impact (why would this be important?)
1 – Low Impact
3 – Medium Impact
5 – High Impact
Once you have your likelihood and impact, you can then work out your exposure:
Likelihood x Impact = Exposure
If you then rank your risks by exposure, with the highest at the top, this will give you a good idea of the risks you should be looking at first. However, having this still didn’t give us a real handle on how to assign a likelihood or impact to risk – one persons 3 might be a slightly more anxious and pessimistic persons 5!
I’d recently been reading (again, it seems to leak out of my head whenever I read about it) about Cynefin and it occurred to me that you can use it define risks. If you’re not sure what Cynefine is, this post may not be useful to you – you should start here and then here. Basically, Cynefine is a decision making framework, where the problem spaces are known, unknown, complex and complicated. There’s a lot more two it than my pithy one-liner and I’d encourage you to take a look at the work of Liz Keogh to find out more.
Anyway, once you’ve up to speed…
This risk is so obvious it might not even be a risk. We know the inputs and the outputs, it’s not complicated (as in, there are few moving parts and no dependencies) and it has two or fewer steps to complete the mitigation.
Likelihood: 0, 1
Someone is on holiday. Someone else covers.
Hardware is needed. Hardware is bought.
This risk has more than two steps, but those steps are well known. The inputs and outputs are also well known. There may also be dependencies, these are also well now.
Impact: 0, 1, 3
A team member doesn’t know how to use a technology. They need training from a peer.
Availability of a resource is unknowable. Seek alternate resource.
Multiple steps, multiple inputs and outputs, multiple dependencies. Some or all of which may be unknow. Work is required to move this kind of risk to “Complicated”. Although, this may not always be the case if we choose not to mitigate this risk, or there are simply too many unknowns.
A choice of technology is unconfirmed, work needs to happen to confirm the choice is appropriate.
Industry-wide definition of product format is changed.
Unknown steps, inputs and dependencies. More of a gut feel used as an early warning system. Chaotic risks should probably never be added to Kivue, although they could be added to a separate RAI register. A chaotic risk should be worked on until it can be move to complex or complicated.
Competitor is releasing a new, secret product.
Annual C-Level board meeting in which the entire company strategy is usually changed.
This worked for us and might work for you to. If not, then I’d implore you to come up with a common way of describing risk, it makes it easier to assess the relative “riskiness” of each risk and understand better where you should apply your mitigation efforts.
You may have other ideas on how to describe your risk impact and likelihood, and, if so, please comment below!
This is the first in a number of posts which will explore a few different software development methodologies. Part of my job as Agile Coach is to know what methodologies there are and how and when they can be applied. We’re agile at Affiliate Window and doing Scrum, which is working well for us, but without knowing what else is out there, we’ll never know if it’s a perfect fit. So, without further ado, I present Lean Software Development!
Lean Software Development is based on seven principles and, in the nature of being Lean, nothing else. These seven guiding tenets were originally written up by Mary and Tom Poppendieck in their award winning book: Implementing Lean Software Development, and I think they’re going to stand the test of time. You could also head to the Wikipedia article, which is what the PoppenDiecks wrote, verbatim. Below is my take on the tenets.
This principle is probably the most well known and the most obvious route to becoming Lean, the hardest part about ‘eliminating waste’ is spotting waste in the first place! It’s often a case of being unable to see the wood for the trees in most teams. But waste comes in many forms. From a developers point of view, waste can be seen as unnecessary code or functionality. So, think about DRY (Don’t Repeat Yourself) and YAGNI (You Ain’t Gonna Need It). Waste can also be seen when developers have to deal with unclear requirements (incomplete requirements are fine though), red tape and bad communication. All of these things, and more, are waste. Think about it this way. If you could get rid of something, or swap something for something more simple and have it not adversely affect your quality or output, then it’s waste.
So, this isn’t listening to a podcast through a Marshall stack, or even making the text bigger in your browser (although, these might help). This is all about making sure that you’re constantly learning and refining your craft as a software engineer. The learning process is sped up by the use of short iteration cycles, meaning you get feedback from the customer and feedback on the process quickly. This ensures you’re constantly learning about your product and the way you build it.
Decide As Late As Possible
This is the part where I tell you about the ‘Last Responsible Moment’. This moment is the very last point in time where you can make a decision. But, it’s not just about putting off a decision until you REALLY have to make one. It’s about putting off a decision until you have as much information as you’re going to get before you have to make a decision. You need to weigh up all the potential options that a decision throws at you, decide what the deadlines are on each of those options, then you’ll know when you need to make your decision by. This is to stop you from making generalised decisions, or writing generalised class structures – stuff you might end up throwing away. Waiting until the very last moment to make a decision might seem reckless, but weigh that with making decisions too early and having to throw work away and you’ll start to see the benefit. If you’re struggling to work out when the last responsible moment is, there’s a great comic strip on the Agile Journal that might help you out.
Deliver As Fast As Possible
This is just common sense in an agile world. Any of the agile-y methodologies suggests that you do this – it increases visibility on how your product is doing through the medium of early feedback. Your customers or users can see what you’re doing in short bursts and feedback to the team. On top of this, it allows the teams to step amplify their learning process with constant, quick feedback. You’ll also be delivering things the customer wants today and not what they asked for three weeks ago. This also draws from Toyota’s way of doing things Just-In-Time. Where you deliver things just in time for the next part of the process, eliminating waste by having nothing hanging around waiting for the next step or phase. In development terms, this means finishing a task and handing it off for testing just as the tester finishes testing the previous task. Not that that’s going to be easy, but no one said it would be!
Empower The Team
Find good people and let them do their job. Don’t hire good developers, testers and the like, then tell them how to deliver the software. The people who know the most about how to deliver your product for you, are the guys in the trenches, the girls on the factory floor, not the managers in their glass boxes. Teach your management layer how to listen to your developers. If you can’t do that, then make sure there’s a conduit for information to flow both ways. If management starts telling developers how to build software, you might as well not bother…
Hire good people, show them what you want and how you think you’d like to get there, then get out of their way.
Empower the team to make decisions on the direction of the product – from their point of view – this is important. Developers aren’t going to know the overarching roadmap and vision of the product unless you tell them, they’ll then be able to start making design decisions based on that knowledge, so hide nothing from them. Hire good people, show them what you want and how you think you’d like to get there, then get out of their way.
Build Integrity In
Software quality is paramount. Developers are no longer satisfied with being such, they’re now engineers, artists and craftsman. To be a good software engineer, you need to be both artist and craftsman. Both of these professions strive for quality and perfection. Your teams should be doing this too. Your software should ship with no defects and to ensure this happens, you need to make sure your teams are baking tests into their product. Automated tests are part of the product, if they’re not useful, they’re wasted and should be stripped. They’re also not the goal, they’re the means to achieve to the goal (a quality product, free from defects).
Building integrity into the code is one thing, you also need to build integrity into the entire system itself. Everyone from the customer to the team members should be refactoring, de-coupling and generally making sure the whole system is rock solid and trustworthy. If your customer has a good feeling about the entire product, then you will too!
See The Whole
Software nowadays is no longer the sum of it’s parts. Now software is modularised, or farmed off into services, it’s the interactions which count – the layers between the layers. Be mindful of the way things interact with one another and you’ll avoid common defects and be able to deliver a better product. Seeing the whole also refers to the relationships between all relevant parties of you project or product. If you’re making software with teams that span the globe, make sure you’re keeping the interactions between your teams and even your 3rd party vendors in your sights. That way, you’re much less likely to miss the problems of integration when they occur.
Implementing these seven parts of Lean Software Development into your Software Delivery Lifecycle, along with a good dash of common sense and some good people on your team should be all you need to create a great software product. Is Lean the answer? I don’t know. It’s one methodology that might suit your team, your industry or your product. But maybe it won’t. From the outside, it seems fairly sensible that, reducing waste is a great idea, but – what is waste really? I don’t think that anyone nowadays will be of the mindset that ‘this is what we do because it’s the way it’s always been done’ are they? So, how do you identify waste when your software development and delivery practices all have a purpose? Do you try and assign a value to the purpose and ditch those practices which fall below a certain value threshold? Maybe. But, until I’ve had a chance to experiment with Lean Software Development, I’ll never be sure.
I’m beginning to think that each methodology has it’s good ideas and common sense ideas – it’s up to you and your team to pick the best ones that work for you, I think that, regardless of your methodology, ‘reducing waste’ is a good guideline to subscribe to and if you take anything away from this, then that’s definitely something to adhere to.