Release Choo Choo
On a LAFABLE project, the Release Choo Choo is set in motion during the Planning Phase.
Residing in an ivory tower, positioned well away from the need to dirty his or her hands with code, a LAFABLE project architect is responsible for giving the team lots of unsolicited advice. If anything goes wrong on a project, the Architect is required by LAFABLE to side with the product owner and Stroll Master in insisting that if the team had just built what was specified, the project would have been a success.
In LAFABLE, the product owner is responsible for making all decisions about the functionality of the product. To do that effectively, it is important for the product owner to own all the resources involved in the project—human and other.
A team’s Stroll Master acts as a coach for the team—yelling and berating the team at every opportunity. Always acting with an eye toward continuous improvement, a good Stroll Master can find innumerable ways for team members to improve and is not shy about sharing these with them. The best teams are staffed by a Certified StrollMaster who participated in a grueling two-day course to earn that certification.
Developers and Testers
It is good to have at least a few developers and testers around so that the Product Owner and Stroll Master have people to boss around.
Backlog of Backlogs
There are so many backlogs in LAFABLE that the team maintains a backlog of backlogs just to keep things straight.
The product backlog contains everything the product owner demands be in the product. If a feature is not in the product backlog, LAFABLE rules prevent the product owner from yelling at the team about not getting that feature. Fortunately, another LAFABLE rule allows the product owner to add to the product backlog at any time, including right before yelling at the team.
Team’s Delivery Date Estimate
The team produces a date estimate range of when the product will be finished. This estimate is produced solely for the amusement of stakeholders and external management. No one pays any attention to it.
While paying lip service to having the team estimate their own work, the business stakeholders lock down a due date based on desired functionality, whim, and a disconnect from reality. Out of respect for developers’ and testers’ time, they are not consulted to create this estimate.
A deadline for the project is published. Deadlines in LAFABLE are most commonly selected by taking the team’s expected finish date, halving it, and decreasing the unit of measure. In that way, a team that expects to finish in 4 months will be given a deadline of two weeks.
Release Choo Choo
During a project’s strolls, the Release Choo Choo is picking up steam and rumbling down the tracks.
The Team Backlog contains all the items that must be finished during the Stroll. A Team Backlog is created by the project’s Tech Lead who assigns tasks out to other team members while personally retaining the best, most enjoyable tasks.
To avoid difficult to manage shared responsibility, each team member has a Personal Backlog of tasks that he or she is personally responsible for. If a team member does not finish all items on his or her Personal Backlog, the team member should not expect help from other team members who are expected to instead jump ahead to work for the next Stroll.
Building on the success of pair programming, LAFABLE incorporates pair managing, in which each developer or tester is watched by two managers. With two pairs of eyes on each task, it becomes extremely unlikely that an opportunity for micromanagement will go unnoticed.
Definition of Mostly Begun
Each team establishes a Definition of Mostly Begun. A task cannot be said to have begun until it complies with this definition. A typical definition of mostly begun includes:
- Developer has had morning caffeinated drink
- Developer has read favorite internet morning news site
- Developer has heard of the task
Once these things are complete, the developer is able to report in a daily standup that work on the task has begun.
Definition of Done on My Machine
Once a developer has seen a feature work even once on his or her own machine that feature may be reported as “Done on My Machine.” In LAFABLE, senior developers are held to a higher standard and cannot report something as Done on My Machine unless it has worked multiple times on their machines.
Definition of Mostly Done
In order to avoid communication problems, LAFABLE teams establish a Definition of Mostly Done. Once an item is Mostly Done, it is often deployed into production use. Doing so engages users in the testing process. Making users feel a part of the process is more important than giving them high quality features and so the product is delivered to them well before it should be.
Definition of We Really Mean It’s Done This Time
Finally, functionality reaches a state where the team really means it’s done this time. Really. They do. Except the testers have not touched it yet. That happens in Stabilization.
Testers Get First Look at the System
After all Strolls are complete, it is time to involve the testers. In LAFABLE, all testing is done during a lengthy Stabilization phase. Don’t worry, though, it’s not that lengthy. LAFABLE rules dictate that teams spend no more than half the time required to find and fix all defects, ensuring you beat your competitors to market with a low-quality release.
Product Owner’s Hidden Agenda Backlog
LAFABLE teams are told to “embrace change.” A product owner ensures a team’s ability to do this by deliberately holding some requirements back to be introduced later in the project. By introducing important functionality and architectural changes late in a project, a product owner can keep a team prepared for change at any time.
Because the written word is subject to interpretation and because all communication on LAFABLE projects is written, the product owner, Stroll Master and team members engage in a three-way battle. At stake is ownership of the intent of various statements in a document. Whichever group wins this battle and owns the intent will be able to say to others, “Well, I see how you could interpret this requirement that way, but let me assure you that isn’t what it means.”
Rapid Descoping Phase
The important, final phase on a LAFABLE project is the rapid descoping of all features that could not be delivered in the ample time provided to the team.
Release Choo Choo
During the Stabilization phase, the Release Choo Choo is shown to be a train wreck.
Train wreck! The Release Choo Choo goes off track, sliding off the top of the product backlog and crashing into reality.