tl;dr: I’ve seen “agile” software development teams (2-8 in size) that took ~ 100 days to ship features to teams that ship everyday, at times with the same team members. This post is about the journey & ingredients of such teams in product orgs. Feel free to call out mischaracterization as you see suitable 🙂
The “once a quarter” team
This team generally has a cadence where it ships something “big” every quarter, typically 60-90 days. It has some version of biweekly planning with daily stand ups for updates. It does “estimation” as a means of de-risking projects, but given that it is shipping on a ~ 100 day cadence, it frankly doesn’t matter because it isn’t “learning” from the real world fast enough. In fact, a 100 day cadence results in slips, regressions, & all kinds of vicious outcomes that come with deploying significant chunks of code.
The tech stack for this team ends up becoming coupled. Members develop “expertise” in parts of the tech stack, and the interchangeability of members becomes impractical.From a process perspective, this team looks like a “once a day” team to outsiders.
This team feels good about their “lack of process”, feels that it is shipping “big meaningful things”, and celebrate big milestones in terms of output. These teams rely heavily on “opinions” and “experts”.
Generally, this team has poor outcomes despite “big milestones”, & painfully slow pace of validated learning about the world.
The “once a month” team
This team has adopted some version of SCRUM successfully. It is using “estimates” to determine how much it can commit to. The “tickets” are approximations of end to end value delivering features. The estimation ceremonies for this team is excruciating & dreaded by all engineers. The stigma of not meeting the “Commitment” is painful, and retrospectives can end up becoming an exercise in scapegoating.
While painful, the journey of a once a quarter to a once a month team makes tech stack as well as cultural challenges visible. Some engineers who were previously “experts” in parts of the tech stack start complaining, and some leave. The technical coupling becomes obvious, and the team starts to attack that coupling pulling apart the dependencies.
From a process perspective, this is the most process heavy stage in the evolution of a development team. This is what our journey from a once a quarter to a once a month team at Sefaira looked like.
It was troublesome and our team worked hard to maintain morale, despite obvious challenges. The best way to maintain morale was by showing our ability to ship faster.
Eventually, this team reaches a state where all tickets land in the same 2-3 days window towards the end of the sprint, which results in bottlenecking. Interestingly, the deadline of the sprint end date which served to impart urgency originally, now serves to destroy it. As this team reaches the cadence of the “once a week” team, there is “horse trading” in priorities. It takes a while for the team & business to understand how rapidly it can respond.
The “once a week” team
This team has adopted some form of “Kanban”. It has a lean backlog. The “estimation” done here is super lightweight (10 minutes for ~ 5 day estimate), and done mainly for learning about the health & awareness of the code base (if estimate is off, code is marshy).
This team pairs aggressively, and usually has no individual ownership of “tickets”. This team understands that it is driving certain outcomes (measured in some value delivered to the customer). Daily standups start to become less important. It reviews progress once a month, and reviews “failures” only when there is some major blow up (e.g. work takes 3x longer than expected).
The biggest change in this team is its shift from focus on meeting commitments to minimizing elapsed time.
Culturally, this team has very little scapegoating. While afraid of failing, the stigma associated with failure is low. This team’s pace of learning is also very solid. Such a team can reasonably go from idea to an incremental revenue generating feature in 1 month. The bottle neck at this points shifts other parts of the business (sales, marketing, etc).
The “once a day” team
This is the zen like state for a team. The talent, mutual trust, shared values, and goal orientation of such a team is self-reinforcing. This team is relentless in its pursuit of an outcome. This product team is more like a swarm than an individual. There is very little “individual ownership” but very high “collective ownership”.
For this team, there is very little separation between discovery & delivery. UX, Engineering, and Product attain mild-meld, and to outsiders, these teams are enigmatic. Outsiders don’t understand these teams. There is very very little visible process.
At this stage, the team’s culture & practice are in complete unison. You can feed these teams the greatest of challenges, and this team will annihilate it. This is a team Yoda would be proud of 🙂
So, ask yourself, where are you in this journey & will Yoda be proud of you? 🙂
Learn by Building 