The Need for Speed
Leadership, management, and engineering all recognise the need for speed; the need of a business to make money. Leadership feels this urgency and is incentivised to meet the customer’s needs through sales, thus keeping the business alive. Management is incentivised to drive product development to go ever faster to beat the competition. Engineering tries to solve the problem their way: produce more code more quickly! Yet many of us are left with the frustrating experience of watching our productivity trend ever downwards. Whether or not we have reports and metrics, we often feel that there’s something wrong. We feel like we should be going faster. How can this be?
Tech companies advertise the use of Agile in order to gain speed, yet engineers observe that work is piling up faster than we can deliver. The result: an ever-growing backlog we can see. We notice the problem and try various options to speed up, the latest of which are copilot tools and vibe coding. However, that doesn’t have the desired effect as AIs produce more code with more errors. We live in a world with tools to create an infinite amount of code, but how valuable is quantity with unknown quality? In fact, how valuable is any quantity?
This issue becomes obvious when we observe the whole system through the lenses of Lean Manufacturing and the Theory of Constraints. Lean identifies waste as anything which does not provide value to the customer, be that a bug or undesired feature. Therefore, productivity is measured by doing the right things, not lots of things. The Theory of Constraints tells us that the tightest bottleneck decides the throughput of a system. Therefore, we need to address the critical constraint in the pipeline. That’s usually in engineering.
The typical system of development yields enormous waste and exorbitant costs as we repeatedly spend time, money, and effort on things we don’t even know we need. We ship complex features, with lots of code, and provide ongoing support, thereby raising the effective cost of the business. Every time we release something unverified as needed, we add burden to the entire organisation in the hope that we find success.
Ideally, we want to pull what is needed from our limited pool of precious resources. We need some way to discover what we actually need to do. How do we know which units of work actually drive success?
How do we Know?
This one question cuts to the quick, separating fact from feeling. We are biased creatures who use feelings to guide our decisions on a regular basis - we “trust our gut”. As common as this phrase appears in conversation, it’s short sighted. Trusting our gut can be valuable, but its value pales in comparison to data. We can uncover this data and drive our learning. At Amplify, we have found a process to uncover the truth which directs our next steps. This process enables us to answer the question, “how do we know we are building the right thing?”
Validated Learning
Eric Ries identifies a critical unit of measure in The Lean Startup which determines business success: validated learning. The more golden nuggets of learning we have, the brighter the light on the path ahead. Validated learning is directly applicable from leadership’s zoomed-out perspective on strategy all the way to the zoomed-in process of our SDLC. We uncover validated learning in engineering by iteratively running small experiments on our code. We then discover the minimum set of required changes to meet the needs of what came immediately before, and experiment again.
The faster we learn, the faster we meet these needs.
Enter Easely, Stage Right
The Mikado Method is a process of experimentation and discovery (iterative learning), to select what is required (filter out waste, reduce operating expense), and systematically address the correctness of the feature (productive, valuable) with less code (reduce inventory), allowing us to ship faster (increase throughput). This process effectively trims out over-engineering at the start, thereby eliminating whole sets of engineering-led premature optimization (we don’t even know we are doing), which shrinks the size of each feature. You will discover how simple your solutions can be.
The Mikado Method is the core process inside Easely. We have taken the Mikado Method, supercharged it, wrapped it in a plugin, and embedded it into the IDE. The power is at your fingertips.
The speed of development with this process is directly related to the speed of discovering validated learning. This means the fastest way to increase productivity is to go through the loop of the Mikado Method as fast as possible. At Amplify, we know this to be true. Our primary goal with Easely is to shorten the loop as much as possible, enabling you to learn as fast as possible.
You can affect the right change, Easely.
