Plans are useless but planning is indispensable.
Dwight D. Eisenhower
What goes up must come down. This is true of aircraft in flight. Bringing an aircraft back to the ground safely is the primary concern, but it also is necessary that the return to the ground occur at the intended landing point. The descent from flight altitude must be started well before the intended landing point is reached, and the rate at which the aircraft descends must be calculated, so that the aircraft reaches ground level just as it reaches the desired landing point. This controlled drop in altitude is called the descent rate.
Let us use these tips to learn how we can apply it for Agile development team.
The analogy here is very close…
Imagine team is a crew and airplane is the sprint, while burndown chart (CI, established NFRs, …) are navigation tools that allow to land sprint properly, with all passengers (stories) safe, at right airport (release) and on time (sprint review meeting).
So the crew must take into consideration many factors as altitude, distance to destination, aircraft descent velocity, weather conditions, fuel consumption, etc..
One of the key factors that allow to have successful landing of aircraft is choosing the correct descending point. You for sure remember that at some point you see “fasten your seat-belts” sign on and flight attendants start asking you to follow the “landing rules”. This happens not right before airplane lands but some time in advance…
Similarly Agile team must consider many factors to get things done on time with required quality baked in (number of stories in progress, time left finishing development, regression testing left, meeting agreed non-functional requirements, preparing for the demo, etc. ). And shall start finishing things in advance to guarantee proper “landing”.
How much in advance?
It heavily depends on variety of factors: team maturity and confidence, extent team can rely on automated testing (and extent product is covered with automated functional testing), need to check for non-functional requirements, all kind of risks, etc…
Sprint (Flight) Plan and Descent Point
I will bring real life example.
In a picture below team had planned sprint in the way to start checking product on development environment in advance (while possibly working on integration defects), then deploy it on staging environment the last day of the sprint to make required final performance/load tests, confirm release/deployment plan and test application closest possible to the real life conditions:
Part of this plan presumed that in case all is OK, free team members will focus on less priority bugs, increase unit tests coverage, prepare for upcoming sprint, focus on past retrospective action items and do other valuable things. While plan changed of course, reflecting changing reality leading team inspecting and adapting accordingly and team moved descent point according to the joint decision.
But there is still difference…
While airplane landing is an example of waterfall project with QA (hardening) phase in the end (landing), it’s still differs from Agile. The more you do Agile right the more your team is mature, your product is safe, having more quality in and things are more automated. The more you apply engineering practices and earlier you start integrating and testing things (continuously), the later you can start “landing” and the more passengers you’re capable to take (stories) and the shorter your “flight” will be (you will “Deliver Faster”).