Here is the output of our production monitoring. Please read this information and answer the question below:
appears to be “You don’t. What you need is an Ideas Splurge.”
Giving away the punchline: In crude terms, an Ideas Splurge generates more well-thought-through ideas per person in less time. More people meet and talk in less time. It is more inclusive, and less off-putting to newbies. It can be arranged at shorter notice, and there is less to go wrong. It leaves folks wanting more, rather than, as with many hackathons, “well, I’m glad that’s over”. An Ideas Splurge is, fundamentally, more effective at tackling the disconnects between disparate groups within a company.
Over the past few years at the FT we have steadily been increasing our disaster recovery testing with planned failovers and deliberate acts of sabotage to our own estate. Taking a leaf from the Netflix simian army, we have gradually improved our services’ resilience with what we have learnt from these exercises. For example, powering down DNS or Active Directory servers have highlighted areas of weakness that we have been able to mitigate or remedy completely. Continue reading “Using sabotage to improve”
The whole thing was arranged in less than a month and, apart from some VC hiccups, ran remarkably smoothly with some good feedback from the 100+ attendees.
So what made this work, both in getting it organised and in the event itself? The organising group sat down and tried to work it out.
Earlier this month I was invited as a panelist to the Engine Room conference here at the FT. As I spent last year exploring BDD practices as a product owner with the development teams, I was there to contribute on the automated testing panel. I decided to make it a full day and stayed in the audience for all the five panels. I expected a day of in-depth conversations around technical tools and engineering practices. I came prepared for that I might not understand even half of the details, but hoping to catch up on the latest trends in FT Technology. My expectations were wrong. Most of the discussions centered around what we build and how we manage our product life-cycle and as a product manager I found myself right in the middle of the action!
After a great day at the conference I wrote up my impressions from the panels and from discussions throughout the day. This is a (slightly edited) note I sent to Product Management at the FT. Perhaps there are thoughts you will find useful!
Here at the FT we have been trialling a new method (at least for us!) of beginning a software development project. Essentially, the entire team (developers, testers, product owners) assemble in a room with the aim of producing a quick and dirty prototype based off a given value statement. We also invite people from other teams who have an interest in what we’re about to do: either they’re going to use the functionality we are developing or they need to provide us with something for it to work. We call this a QuickStart session.
The idea is that we learn about complexity to a good level of detail early on, allowing us to provide reasonable, evidence-based estimates to the business.
“The automation tests are passing at around 80% so I think we’re good to release”
We’ve heard this expression before and it doesn’t bode well. We release code into the production environment and within a few days a new defect is reported.
“How did this get missed?” asks the editor.
We have recently experimented with some dev-first approaches for some distinctly different scenarios
- riffing on a specific theme; generating and exploring lots of ideas quickly
- starting a tech-architecture-heavy project
and were very happy with the outcomes.
tl;dr The essence of both approaches is
- get the core group sitting in the same room for a day (Co-location is great. Who knew?)
- dump all possibly relevant information into the mix at the start
- let the developers have a play
- see what happens
What follows in this post is a more detailed look at the approach we took for …