Release rhythm is a hot topic for the team right now. Termed another way, the team is aiming at cheap, frequent, reliable releases. It doesn’t seem like it should be hard, but it is.
When I say ‘team’, I’m not referring to engineering and QA alone. I’m referring to the entire team consisting of scrum master, business, engineering and QA.
Shifting Priorities
Our business team has a worthy challenge. They’re armed with an ultra responsive engineering team and a raft of features which are aimed squarely at improving our site SEO and traffic monetization.
We have two week iterations, and oftentimes by the time we’re attacking the final couple of stories, the business priorities have shifted.
Features for the Short Term
With two releases going out per iteration, there’s a tendency to want to ‘squeeze’ stories into the coming release. Stories arriving late into the release branch are often rushed, trend high with defects, and create churn and uncertainty as we’re trying to ship our product. With regularity, it would seem, defects find their way to production.
It’s true that as the team addresses production defects and releases hot-fixes, our velocity for the iteration is impacted. Of course the overarching goal is to be responsive to change while minimizing atrophy through defect churn.
Dev Complete
In our retrospective today, the team engaged in a discussion about ‘dev complete’. It was interesting to observe the discussion, particularly as focus shifted to reviewing test cases, and considering the announcement of ‘dev complete’ to mean production ready.
Mature Code-Base
It’s true our code-base is mature. Over time, it can be difficult to maintain a focus on craftsmanship and constant improvement through refactoring. There were great retrospective items today, where we identified opportunities for refactoring in the context of user stories which had come to pass.
Our Defect Trend
Where To?
- I’m not sure how it only struck me now: should we consider one week iterations? What with those shifting priorities?
- Monitoring our defect trend will continue to be critical. We’ve only just started watching this metric in earnest, but surely it can only aid our focus on quality.
- Can added focus on the pivotal, story by story announcement of ‘dev complete!’ help? The team is sure hoping so.
- We’re planning to identify brittle parts of our code-base, and prioritize clean up accordingly. We in fact have one story in this vain in the current iteration. Will this help for the long term?
- Can we shift our expectations from a ‘feature squeeze’ mentality to a releasable feature set (planned in advance) mentality?
