Our systems always depend on other systems and services and thus may and will be subject to failures – network glitches, dropped connections, load spikes, deadlocks, slow or crashed subsystems. We will explore how to create robust systems that can sustain blows from its users, interconnecting networks, and supposedly allied systems yet carry on as well as possible, recovering quickly – instead of aggreviating these difficulties and turning them into an extended outage and potentially substiantial financial loss. In systems not designed for robustness, even a minor and transient failure tends to cause a chain reaction of failures, spreading destruction far and wide. Here you will learn how to avoid that with a few crucial yet simple stability patterns and the main antipatterns to be aware of. Based primarily on the book Release It! and Hystrix. (Presented at Iterate winter conference 2015.)
From time to time I stumble across customers that ask me: – Can’t we just build a “Google search”? Or: – We need to develop new products with great user experience faster!
Increasingly over the last decade the world has experienced new products and business models popping up all over the place. They challenge the established players – and often win in the contest of customer engagement.
In the meantime our clients (large organizations) come to us and ask us to help them improve – and speed up – their product development process (they rarely ask us to help increase customer engagement or earn more money). They often refer to the Lean Startup process.
It seems to me that someone has mistakingly interpreted the fact that new successful products are popping up faster than ever due to approaches like Customer Development and Lean Startup. The main reason is actually due to cheap distribution and available technology that enables almost anyone to compete with anyone – on a global scale. Building a product is easy. Anyone can do that in 2015.
Customers sometimes expect us to do this: – Can you teach us Lean Startup – to reduce time to market for a new product – and reach sustainable new revenue faster? This is however where we easily get things wrong. The fact that Lean Startup makes us learn faster doesn’t necessarily mean reducing time to market (we charge early customers to validate ideas, not to make money). In order to create sustainable new revenue we need to solve real problems and excite our customers. That is hard.
This is how the Lean Startup brings value to you:
- reduce cost
- reduce the risk of making a bad investment
- increase our chances of building something our customers want (to pay for)
But we cannot guarantee reaching break even twice as fast.
To illustrate my point I have combined the “Crossing the chasm»-illustration from Geoffrey Moore with the process of building a Lean Startup.
How fast should we expect to reach the “chasm” and fase our biggest challenge yet of getting into the mainstream? How do we know if we have successfully crossed it?
What is your criteria for starting to invest and scale your product, service or business model?
I had this idea that I wanted to develop, but as entrepreneur and Lean Startup practitioner I immediately faced an inner conflict:
If I was to do as I preach, I should on the very first hour begin by exploring the world of potential customers. What I felt like doing, was to start programming. Under excuses like “I’m also doing this to learn a new web framework” and “this is just a hobby project”, I chose the latter. If nothing else, I also decided to pay close attention to my development process and how it evolved. I even promised myself I’d write about it, so here we are.
My customer segment is newbie textbook authors and novelists. I assume they have the following problem: Writing a book is a solitary process. I know this to be true for at least one person in the entire universe.
In other words, like the 37signals guys, I’m solving my own problem. I’m well enough into Lean Startup and entrepreneurial thinking to know I shouldn’t be working like an author – in solitude – so I have a few users in play (and they have already given me valuable feedback).
Apart from learning a new web framework, I’m also realizing something about the Lean Startup: I think I may even have found a silver bullet.
Let me explain.
We don’t foilware our work anymore, sorry, but no can do.
Instead we have turned ourselves into The Iterate Garage Enterprise Edition. We are the Action Team that builds new revenues, shares knowledge and lives in a tornado of learning loops in the commercially harsh and real world together with billion dollar corporations. When we are wrong, we learn and create the next iteration of ideas based on reality and live “build – measure – learn” loops.
Consultants have turned into product owners, customer journey specialists, prototyping artists, brand managers, experience designers, business developers, business model architects, or a combination of the above. Developers sit side by side with product owners and experiment designers.
Our managers have been turned into Experiment Designers, CEOs, Chief Commercial Officers, Head of Customer Voice and Chief Corporate Entrepreneurs.
We build and we cry – we build and we laugh – we build and solve real peoples problems.
And we love it.
I am a serial entrepreneur focusing on innovation in large enterprises and I head The Iterate Garage Team.
“Want to learn more about how Lean Startup worked for other established organizations? Sign up for free Lean Startup School!”: http://info.iterate.no/lean-startup-skolen/ (in Norwegian)
Cross-posted from The Holy Java.
Credit: Dennis Jarvis, CC
Are you tired of days spent in front of the screen, with no results to show? Have you once again engaged in yak shaving? Today, after having failed previously, I have finally managed to solve a problem while avoiding this trap by following rigorously two guidelines preached by grandmaster programmers. Be warned: Following this approach, you will get a working solution – but you won’t like it. It will be ugly, stained by compromises, far from the elegant solution you wish for. But if your resources are limited and you want to avoid death by too many yaks, this is your only option. But first, what are these guidelines?
One: Maintain a laser-sharp focus. A great programmer is constantly aware of what she is trying to achieve and never strays far from it. If the path leads away, she backs up. If something else pops up, she writes it down for later and gets back to the job. This is essentially about deciding what not to do. (Many thanks to Kent Beck for sharing his focus secret!)
Digest of chapter 9 of the Continuous Delivery bible by Humble and Farley. See also the digest of ch 8: Automated Acceptance Testing.
(“cross-functional” might be better as they too are crucial for functionality)
- f.ex. security, usability, maintainability, auditability, configurability but especially capacity, throughput, performance
- performance = time to process 1 transaction (tx); throughput = #tx/a period; capacity = max throughput we can handle under a given load while maintaining acceptable response times.
- NFRs determine the architecture so we must define them early; all (ops, devs, testers, customer) should meet to estimate their impact (it costs to increase any of them and often they go contrary to each other, e.g. security and performance)
- das appropriate, you can either create specific stories for NFRs (e.g. capacity; => easier to prioritize explicitely) or/and add them as requirements to feature stories
- if poorly analyzed then they constrain thinking, lead to overdesign and inappropriate optimization
- only ever optimize based on facts, i.e. realistic measurements (if you don’t know it: developers are really terrible at guessing the source of performance problems)
A strategy to address capacity problems:
These are my rather extensive notes from reading the chapter 8 on Automated Acceptance Testing in the Continuous Delivery bible by Humble and Farley. There is plenty of very good advice that I just had to take record of. Acceptance testing is an exciting and important subject. Why should you care about it? Because:
We know from experience that without excellent automated acceptance test coverage, one of three things happens: Either a lot of time is spent trying to find and fix bugs at the end of the process when you thought you were done, or you spend a great deal of time and money on manual acceptance and regression testing, or you end up releasing poor-quality software.