My exploration of “Starter Agile” practices through the lens of Joshua Kerievsky’s “Modern Agile” concludes with this final group of three practices: standup meetings, task decomposition, and cadence-driven retrospective!
Disclaimer: this is my favorite set of practices to critique! Let’s dive in!
Did you miss the prior 2 posts?
Part 1 explains why timeboxes, story points, and velocity are “Starter Agile.”
Starter Agile: Standup Meetings
Of all the practices in my gathering of “Starter Agile”, standup meetings might be at the top the list. Disclaimer of personal conjecture within: when it comes to the “daily standup,” there is no practice more widely forced on teams because, “that’s what Agile teams do.” Further, implementing this meeting requires no restructuring, infrastructure, or tooling; we can start immediately. Therefore, and perhaps unsurprisingly, the standup might also be the most misapplied practice in the whole Agile toolkit.
When I reflect on my experiences with teams using a ~15 minute timebox to check-in and set goals, the teams finding value with the meeting have always had two ingredients in place: a challenge requiring their collective minds (as opposed to individual tasks) and trust.
News flash: most organizations struggle mightily with the latter, making the former merely wishful thinking. Thus, I’ve observed a majority of teams that fall somewhere between the spectrum of apathy and vilification – from, “whatever, it’s fine” to “what a waste of time.” Add to the mixing bowl a healthy dose of ingredients to reinforce existing behaviors (status reporting, micromanagement, individual accomplishment to name a few) and you’re ready to bake a batch of “Starter Agile” cookies that no one wants to eat. The unintended consequences here run deep: peoples’ experiences with “daily standup” meetings can exacerbate the existing dysfunctions, amplifying problems to new heights and reinforcing biases.
“Modern Agile” highlights the importance of “psychological safety”—impossible without trust and respect—which lays the groundwork for an environment where teams can truly cooperate and collaborate. It’s here that a “daily standup” might be valuable in the context of “Starter Agile”, yet I’ll go further to suggest “Modern Agile” teams realize it’s unnecessary. As work becomes a team effort, conversations about progress, knowledge, and obstacles become a continuous, daily behavior – not answers to prescribed questions once each morning. Based on activities done yesterday, if team members arrived at work with shared understanding of what’s on tap for the day (and obstacles, dependencies, etc.), what value would a “standup meeting” have?
Starter Agile: Task Decomposition
One of the earliest shifts in behavior people undertake when experimenting with Agile is collective task decomposition, especially as part of a sprint planning ceremony. For many, collectively breaking down work to be done is a significant “win,” especially when compared to the isolated functional silos of many phased work systems.
When we break-down work together, we leverage the collective strengths of people to identify hidden risks and needs, plus transparency into the work itself – allowing team members to cooperate with greater ease. The practice reinforces the concept of a team-centric system of work and, theoretically, encourages a team to be self-organizing and determine how best to solve problems.
However, like most practices in the realm of “Starter Agile”, the potential benefit of task decomposition is often missed due to the ease of familiar behaviors taking over. In my experience, it is very common to observe “collective task decomposition” take the form of individuals breaking down their own work. Often it flows just like a traditional “waterfall”: the person with UI experience starts by stating his/her tasks, next the person with the most experience in the “middle” of the system will list tasks, while the “tester” waits until the end to suggest the same two tasks for every backlog item (“test plan” and “test execution”). Further, and perhaps just a part of human nature, I’ve observed that those who suggest the task(s) end up doing the task(s). Thus, unexpectedly, the practice of task decomposition can introduce a culture of plate-emptying within the team – inevitably creating a microcosm of the same bottlenecks and constraints that might have been the reason for experimenting with Agile in the first place.
“Modern Agile” teams work from the principle of “Experiment & Learn Rapidly” and are mindful to avoid silos of knowledge and technical deficiencies that come with weak collaboration. Therefore, such teams value a collective approach to work and often get started by jointly selecting a “small enough” increment, skipping tasks completely. Tasks emerge daily as the team cuts through the work together, possibly using social practices like pairing or mob programming. Else, in “Modern Agile” teams where solo work is common, you can be certain that code is integrated early and often, eliciting conversation and interaction. The takeaway here points to the discovery that we don’t need “task decomposition” to gain the benefits of task decomposition.
Starter Agile: Cadence-Driven Retrospective
This final topic is tricky. To be sure, describing retrospectives as a “Starter Agile” practice is not suggesting the act of inspect and adapt is antiquated or less useful. In fact, I’ve yet to observe an Agile team operating at a healthy, sustainable pace without a value for learning and retrospective. Perhaps total neglect for the way we work together can produce outstanding teams; I’ve simply never experienced it. Thus, the emphasis here is “cadence-driven.”
Retrospectives are an Agile-related practice that requires no new infrastructure, technology, or training for participants. Therefore, it’s unsurprising that retrospectives are one of the first practices teams are asked to try. Good intentions reign supreme: who would be opposed to finding better ways of working together? Yet this ease of getting started is often a curse, as the effectiveness of retrospectives tends to be highly behavior-driven. Without adequate time for the environment around teams to reflect Agile values and principles—and “Psychological Safety”—it’s common for retrospectives to fall flat and take on characteristics of the legacy status quo. As a scheduled ceremony occurring at the end of a sprint (typically modeled after the Scrum framework), retrospectives often mirror “lessons learned” or “post-mortem” meetings from peoples’ past experiences. Rather than a means to discover ever better ways of working together, many “Starter Agile” retrospectives range from apathy (e.g., 30 minutes to review good/bad sticky notes), to a laundry list of changes that no one is accountable for, to lengthy vent sessions featuring pointed fingers loaded with blame and shame.
To be sure, “Modern Agile” teams have escaped the laissez-faire and destructive behaviors described above. The critical foundation for working together is here: a culture supported by pillars of “make it safe to fail”, “respect & appreciate people”, and “conduct blameless retrospectives.” I argue that teams of people who discover these principles make a shift towards retrospective as a behavior, rather than a scheduled ceremony. This may look like team members exclaiming, “Let’s retrospect on that!” after a particularly positive (or negative) event occurs. As an example, I observed a team that used stickies on a wall to capture feelings, needs, and ideas daily. At any time a team member could call for a retrospective (respecting work in progress) to explore the notes and, because retrospection was an intentional behavior, the team usually had a couple sessions each week. Supported by a culture of respect and safety, improvement was always on-going. A person on this team made a comment about retrospectives that perhaps draws the distinction between “Modern Agile” and “starter Agile” – she said:
“On this team, I don’t feel like I’m on a schedule to jump in place – going through the motions, but never getting anywhere.”
I can’t think of a better note to end “Starter Agile” with.
Agile Out Loud 
2 thoughts on “Starter Agile, Pt. 3”