6 week cycles instead of frequent meetings

Recently I came across a book named Shape Up by Ryan Singer (https://twitter.com/rjs) about product development teams and strategies.

The more I’ve started reading it, realized that most of the painful problems are real. Solutions mentioned in the book can be followed at the larger scale. In this article I’m not gonna review the book but will focus on the problems faced by me.

To start with personally I really felt these two things as the team grows. Or I can say when I work for very long time in a single project.

Team members feel like projects go on and on, with no end in sight.

Founders ask themselves: “Why can’t we get features out the door like we used to in the early days?”

In this case I even ask myself “Why can’t I work like I used to in the early days”. After reading this book, I realized that everyday stand up or agile meetings are too frequent and mostly we share the same status on the tasks. With WFH in place, as a developer I spent at least 4/5 hours a day in meetings and this everyday standup does not help at all.

Pointless meetings

Six-week cycles is something we might aware of but never followed correctly. In this book this 6-week cycles were recommended and I really feel this will help any agile team.

First, we work in six-week cycles. Six weeks is long enough to build something meaningful start-to-finish and short enough that everyone can feel the deadline looming from the start, so they use the time wisely. The majority of our new features are built and released in one six-week cycle.

https://basecamp.com/shapeup/0.3-chapter-01#six-week-cycles

Our decisions are based on moving the product forward in the next six weeks, not micromanaging time. We don’t count hours or question how individual days are spent. We don’t have daily meetings.

https://basecamp.com/shapeup/0.3-chapter-01#six-week-cycles

Programmers or any individual sometimes used to have few off days in which we cannot do any meaningful progress. Reasons can be anything but this frequent daily meetings make it worse. Because I need to update something to the team.

My personal take from the book is it is good to have status meetings when required but not everyday.

I figure out there is something we already following from the book (good things).

Making teams responsible

https://basecamp.com/shapeup/0.3-chapter-01#making-teams-responsible

Instead of manager or equivalent people handling everything, small team have the full responsibility of the application. This will give the scope control to the programmer and one can feel the ownership of that task and follow up with the consumers without hesitation.

This is just the beginning part of the book and I feel this is a good read for not only for managers but even if you’re an individual contributor and like to manage your time better.

Shape Uphttps://basecamp.com/shapeup/webbook

Published