Fixed Development Iterations and Releases
Andrew J. Peterson
NDP Software
What are Fixed Development Releases?
- Every two weeks a development "iteration" - releasable product with more customer value
- Every two weeks this iteration is "released", "pushed live"
- "Laws of Physics", no exceptions! Not "We'll try" or "The Goal"
- Predictable cycle for whole company
- Well-understood for whole company
Periodic Cycle
N - 1
Live
Iteration N
N + 1
Plan
QA
Live
Benefits, in general
- Provides regular planning cycle for everyone
- No meeting time discussing when to schedule releases and communicating decisions out. (These can be large.)
- Prevent misunderstandings
- Avoid difficult trade-offs between features, quality and release date
- Industry standard "Best Practice"
- Less stress
Possible pitfalls
- I can't demand things NOW!
- Too much process for us
- Release cycle doesn't meet business needs
- Lower-quality features
These are all addressable.
Demanding things now is very costly... doesn't work well for a larger business.
This is one of the most light-weight, but efficient processes.
Example: When Things Go Wrong
Development team says, "Feature X can't be done by code freeze."
Options:
- delay release
- scale back feature
- remove or delay a feature (this or another)
- lower-quality of feature
(Given: N = features + quality + time)
Delaying a Release... is Bad
It's tempting, but...
- Delay affects every feature of the release, not just the one that caused it.
- A "Should we delay?" meeting is costly
- Costly communication
- Puts everyone in a high-pressure situation, fostering bad behavior
- Another delay compounds the problem... pay again!
- Doesn't work when teams grow
A "Should we delay?" meeting is costly: it is often difficult to assess all the costs of a delayed release, which can be both internal and external. Trade-offs are often not easy
Costly communication. Must be communicated to every stakeholder of the release, not just stakeholders of features
If we don't delay
- must remove that feature (or another), scale-back, or push in feature in
- tends to be a more isolated, easier to understand decision
- can make clear feature vs. feature decisions
- Make trade-offs between user-facing features, not quality
- Easier to communicate to management when things go wrong
- Doesn't require lots of rescheduling
Benefits, for Developers
- Easier to plan work
- Easier to answer questions about when work will be done
- Easier to control for quality
- Can improve estimates through simple statistics (velocity)
- Fewer "fires"
Benefits, for QA
- Able to plan work
- Able to study quality and adjust resources and schedules accordingly
- Better able to predict and control quality
Benefits, for Product and Marketing
- Easy to know the current schedule (it doesn't change)
- Easier to make product trade-offs and prioritiziations-- see next slide
- Fewer "fires"
- Easier to communicate to management when things go wrong
Benefits, for Management
- Easy to know the current schedule (it doesn't change)
- Easier to control for quality
- Team more focused on optimizing business benefits
- Fewer "fires", and therefore better quality
Long-term benefits
- Finely tune development system
- Reduce size of queue, and promise feature delivery dates
- Less stress for employees
Where does it come from?
- Scrum
- Evolving best practices...
- Train metaphor