Bankloch

  When starting a new product , there is always a difficult question: how much should you build from the start? On one side, there is the MVP philosophy . Build only what you need, get it in front of customers, learn from their feedback and improve from there. Don’t spend months solving scalability problems for a product that might never have a scalability problem. Don’t automate processes before you even know whether those processes are the right ones. And don’t build a perfect architecture around requirements that will probably change anyway. On the other side, there is an equally convincing argument. If you already know something will eventually need to be automated , why build it manually first? If you know you will need APIs, scalability, proper monitoring and high availability, why postpone them? Doing the work twice is rarely cheaper than doing it properly once. Even worse, changing something later can become very difficult once customers are using it and depend on t...

A few weeks ago, I came across a heated LinkedIn debate on estimation in Agile. Some argued that estimation contradicts the Agile Manifesto altogether. The sentiment? Estimating is a waste of time - and possibly harmful. There’s some truth to this.   Estimations  often lead to: Micro-management tendencies Time-consuming rituals like Planning Poker and long Story Refinement sessions Inaccurate forecasts Shifting scopes due to changing priorities make estimations no longer relevant Padding estimates to avoid risk, rather than encouraging lean delivery But these critiques mostly apply within the microcosm of the scrum team. And that’s the catch: scrum teams don’t operate in isolation. Beyond the boundaries of a sprint board lies the rest of the organization - marketing, sales, documentation and training, customer communications, product launches…​ All these functions rely on the output of scrum teams and need time to prepare. Without at least a rough sense of what’s coming and wh...