Small systems are more flexible and malleable; therefore, experiments are easier. Some experiments would work well, others wouldn’t. Because they would keep things small and flexible, however, it would be easy to throw away the mistakes. This would enable the team to pivot, meaning they could change direction based on recent results. It is better to pivot early in the development process than to realize well into it that you’ve built something nobody likes.
Google calls this “launch early and often.” Launch as early as possible even if that means leaving out most of the features and launching to only a few select users. What you learn from the early launches informs the decisions later on and produces a better service in the end.
The concept of activating the failover procedure on a system that was working perfectly may seem odd, but it is better to discover bugs and other problems in a controlled situation than during an emergency.
This is a shift in cloud native thinking: accepting that there are errors in production and forcing those errors to happen so you can fix them. It’s like avoiding that psychological trap we all get into: if we don’t acknowledge a problem it must not exist and fixes the problem. Computers don’t act that way – you can’t bury a problem – and humans don’t either, really. So, just force the issue, but in small, controlled batches to limit the blast range. Better you control it than something else making the negative effect larger and worse, most likely.
I would need numerous hands to count the number of times I have seen product managers and clients add scope to a release, horde bugs, or refuse to deliver an MVP because they thought the next release was the only chance they had to complete a feature. Just last week a friend of mine at a well-known healthcare company said:
“We missed the May release train, so we go live in December. And that means January because of holidays, so we’re just doing some extra stuff until then.”
As PPM Leaders how can we expect other’s to deal with the profound organizational changes that will be required by life in the digital age if we aren’t willing to show the way by changing our own ways of doing things?
The second thing required of us on the road to achieving agility is a willingness to lead others through the change we ourselves have committed to.
In order to exploit being outside the EU, the UK may choose to lower corporation tax – currently at 20%, compared with 33% in France, and 12.5% in Ireland.
This, along with the potential for less regulations and more favorable anti-trust/monopoly treatment seems like one the biggest possible changes in tech with respect to the “Brexit.” However, cutting off easy access to staff (across all of the EU) might confound it all. Who knows, really?
During a media lunch Golub stated that approximately 25% of attendees at the conference had role titles associated with an operations/sysadmin function
What’s interesting here is that it suggests that the Docker community starts with developers, and builds to sysadmins. Which, pretty much, checks out with anecdotes.