There’s a lot to approve of in this Agile post by Mario Moreira, saying that we shouldn’t confuse short iterations of shippable code with rushing to get something out just for release sake. You see posts like this a lot from evangelists of the framework, because you never want to swing the pendulum the other direction:
“Building the wrong thing fast is like driving a dragster that races off the motorway when the road twists and turns as they often do.”
The same can be said for topics like documentation, planning, and communication. When some take a class on Scrum, Lean, XP or any other Agile framework, it’s not a far stretch to change your thinking towards all three.
It’s just not practical to put out software with zero documentation and planning. You can’t over-communicate. Definitely can’t expect that slashing meetings will result in large projects out in a couple of sprints.
How do you find the balance?
It’s impossible to have a “one size fits all” answer for every company. Products without any legacy code or minimal support needs can get away with less documentation. Some teams get away without a grooming session, or a daily standup. There’s always customizations you can make to fit your needs. Wouldn’t be very agile without it.
When focusing on the speed of delivery, ask your stakeholders what’s more important: time, budget or scope. When that decision is made, you know how to write your go-to-market plan.
One last note: “fast” is always in the eye of the beholder. Just because your boss uses the word in a presentation, doesn’t mean his definition is the same as yours. “Fast” may mean a 3-month release cycle instead of six. It may mean a 6-month release instead of 12. Shippable code means it could be released, so don’t freak out when you hear it.
Chris Murman 