Taking agile, a process otherwise optimized for small, cross-functional, collaborative teams and making it work at scale is fascinating. You have to change some elements, and retain others, as you redefine the context. Being outcome driven, is one element you must retain – or even elevate in importance, or you fundamentally break the system of delivery
Being “outside-in”, “outcome-based”, and “market-driven” is particularly important for creating successful products. The problem is that just saying the words is not enough to help someone shift their thinking. For those of us who are already thinking this way, the phrases become touchstones or short-hand. For folks who are not there yet, these may sound like platitudes or empty words. I know many people who want to switch their roles from “do these things” to “solve these problems.” They have to change their organizations. This example may help get the point across.
Your boss wants a commitment. You want to offer a prediction. Agile, you say, only allows you to estimate and predict – not to commit. “Horse-hockey!” your boss exclaims, “I want one throat to choke, and it will be yours if you don’t make a commitment and meet it.” There’s a way to keep yourself off the corporate gallows – estimate, predict, and commit – using agile principles.
This is an article about agile product management and release planning.
Agile values working software over comprehensive documentation – it is 1/4th of the original manifesto. That doesn’t mean don’t document! It means don’t document more than you need to document. Documentation does have value, but the practice of documenting got excessive – that’s why a reaction to the bad stuff earned a spot as one of the pillars of agile. How do you avoid over-reacting when changing a culture of over-documentation?
Each requirement you write represents a single market need, that you either satisfy or fail to satisfy. A well written requirement is independently deliverable and represents an incremental increase in the value of your software. That is the definition of an atomic requirement. Read on to see why atomic requirements are important.