LAFABLE: How to Scale Agile without All the Pesky Changes

Posted in Agile, Scrum, Planning, Estimation, Leadership, XP, Management, and Musings - 0

Train TopScaled Agile Framework (SAFe), Disciplined Agile Delivery (DAD), Large Scale Agile. Nowadays, there are more ways to scale agile than there are to skin a cat. Which approach is the best?

I’ve tried them all. Or so I thought. Then, one of my customers introduced me to a new scaling agile method called Large Agile Framework Appropriate for Big, Lumbering Enterprises , or LAFABLE. I was intrigued, so I decided to do some research. First, I spent time with my customer, watching how they integrated the various parts of Scrum into their company, and the changes they made to ensure success. What I found was a delight. Let’s dive into LAFABLE.

Each LAFABLE project begins with planning. Now in Scrum, the team estimates the product backlog and the product owner selects a date based on this estimate and the team’s velocity. LAFABLE is similar. The team, along with the architect and Stroll Master (like a ScrumMaster, but different), select and publish a date and the scope to be delivered. Then, the company leaders take that published date and cut it in half. This way the business is able to meet its commitments and the team is able to deliver the software, which they originally estimated would take three to six months, in half the time. Brilliant! After seeing it in action, I was ashamed I didn’t think of it myself. 

After planning comes the Release Choo Choo. As the Release Choo Choo lumbers down the tracks, the team begins Strolling, which is where the work happens. The team members work with two backlogs, the team backlog and their personal backlogs. It’s critical in LAFABLE projects to have the personal backlog, because this enables management to track personal tasks. It also ensures that the team specialists, like the developers, are focused solely on development work, leaving the testers to focus on their own tasks. This robust framework also includes many definitions of done:

  • Mostly begun
  • Done, meaning it works on my machine
  • Done, meaning it’s mostly done (for example, maybe testing has not started)
  • Finally Done, which typically means it builds and is ready for checkin

As the Strolling phase comes to an end, LAFABLE moves to a Stabilization period. This is where testers can officially look at the code that is done, well mostly done, and start building tests for it. The Release Choo Choo keeps lumbering down the tracks, and at the right time, the Product Owner releases the surprise work that the team must cram in at the end, typically in the form of a hidden agenda backlog. This is usually the first time the team has seen this, but that is OK because that is what Stabilization is for. This causes the team and the product owner to fight, and the product owner then starts dumping not only the hidden agenda backlog, but also the other features that testing deems not really done. 

LAFABLE is a great solution for the large organization who is trying to scale Agile. It retains most of the Agile vocabulary but allows the business to stay aligned to its normal operating procedures, which is easier for everyone because there is no real change.

LAFABLE will ultimately get you what you want, a Release Choo Choo that has gone off the tracks. The benefit? You find out at the end of the line.

Read more about LAFABLE here. (and happy April Fools Day!)

Train Bottom