> It starts to seem likely that Scrum done with respect and intelligence and Kanban performed the same way will converge on a common solution. As we all discuss this I see so many more similarities than differences.

Yes. Kanban gives us a way of describing, or understanding, why these adaptations of text book Scrum are good. Or ways of arriving at these solutions via a different path.

Karl

In my mind, the biggest difference is in how you arrive at the timing, not in the nature of the timing.

Scrum generally specifies the overall time signature and the different meetings (Inspect and adapt cycles in general, but I’ll call them meetings for ease) occur at harmonic cadences within that overall signature. I can easily picture a daily standup as sixteenth notes within a weekly tempo of quarter notes within the sprint cycle of measures… Same thing with kanban except replace sprint with MMF’s…. they do tend to hit a steady pattern as Karl describes.

[Ok - post-wrong, aka different type of wrong, starts here]
I was going to say that Scrum specifies these tempos and kanban allows them to emerge. I was wrong. Scrum specifies two of the cadences: Sprint length & Daily stand-up. Kanban doesn’t specify any of them, but the daily one is almost universal in my experience.

However, Tobias, from listening to how you run Scrum, it sounds like you do allow all of the other tempos to emerge naturally, including release cycle and some aspects of the planing cycle.

As I listen to you talk about to Scrum I continually come to the understanding that successful teams led/facilitated/taught by the masters are going to end up with behaviors that look and feel remarkably similar, regardless of the set of tools and approches used to get there.

one thing to consider in the time signature, is that we are not necessarily talking about a single signature. the system in question could very easily (is most likely) a poly-rhythmic system. You could have planning running on a 3/4 signature, review on a 4/8, release on a 3/5, and …

we have to remember that not all activities need to run on the same schedule. let the customer-focused activities follow the rhythms of the customer, and let the team-focused activities follow the rhythms of the team. where there are customer-and-team combined activities, let the two synchronize naturally.

As an example, I have worked with teams who do mid-sprint planning, simply because it is exactly the right thing to do. Generally they continue with the committed work, but new information that comes to light can be incorporated if everyone agrees and corresponding articles are removed from the current commitment. Just as common are mid-sprint retrospectives (although I’ll still tend to recommend teams set certain days/times for these to continue the sense of regular rhythm — heartbeat. There is a feeling of safety in that, a steady commitment, a trust.

One of the very big advantages of regular rhythm for product reviews of course is that we can calendar in the execs, customers, users etc. months ahead of time. Running reviews ad hoc we stand a big chance of not having the right people there. I also like the ceremony around the “Regular Wednesday Lunchtime Review” (or whatever it is). Ceremony is important for tribes, and a good Agile team is exactly that: a tribe. A review is a feast, with many guests invited. It takes planning and consideration to entertain well.

If the former, then I don’t see it as any different to the way a Scrum team works, but if you are changing time signatures, and perhaps duration of each beat (?) then that is wildly fascinating and I want to learn more about that. I am not sure it is the best way to reveal dysfunction though, but I think it must have some other interesting outcomes.

I would suggest that we separate the notion of a Scrum Sprint timebox from the wider concept of timeboxing. Scrum connects many activities to a particular timebox but this is not the only way that time boxing is used.

A time box can be useful for managing activities at a wide variety of levels. For example, a meeting or a project can be timeboxed. By timeboxing we communicate that our priority is schedule, most obviously over scope.

So a timeboxed meeting will provide an hour to discuss a topic, the discussion is over hen the time runs out. This can be a useful discipline independent of methodology.

Similarly a timeboxed project is a commitment to effect a change bounded by a particular date, this will guide our decisions about how the change will be approached.

Unfortunately this doesn’t guide you to the length of the cadence. Its most likely that business needs (processes) as defined by sales & marketing (rule of thumb has been that 2/3 of all dollar spend by a company is by this group) is likely to have a greater influence on the cadence length, as they are closest to the customer and are missioned to set expectations.

Takt time is calculated by determining the customer demand for value (i.e. working product delivered) and dividing that by the available work-time. The result tells you how much product you need to deliver per period. And then you can determine how many resources you need to deliver at that pace. Both too fast and too slow development is wasteful.

Applied to the development of software intensive-systems, I suggest the customer demand is established by the pace at which the user’s Acceptance Test group can accommodate new releases. The cadence of the entire development process should then be geared to that.

Best regards,
Grant (PG) Rule