Modular Agile: Loosely coupled, highly cohesive ceremonies

I'm giving a talk these days on the No Fluff Just Stuff tour entitled "Yes You Kanban." Toward the end of that talk I do a brief compare and contrast exercise between Kanban and Scrum. A brief visit to the ScrumAlliances page entitled "What is Scrum?" will give you the following tasty tidbit:

Scrum is made up of three roles, four ceremonies, and three artifacts.

The point has been made at the last couple of shows that I've done a good job talking about the differences between Scrum and Kanban as they relate to roles and artifacts, but that I haven't said much about the ceremonies. While trying to figure out what direction I'd be going after closing out my series on "The Seven Wastes of Software Development", I thought I'd jot down some of my ideas around ceremonies.

The "What is Scrum" page enumerates four ceremonies that form their segment of Scrum:

• Sprint planning: the team meets with the product owner to choose a set of work to deliver during a sprint
• Daily scrum: the team meets each day to share struggles and progress
• Sprint reviews: the team demonstrates to the product owner what it has completed during the sprint
• Sprint retrospectives: the team looks for ways to improve the product and the process.

So what are, if anything, Kanban's analogs to these four ceremonies?

Kanban in itself prescribes almost nothing for the software development team, save the idea of explicitly limiting work in process. Kanban is a tool for modeling your workflow, not replacing it. Any and all ceremonies are optional. Their presence or absence in your particular implementation is left up to you. This is incredibly appropriate, as only you know your unique context well enough to determine what ceremonies will provide value to your organization.

With that said, Kanban does recognize the value of a regular cadence of prioritization and delivery. However, while Scrum tightly couples these concepts to the bookends of the Sprint, Kanban takes a more modular approach.

One of the primary tenets of sound software architecture is modularity, or the idea of composing a system from a set of loosely coupled and highly cohesive components.

The idea of loose coupling relates to how tightly the behavior of one component is bound to the implementation details of other components. Where a change to the internal details of a module A have a cascading effect on module B, we can postulate that A and B are tightly coupled. However, where that same change to module A has zero affect on module B, we can postulate that A and B are loosely coupled. Other facets of coupling include the relative difficulty inherent in implementation of modules, as well as the relative reusability of components.

The idea of high cohesion relates to the behavior of a single component. A highly cohesive component encapsulates one concept - it does one thing well. Highly cohesive modules are easier to understand, easier to maintain, and easier to reuse. On the contrary, components with low cohesion suffer from "kitchen sink syndrome." They try to do too much. They try to encapsulate too many concepts. They tend to grow exponentially, and over time become more complex and more difficult to maintain.

For a good example of a loosely coupled, highly cohesive architecture, look no further than the Unix family of operating systems and its "pipe and filter" pattern for chaining the input and output of various command-line programs to accomplish varied tasks. Each of these programs, such as "ls," "grep," "wc," etc., does one thing extremely well. And they operate completely independently of one another. However, using pipes ("|") and filters (the individual programs) we can construct systems at the command line of which their authors never dreamed.

OK - end rabbit trail - back to Kanban and Scrum. What does all of this talk about modular architectures have to do with ceremonies? Think of the various ceremonies - planning, daily standups, reviews/demos/deployments, retrospectives, etc. - as individual modules. The Sprint itself - the development of the software - is also an individual module. What we do with Kanban is to decouple all of the ceremonies from the development of the software. Planning and prioritization happen only when and if they need to happen, rather than always happening at the beginning of a Sprint. Reviews/demos/deployments - activities that always happen at the end of a Sprint - now take place at whatever interval is determined to be optimal for the organization.

Let's examine planning and prioritization. Our Kanban system starts at the far left with an input queue labeled with some size limit. At any given time, if the column immediately to the right of the input queue has not reached its WIP limit, an individual can pull work from that queue and begin work. It is the responsibility of those charged with planning and prioritization to ensure that the input queue is never empty. Depending on the speed of the development activities, this may happen daily, weekly, or monthly. It may shift around somewhat based on the amount of work item variability allowed into the system. Those involved with the prioritization process optimize around making it work in a way such that the entire value stream is optimized. It is highly cohesive, and it is loosely coupled from events in the development pipeline.

What about reviews, demos, and/or deployments? In our particular environment, we deploy running software once per week on Wednesdays. However, that Wednesday event is seldom a momentous one. Take a look at the development team on Wednesday's and you'll see the same level of stress that you see any other day - relatively low. They are busy about the business of flowing work from one end of the board to the other. It's just another day. However, on Wednesday evening, our deployment team picks up all of the work items that are in the "DONE" column and deploys them. If they find one item, it gets deployed. If they find ten items, they get deployed. If they find none, they get to go home early. :-) Deployment is optimized around making sure customers get value once per week. They've come to expect it, and Thursday morning always finds folks excitedly trying out what's new. That said, there are little expectations about what shows up in that package. If development is finished, it shows up. If not, then wait until next week.

But let's consider a high priority item that has come from the executive suite with a great big expedite tag on it, and it doesn't get finished until Thursday. When does it go out? Thursday night! Our deployment process is completely decoupled from our development process. If something needs to be deployed, it gets deployed. No more, "Wait until the next Sprint demo."

Let me summarize. Kanban is all about optimizing your workflow around rapid delivery of value to your organization. For some of you that workflow may look like out-of-the-box Scrum, and for some of you it may not. As it relates to ceremonies, where Scrum tightly couples its ceremonies to the Sprint, Kanban takes the modular approach, allowing you to create independently managed cadences for planning, prioritization, reviews, demos, deployments, retrospectives (a topic for a later Kanban article), and development. Comments? Sound off.