Running in Circles
Agile started off as a set of values. As agile spread, what spread wasn’t the values but the practice of working in cycles. So cycles became “sprints” and the metric of success, “velocity.” But speed isn’t the problem. The problems are doing the wrong things, building to specs, and getting distracted.
Deliberate resource allocation
Allocating resources means dedicating resources
- Whoever allocates the time and money to build a feature must also protect the team so they can do what was asked
- Only management can protect attention
- Tell the team to focus only works if the business is backing them up
It takes a whole business to ship
An “agile” team isn’t going to get very far if management doesn’t protect their time
- Designers and developers can learn the uphill strategies from Getting Real to gain certainty instead of crossing their fingers
- Whoever sets requirements can give teams the room to push back in the uphill phase
Mutable requirements
If a team works to a spec, there’s no point in iterating
- The purpose of working iteratively is to change direction as you go
- Separate the core concept from the periphery
- Some things are essential and other things are not
- Give teams low fidelity hand-drawn sketches when a cycle starts and spend more time on motivation than the specifics of design and implementation
Uphill Strategies
Work that requires problem solving is more like a hill. There’s an uphill phase where you figure out what you’re doing.
- The uphill work is full of false steps and circles and dead ends. It’s where you encounter the unexpected. The only way to gain certainty is to roll up your sleeves and engage with the reality of problem.
Comments ()