After a period of time the Development Team found that no matter how the work was planned or divided, there was almost always an over-run. Estimates of two or three sprints became two or three months. Deliveries were late, features were cut, opportunities were missed. The quality wasn’t always that great either. The Product Team was not happy.
There seemed to be a culture of:
- Everything must be perfect
- Poor alignment with Product Team expectations
- Not finished? Never mind, we’ll carry on next week
After a natural slimming down of the Development Team from twelve to six developers, it was time for some hard thinking and some serious change.
The Development Team decided there were no sacred cows and that they should challenge the things they took for granted.
- Why two-week sprints?
- Why does the Operations Team need to deploy our product?
- Do new features have to be deployed “big-bang” fashion?
- Does everything have to “perfect” before deployment?
- Can the Product Team give feed-back during development?
- Does fear of failure paralyse the work?
The Development Team decided to work in one-week sprints.
These alternate between Feature and Engineering Weeks.
Feature Week – A direct request from the Product Team
Monday stand-up, the team is presented with the challenge(s) by the Product Team and these are discussed to ensure the Development Team have a good understanding of what is required.
Monday morning, the team plans its Day 1 / Day 3 and Day 5 goals.
Day 1 “The Feature Request”
This generally involves communicating with the Product Team what will be delivered. Sometimes the Feature is just too big for one week, so a sub-set that adds demonstrable value, and that can be subsequently built upon, is agreed as the deliverable.
Day 3 “Early Access”
This involves a demonstration to the Product Team. This provides the opportunity for feedback, tweaking, re-aligning (if the Development Team is misaligned with the Product Team) or as a last resort, canning it entirely due to changing business priorities.
Day 5 “Delivery”
The deliverable is demonstrated to the Product Team before the end of the day. This gives the opportunity for a final bit of polish. The finished work will be developed, documented and deployed to all environments.
The Development Team have delivered a number of complete features in a single week, as well as larger features spread over non-consecutive weeks.
Engineering Week – Prioritized engineering concern(s)
Monday stand-up, the Development Team selects prioritised engineering task(s). These may not be of direct interest to the Product Team, but they will have indirect business value e.g. reduce errors, reduce manual processes, reduce costs, improve performance, stability or supportability.
Monday morning, the team plans its Day 1 / Day 3 and Day 5 goals.
Day 1 “The Set-up”
This generally involves the Development Team communicating with the Product Team what they plan to deliver and why it adds “value” to the Platform or the business.
Day 3 “The Reveal”
A team demonstration of this week’s task(s).
Day 5 “The Knockout”
The task(s) are demonstrated, and the business benefits are highlighted to interested parties. By the end of the day, the finished work will be developed, documented and deployed to all environments.
Significant Engineering tasks delivered this way include:
- The Continuous Delivery Pipeline – reduces manual processes, reduces errors.
- Performance Improvements – load handling, scalability, error reporting, simpler diagnostics.
- Service Resilience – automatic service restarts, flagging unhealthy dependencies
- End to End Testing – Reduces errors creeping in
- Load Testing – baseline performance expectations
Cross Functional Working
The Development Team is in a constant state of communication with the Product Team so demonstrations and deliveries are not wide of the mark, and any issues blocking progress are resolved rapidly.
The Development Team also works very closely with the Infrastructure Team, bringing them in early at the planning stage when it is likely that the development will require additional infrastructure, make additional demands of existing infrastructure or will require assistance from members of the Infrastructure Team.
- Responsive – The Development Team could potentially be working on a new feature the next week. This means where a sale is more likely to be a success if we have some or all of Feature “X”, then this could be the highest priority of the Product Team.
- Less Wasteful – If it is decided that Feature “X” isn’t what’s needed or the opportunity has gone, or it simply isn’t what we thought was required, bin it. Only a week was lost. The Development Team will more than likely have learned something valuable along the way too.
- Flexible –Feature and Engineering weeks do not have to alternate. Priorities will determine which. The trick is to not let the pendulum swing too far in one direction.
- A week was spent prototyping a feature, the requirements changed, or the moment passed. It was dropped, then the Development Team got on with the next task. There was no baggage weighing them down.
- An old style big-bang feature. This went from a four to five week estimate up to about three months. It’s not a particularly nice feature and by the end it had to be finished by a hard deadline, so some functionality was cut, and overall quality suffered.
- Piecemeal – Sometimes there is an overhead getting back into a feature not recently worked on. This tends not to happen though, since anything left too long probably isn’t that important anymore.
- Using New Tools – It is essential that developers keep on top of their game. It’s all about beating the “other guy”. However, it can be risky to try something new during a Feature Week, unexpected issues could jeopardise delivery. The trick here is to reduce the commitment, have a Plan B or to create prototypes and do learning in an Engineering Week.
- Time Management – This is more important. Even a one-hour meeting eats into development time.
The Development Team and its processes were by no means shocking to start with. They had a green field project, continuous build servers, high levels of testing and controls on changes. None of these in themselves guarantees the production of the right things at the right time.
The short duration of the one-week sprint focuses the teams on the here and now, there’s no resorting to “we can do that next week”.
The mid-week demos get that essential feedback from the Product Team, the opportunity to correct direction and misunderstanding.
The finish at the end of the week means there’s the satisfaction of achievement and the new start every week.
Overall, the pace can feel like it is tiring (exhaustion would suggest over-commitment), but after nearly a full year of working this way, it’s the freshness of a new challenge each week, the ability to deliver evolutionary change and build on strong foundations that keeps it interesting and rewarding.