Testing in Agile: Never Again Say "Deadline"

Dealing with deadlines, stress and tremendous pressure; working overtime, shipping buggy releases on manager's orders (also known as "death march") - by now this should be a distant memory from the past. And yet, Agile teams still live in the world full of "deadlines".

Continue reading to explore the nature of constraints in Agile and learn how a team can establish their pace without ever being in a "time crunch".

After every release I sit down with each of my teams to talk about their recent experiences. Together we look at the artifacts and analyze them for anti-patterns. We discuss velocity, sprint burndown and review retrospectives. At the end the team comes up with a plan for the next release - what to pay attention to, what techniques to try, how to address dysfunctions. Every team is different and it's fascinating to see their successes and challenges.

Just recently I was reading retrospectives Team A created over the course of a release that consisted of eight sprints. One thing struck me as odd. Sprint after sprint Team A's "what went well" column mentioned how proud they were to have met the deadlines despite holidays (Christmas), weather (a few snow days in January) and resource shortage (vacations, sick days, maternity leaves). Sprint after sprint they said they had to go through a tremendous amount of effort in a short period of time to make the deadline. They suggested to make the sprint longer (three weeks instead of two) and ship fewer updates to the customers.

If I were an outsider reading the retrospective, I would think the team suffers from an acute case of command-and-control manager who sets arbitrary deadlines and turns releases into death marches. Except, this is not our case. The teams are completely independent in their sprint planning, PO sets the priorities, and the release dates are determined based on the team's sizing, velocity and sprint plans. Where did the deadlines come from?

To understand the phenomenon, let's talk about the history of deadlines. In the olden days of Waterfall, the requirements (scope) were outlined by Business early in the cycle and remained unchanged until the end of the project. The project timeframe was also set in stone first as an estimate and then as a final delivery date. This date was what we called a "deadline". Since Waterfall projects were big and long, the estimates and timeframes were typically determined by managers. They could have used input from individuals and teams, but at the end it was their responsibility. They were also personally accountable for the project to be "on time".

With two fixed constraints (scope and time), the only way to adapt to the changing reality was to leverage the third piece of the "iron triangle" - the resources. In Waterfall we managed people as numbers on spreadsheets. We could ramp resources up and down by moving staff around. With the deadline looming closer, panicking managers went into "all hands on deck" mode, which really meant this: "My head is on the line, I don't care who you are and what you are doing, drop everything and start helping, even if you have no idea about the product, and instead of helping you really just get in the way of people who are too tired and frustrated to care".

That's what we used to call the death march. Everybody worked overtime and around the clock, only to find more bugs and issues. Everybody knew the release was not in shape to be shipped, but it still did, because the manager said so.

Similarly to Waterfall, Agile planning triangle has two fixed and one variable constraint. That's where the similarity ends. In Agile, the resources are fixed, it's our team. The time is also fixed, it's our sprint.

The third (variable) piece is scope. It's created and prioritized by the PO, but then the rest of the sizing and planning is done by the team. The case we've been discussing earlier really goes back to the Team A's tendency to over-commit. They heaped their plate so high, they struggled to finish it by the end of the sprint. They felt like they were expected to deliver more, to grow their velocity, so they bit more than they could chew. Their "deadlines" were imaginary and self-inflicted, but they caused very real stress and compromised quality.

Thoughtful planning takes into consideration historical productivity (velocity) as well as fluctuations of Time and Resources. A holiday in the middle of the sprint will reduce velocity. Planned vacations and babies reduce velocity. These things are typically known before the sprint starts and should be considered in advance.

Unexpected things like sickness or family matters that require time off, reduce velocity too. When it happens, the team can simply change their initial plan and pull a user story or two from the sprint. North Carolina is famous for occasional extreme weather, every once in a while we get hurricanes, tornadoes or ice storms. When the weather happens and team members are not available - reduce the scope.

Changing the scope during the sprint is totally legitimate. It's absolutely the right thing to do when the team's capacity changes or the user stories turn out to be bigger than they seemed during sizing. The recipe to adjust the scope during the sprint is simple and has only four ingredients:

1. Priority - always start your sprint with the most important items (Critical and Major). Pull in stories prioritized as Average and Minor only if they can be completed by the end of the sprint.
2. WIP - never start working on an item that doesn't seem like it can be completed by the end of sprint. To learn more read this post: Stop Starting, Start Finishing.
3. DOD - when the team plans how many stories can be completed during the sprint, it should always be about the definition of "done", which typically includes functional and non-functional (performance, security, usability) testing, regression, automation, documentation, and such.
4. Visibility - communicate with your PO and stakeholders early and honestly. If something cannot be done by a certain date, it's not "your" problem. It's something everybody needs to address and resolve together.

Remember Team A? In their race for the "deadlines" the team missed another important aspect of their mission - to learn and improve. When you're always in "beating the deadline" mode, you use shortcuts. You only do what absolutely has to be done and skip the "non-essential" stuff like automation, learning and innovation. You do functional testing, but never have time to work on proper performance, security or load testing. You don't review and refactor, don't research, optimize, improve. You are too busy, stressed out and overworked, your sprint is too short, you become numb to the customer's needs. At the end you compromise the most important aspect of all - Quality.

And what about longer releases that absolutely have to be delivered on a certain date? The answer is still the same - plan realistically, communicate early, be honest and search for solution together with stakeholders and management.

There's no magic bullet.

Agile is not "faster" than Waterfall. It's more honest, realistic and transparent, but work takes as long as it takes. The only way to work faster than your normal pace is by letting the quality slip, crash and burn. Don't do this. Don't ever do this again. Don't get yourself and your team into the deadly trap of deadlines.

Please like and share with your network! Comment, share your thoughts and send me your questions, follow me on LinkedIn and Twitter to read my articles on practical Agile.