There are two parts to speed:
- The human experience of things feeling slow or fast.
- Things actually being slow or fast.
Things feeling fast is about friction. When you’re doing all the day-to-day activities of software product delivery, does it feel like everything is smooth, nothing gets in the way, everything makes sense? Or does it feel like the world is fighting you, like no past design decision makes any sense, like you’re shaving yaks all day just to make any kind of progress?
Software product delivery feels fast when:
- Goals are clear. It’s clear what you are trying to accomplish and your team is aligned around how to accomplish it.
- Any information you need is readily available. For example, if you need to talk to a subject matter expert, they’re nearby and readily available.
- Systems and tools you depend on make sense and are easy to use. For example, programming languages, development environments, APIs, libraries, components, services, communication tools, how you track work, etc.
- Any administrative, non-value adding activity is minimised. For example, time tracking, performance appraisals, estimation, etc.
However…
Whether software product delivery is actually fast or slow tends to be less about friction and more about larger scale issues around how the overall system of software product delivery is working.
Being fast in software product delivery is about the design of the delivery system.
Software product delivery is fast primarily when:
- The entire organisation is focused on a limited number of important initiatives and not trying to do everything at once.
- Initiatives are broken down to smaller pieces (aka small batch size). People don’t try to deliver everything at once.
- Coordination is effective. That is, people synchronise expectations before starting any kind of effort that has large interdependencies rather than just assume alignment AND then continue to synchronise regularly.
- You have back-up options for any capability that is risky to deliver in order to prevent schedule collapse. If a risky solution fails, you don’t have to delay delivery for dependent stakeholders because you already have a plan B ready.
