Considering "2-6-4-1"
Considering "2-6-4-1"
My humble thoughts on John Cutler's take on "Shape Up!"
Introduction
This article from John Cutler introduces a very interesting engineering lifecycle concept called "2-6-4-1." Essentially, the idea is that the team does the following for each iteration/sprint:
Spend 2 weeks doing research and discovery
Spend 6 weeks getting something out to customers
Spend 4 weeks iterating on feedback
Spend 1 week tying up loose ends
The requirements for success using this method are:
Don't get distracted by other work for more than 15-20% of the time;
Insist on limiting interruptions and unnecessary meetings;
Normalize waiting (or "slack") time
Be transparent regarding progress on a daily basis and remove blockers ASAP
Make sure everyone knows we're just experimenting!
My Take
As with a lot of methodologies out there, the pure theory of it always sounds great, but in practice, the Real World often gets in the way. What I like about this concept is that the Real World is indeed baked in.
Another interesting thing I'm observing is that on the surface this has the feel of Agile, but on the inside it is almost like Waterfall but dramatically sped up.
It’s Like Agile
Many of the requirements for success that John Cutler presents I've observed in Agile (and even preceding methodologies such as Extreme Programming) going back decades. Focusing developers on a single project with minimal distraction is crucial for "deep work." I can't tell you how many times I've had to chase away stakeholders from scheduling incessant meetings for "status" because all they're doing is interrupting the team from solving the Big Problems.
Baking in "slack" time is also crucial. I remember the standard we had on the first Agile project in which I was a developer: in the Kanban board in TFS, it was pre-ordained that developers had 6.5 hours of time for project tasks per day, not 8 hours.
Being transparent with progress is something I am a big fan of. In the Waterfall lifecycle, often developers are given a huge amount of time to write their code with little oversight or, perhaps more importantly, support. By both visualizing work (such as with a Kanban board) and having daily standups ("What did you do yesterday?", "What are you doing today?", What are your blockers?"), we not only provide all of the "status" that stakeholders need, but we also are empowering the developers to provide results on a quick iterative basis and ask for help if they need it as soon as possible.
It’s Like Waterfall
Yes, it's like Waterfall, but I mean that from a place of love. In Waterfall, we have phases for business requirements gathering, technical design, development, testing, and user acceptance. Here, we're essentially doing the exact same thing, just in a quicker iteration, and repeating it as many times as necessary.
This helps to justify that many of the concepts in Agile and Scrum that we hold near and dear in theory actually often need to be adjusted in the aforementioned Real World.
Conclusion
The "2-6-4-1" Method is a great adaptation of what is found in the book "Shape Up!", and it reminds me quite a lot of what my boss John Proffitt instituted with our GX Foundry team. It acknowledges the Real World disadvantages of pure methodologies and encourages teams to really think outside the box and figure out what iterative technique works best for them. I would be very interested in experimenting with this one, though I bet we'd have to change it after the first go-around. Maybe you'll hear me talking about a "3-5-5-1" method or something in the future!