Fake Sprints

Fake Sprints

Anyone who has done software development has heard the term agile or waterfall. Why do we do scrums? What is agile? These are questions I have been having my second or third year as a software developer. However, I do see one fallacy and these are sprints masked as waterfalls. This is a summary on my interpretation between waterfall and agile, what I mean by sprints masked as waterfalls, and my belief of a true scrum cycle.

Waterfall

Waterfall reminds me of the floppy disk era. Imagine a conveyer belt where engineers are at the end, executives and product managers at the front, and designers in between. Waterfall attracts business owners as it provides a specific date with a fall back plan. The head of the teams figures out how utilize all teams at maximum capacity in parallel, based on estimations and blockers from subordinate leaders. The managers provide these estimations with padding expecting delays from upstream and mishaps.

When planned right, waterfall method is very effective. The teams communicate frequently focusing on the delivery date. They are not afraid escalate or call out when the estimation is off and require adjustments. However, waterfall is less popular among engineers as we are at the end of the spiral. Asking for couple of weeks when the deadline is next week is non negotiable. While everything from upstream not only has to meet the date, but specs have to be 100% accurate from the initial plan. This lack of negotiation power and huge reliance from upstream we are either promising more than we expected or take the blame for missing a deadline.

On the other hand, Kanban provides us to focus on our task with no deadlines.

Kanban

When I think agile, I imagine a Kanban board with post its. Engineers pick up a task and focus to deliver, and repeat. When the backlog is empty (does it ever get empty?), engineers dedicate their time creating more tasks and repeat. This puts the engineers away from the end of the spiral, and the team just needs to focus on prioritizing and completing what’s on the wall.

Unfortunately, a lot of engineering projects are not open source project. Investors, stakeholders or marketing demands a date. These dates are meant to communicate with customers and develop future plans. Further, we are in a competitive market where dates are as important as the functionality. This is where our sprints surfaced, where teams decide to set short objectives on a smaller wall.

The compromise: Sprint-like waterfalls

Scrum contains four rituals: stand up, planning, grooming and retro. What I have experienced is there are many teams who consider them as “agile’” by having these four rituals on their calendar.

The two weeks iterative does make the team feel as “light weight iterations” and incremental victories, but it is no different than a waterfall if the team don’t dedicate time in analyzing why the team is has missed their task and adjust the next week plan.

Some teams focus on filling the two weeks to full capacity with “days” estimation. Where analysis of these estimations are arbitrary and never revisited. These types of scrum cycles are even worst than waterfalls.

Waterfall at least acknowledges the mishaps and bugs, and creates padding. It’s a rare incident to witness a smooth development cycle. But somehow, when some teams plan for two weeks that necessity for padding disappears. The worst part is when a story gets punted, and the team assumes that this is part of the plan, neglects to reevaluate timeline until it is only a few sprints away. If your sprint has a habit of not punting task constantly, I highly suspect this is a team which masks a waterfall as a sprint.

Sprints: Iteration, improvement and velocity

How can a team feel confident about making a deadline in 5 months when they can’t even guarantee what we promised in two weeks?

There is one core piece that is essential to be considered as a sprint. This core piece is the team velocity: the number of complexity points a team can manage. Velocity is the indicator of how confident a team or an individual can deliver their items in a sprint. How distracted the team is with bugs and other administrative tasks, i.e. training, recruiting. This is the data point to make a decision in refactoring, build better tooling, or necessity of reassigning engineers focuses. The team must focus in completing what they promised instead of filling it to full capacity. The team needs to build confidence and focus on meeting small iterative deadline and build trust on their ability to deliver.

Sprint grooming is to give a speed for a task, sprint planning is to experiment the team’s velocity and sprint retro is to review the experiment and validate how accurate the planning was. The iteration is focused in velocity: was the story estimation accurate, what caused the delay, does the velocity match a deadline, how can we invest to improve the team’s velocity. This velocity provides leadership data points in estimating a larger project.

Conclusion

Sprints are meant to be iterative and modifiable with no absolute “right” way. However, the constant iteration based on team’s preferences and measuring velocity is essential. My next piece would be writing about my work experience in my previous company’s sprint rituals. This sprint ritual was the strictest I have ever seen. The approach was difficult to adapt, and very time consuming. However, I would like to write about it as the strictest rituals does answer what and why these rituals were meant for and how we were able to manage and analyze our velocity.