I've been thinking a lot about Scrum, how lean relates to Scrum, and how to express what I see in such a way that it doesn't sound like I am attacking Scrum.

I have never been trying to attack Scrum. Rather, I've always been talking about how you need Lean, etc., and, unfortunately, some people have interpreted that as an attack. In reviewing some of the work I've done over the last few months, I have seen some companies take on applying Scrum to a few teams with very good success.  At this team level, Scrum works well.

This is not new. I have said this before. But it got me thinking - maybe it's fair to say when you look at Scrum and Lean at the team level, they are very similar. The differences lie more at the enterprise level.  At the team level, I would say Scrum is almost a perfect manifestation of Lean principles if one confines "the whole" to the team and if you ignore that the batching of stories in an iteration is not exactly "perfect flow" (but has other advantages). For example,

• Using iterations is a way of deferring commitment, creating knowledge, delivering fast, and eliminating waste (discovering what not to build thereby avoiding building unnecessary things). 
• Iterations follow good queuing theory (limiting work to capacity), minimize work in process and use pull methods in sprint planning. 
• The focus on the team is a way of respecting people - letting them figure out how to get their job done - and management is supposed to help them.
• When you add good engineering practices - Test-Driven Development, proper use of design patterns - as we recommend, you also follow "build quality in." 

So I agree it is not correct to say Scrum is inferior to Lean. I do say that the practices that Scrum puts forth are about how the team works.  Once you want to extend Agile beyond the team one should look at principles that will help guide you.

"Lean-Scrum" and "Regular Scrum" 

The question is, when you are learning how to use Scrum, are you aware that these are the principles that are driving things or are you simply following practices that have been set forth in books and may or may not be applicable in your situation? The former lets you adapt to your context and extend more broadly because you are guided by principles. The latter is helps at a local level but keeps you boxed in to what you have been told.

For this blog, let me call the former, "Lean-Scrum" and the latter "Regular Scrum." "Lean-Scrum" involves the explicit use of Lean in Scrum coaching.  Now, I am not trying to sell Net Objectives here. What I am saying is that if Scrum practices can be thought of as manifestations of Lean principles, then perhaps when learning Scrum, you should look at the principles on which Scrum's practices work.

Example: Daily Stand-ups. The Daily Stand-up is prescribed in Scrum as something to be done daily. But is that really true? I used to think so until I got involved in several companies who seem to like to do it every other day and are doing very well.  They found that far from helping them communicate, those daily meetings actually impeded their work! They interrupted people.

A recent article in Gamasutra underscores the harm that these interruptions can cause.  This caused me to think that these companies were on to something. By doing standups every other day, they managed to avoid interrupting people while still ensuring effective communication. The teams like it much better.

Now, this got me questioning what these meetings are for anyway?  Why do we do them?  What is their purpose?  Is the "Daily Stand-up" the best way to get the value?  Now I know that Ken has said emphatically if you don't do  standups daily then you aren't doing Scrum - but is that right? Isn't the intent to improve our process and not follow dogma?

What is the purpose of the stand-up meeting? It is to:

• Improve team communications
• Track progress
• Let people know what is going on with other people
• Identify impediments

Consider the first three. I have seen teams in bullpens and even offices where they communicate regularly.  When teams use Agile tools it is easy to see what changed and how.  Daily meetings are not necessarily the only way to do these... In fact, if you are relying on the Daily Stand-up to do this, you may well have other serious problems.

What about identifying impediments? On a team where people are not used to sharing problems, this is one of the greatest advantages to Scrum.  But if people already have a culture of sharing their problems and impediments the absolute need for the daily standups may be different.  Do not get me wrong here, in our experience, 95% of teams will find value in the daily standups.  I am just saying that there are exceptions to any practice, even one that seems it is essential.

Bottom-line: Apply local knowledge not dogma 

For me, the bottom-line is to follow the lean principle to "respect people and let the team figure it out." Just make sure you are not giving in to a few people who just don't want to be social :-)

I don't think this is anything new. I just think it underscores the point that understanding why things work is essential... and that no practice is sacrosanct. You still gotta' think!

I still believe that Lean helps you think about Scrum practices.  While it is true that one shouldn't expect that a framework would tell you all the things to look at but I'm thinking in this case it should.  Much like physics is highly dependent upon calculus (and when learning physics they tell you to learn calculus) I think the same could be true for Scrum. Start with Scrum, but then learn how Lean helps when you want to take it beyond the team.

Al Shalloway
CEO, Net Objectives
Achieving Enterprise and Team Agility