http://www.gettyimages.co.uk/detail/news-photo/life-size-replica-of-the-bridge-from-the-uss-enterprise-news-photo/483247592
My colleagues know that I’m a bit of a Star Trek fan. People who remember the show will tell you that you could usually tell who was going to have something nasty happen them in that particular episode. You would notice a man in a red shirt, who you didn’t recognise, beaming down to the planet and within five minutes he had been vapourised by an alien death ray or poisoned by an innocuous looking plant.
These types of issues faced by the Enterprise crew don’t always occur because they didn’t try and manage the risk, more that they didn’t really perceive that nature of the risk in the first place. Coming back to Earth for a moment, if you think about something like electricity for example, we know about it through experience and predictability. We all use electrical items every day and take very simple precautions – but if you didn’t know that your requirement to make toast over the bath was likely to be risky, then you likely wouldn’t think twice about it.
The useful thing about the Alpha GDS stage is that it gives you the opportunity to ‘de-risk’ the stuff that you know is going to hit you later and address it head-on before you properly get started. However, as we move into applying GDS principles to internal IT-focused projects, I believe that some of those potential risks aren’t going to be as obvious as you might expect them to be.
In a recent example on the Agency’s Funding and Contracting Transformation project, an issue that tripped us up was the application of some new integration technology. We de-risked the product by undertaking a series of tests to prove it would work, but later struggled to find developers with the expertise to use the product to the extent we wanted to – a risk we didn’t see coming. For upcoming projects we’re trying to look beyond the obvious and to try and think about some ‘unknown unknowns’. When you have an experienced team, it’s surprising some of the potential risks they come up with – and are usually right to concern themselves with.
For future projects it may be worth considering whether your Alpha should expand to include consideration of other unpredictable concerns such as:
- market capability and knowledge to address the problem you’re going to give them
- capability of release pipeline and dev environments to support your programmes
- ensuring your ‘Definitions of Done’ are sufficient to enable DevOps teams to use them for live transition, and for integrators to understand the implications should they wish to reuse those services
It is important to mention, however, that you will not catch everything in the Alpha and there will still be things that happen which will affect your project RAG status as you move forward. Failing fast is still nothing to be ashamed of, but there’s no excuse for failing if you’ve ignored the obvious.
You can only wonder what Captain Kirk would have done if he’d been able to undertake a GDS Alpha ‘de-risking’ exercise before landing on those mysterious planets. However, I suspect the episodes would have been shorter and quite dull. But at least a few more of those red shirts would still be alive.
You may also be interested in:
1 comment
Comment by Colin Rogers posted on
There are known knowns. These are things we know that we know. There are known unknowns. That is to say, there are things that we know we don't know. But there are also unknown unknowns. There are things we don't know we don't know.
Donald Rumsfeld
It is refreshing to know `Agile` delivery can create the time and space to focus on these 🙂