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.

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.

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.

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.

There are so many backlogs in LAFABLE that the team maintains a backlog of backlogs just to keep things straight.

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.

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.

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.

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.

Release Choo Choo During a project’s strolls, the Release Choo Choo is picking up steam and rumbling down the tracks.

Team Backlog 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.

Personal Backlog 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.

Pair Managing 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.