culture

Agile Rituals Improved – Participation

Let’s face it; many Agile teams are disappointed by how much time they spend in rituals. But, it doesn’t have to be that way. In fact, it shouldn’t be that way. A team can take many actions to shrink the amount of time it spends in rituals while simultaneously increasing their effectiveness and fostering better engagement. Those actions tend to fall in one of two categories: participation and preparation. In this first of a two articles series, I am sharing a few examples of participation-related practices that have worked for me. A subsequent article will look more closely at preparation.

Note: despite some Scrum references, the tips can be applied to rituals from any Agile method. This article, therefore, assumes a certain level of Agile literacy. It does not describe the basics of the various rituals discussed.

Before changing anything, the first step is to ask the participants if they are satisfied with the current state of affairs. If there is no dissatisfaction, there will be no willingness to experiment with solutions. For the purpose of this article, let’s assume that someone has secured buy-in.

The first of the two principal causes of long, boring, ineffective rituals is the dearth of active participants. Here are some tips in no particular order:

Tip #1 – During grooming, don’t let the Product Owner do all the talking. A few days before the ritual, look for team members willing to learn a few stories/epics and take the first crack at answering questions about those during the ritual. A variety of presenters make for more energizing meetings. And you should walk away with at least one person who has a deep understanding of the topic because this technique is an embodiment of: “If you want to master something, teach it.”

Tip #2 – One of the surest ways to lose meeting participants is to have them wait on someone taking notes. This frequently happens in Scrum grooming and planning because the PO is trying to facilitate the meeting, describe the user stories, take notes, and update the backlog in real-time. To cure this, delegate tasks to the Scrum Master and any chickens present in the meeting.

Tip #3 – Story sizing debates derail many a Scrum planning rituals; is this story 3 points or 5 points? There are endless opinions. What participants frequently forget is that sizing is an exercise in estimation and that all estimates are wrong to some degree. Therefore, only the order of magnitude truly matters. For example, teams using the Fibonacci series don’t have to agonize over whether a story is one size up or one size down. The key is to limit the debate to arguments that are likely to sway the estimate by a lot.

Tip #4 – In every group meeting some conversations devolve into back and forth between two or three participants while everyone else waits. To snuff this, devise a mechanism where the crowd signals its desire for the conversation to stop. For example, people can raise a hand, and when two or more hands are up, the debate has to pause while a check for relevancy is performed. In short, don’t let the audience be victimized; empower it to self-regulate.

As a leader, bad meetings are just too expensive; there is the immediate cost of wasted time and the longer cost of reduced employee engagement. Moreover, group meetings are a golden opportunity to influence the organization’s culture. Servant leaders have a responsibility to work toward ameliorating the environment (see the article on the role of the manager). Some of the tips above may be useful in that pursuit. What other tips do you have?

Works cited

“Citizenship”, by Alberto Miranda, The Noun Project, Web. 30 Mar. 2016.  Modified.

Similarities Between Lean and Agile

It is said that the difference between theory and practice is greater in practice than in theory. Although I believe this is true of a lot of things, one area that eludes this old saying is the practice of Lean and Agile.

Practicality

The theoretical differences between Lean and Agile are the frequent subject of heated debates, even though their practical implementations often solve many of the same problems. I think those differences aren’t nearly as pronounced as they are often thought to be, and that far too much energy is expended on their account. I suggest we focus instead on getting to the business outcomes we all crave by cherry-picking the best arguments and techniques from each. Let me elaborate:

Origins

Of all the differences I hear about, the most prevalent seems to be that Lean seeks to reduce variability in the work so that the system can be optimized, whereas Agile accepts that variability as inevitable and attempts to adapt for it. This description is not without merit from a historical standpoint. Lean was first popular in traditional large scale manufacturing environments, and Agile sprouted in software development where each unit of work is unique.  Though this analysis may be historically accurate, it is also far too shallow for us to conclude that Lean and Agile are fundamentally different.

Practices

The similarities strike me as far more numerous. Both Lean and Agile seek to deliver value to the customer through building the right thing. Both promote a culture of continuous improvement: Lean has kaizen, and Agile has the retrospective. Furthermore, Lean has poka-yoke to mistake-proof problem areas, and Agile similarly promotes the management of technical debt. Both focus on reducing delays. Lean most frequently uses the value stream map as the main tool, while Agile methods often use short iterations for much of the same purpose. Both emphasize the importance of quality. Lean has quality standards, and Agile frequently has a “definition of done.” Both promote resolving blocking issues quickly through all-hands-on-deck approaches. Lean has its andon cord, and Agile often has an impediment identification and removal process. Both promote a reduction of Work In Progress (WIP) for the purpose of accelerating flow. Lean emphasizes single-piece flow; Agile urges people to swarm on a common work increments. The list goes on and on.

Values

The parallels between Lean and Agile are actually not surprising. Indeed, a quick examination of the fundamentals reveals similar values. If one compares the principles that underpin the well-known Agile manifesto with the expression of Lean found in the Shingo Model, one notices a common philosophy.

I think the Shingo Model cornerstones of respect and humility are just a highly condensed expression of the Agile manifesto. What I mean by this is simply that the Agile values (and principles) can be traced back to respect, humility or both. For example, humility is implied in the desire to replace planning with a discovery approach. To arrive at that desire, we must first humbly admit the limits of our knowledge and prediction abilities. Similarly, respect is implied in the belief that people are intrinsically motivated, trustworthy and able of self-organization.

Put another way, Shingo’s respect and humility are to Agile what the Maxwell equation is to the inner workings of electric car propulsion systems. All the information is there, but it has to be unpacked.

Fig. 1. “Maxwell-Faraday equation”

Bottom Line

In summary, I believe Lean and Agile are rooted in many of the same principles and values. The challenge of articulating the differences is probably best left to the academics. The doers should focus on taking action instead, because while the differences may be smaller in practice than in theory, practice still makes perfect. I’d love to hear from you if you think this is an oversimplification that obscures some important practical differences.

Works cited

“Maxwell-Faraday equation”, Maxwell’s equations, Wikimedia, 24 Nov. 2015. Web. 1 Dec. 2015.