Not necessarily. Let’s examine the four major methods practiced by those in the Agile community and see what overlap and differences they have. In particular, let’s examine Scrum, XP, Lean and Kanban. Let’s start with some of the beliefs that all of these methods have in common:

• People are very important and know how to do their job better than those managing them
• Completed software is a better indication of where you are than whether you are working towards your plan
• Quick feedback between developers and customers (or their representatives) is essential
• Poor quality development slows you down

There are also some beliefs that Lean and Kanban explicitly state that, if asked, I believe virtually all Scrum and XPers would agree with:

• When you have a lot of work in play at any one time you will be less efficient
• You should finish as much as you can before you start something new
• It is almost always helpful to define acceptance tests before writing the code represented by those tests

Because Scrum and XP are improved by these beliefs (even if not explicitly stated in the methods) they are becoming adopted by their practitioners. However, it is worth noting that the reason they are not explicitly stated is because of the following set of beliefs that virtually all Lean and Kanban practitioners have that many in the Scrum and XP community don’t:

• There is a science underneath software development and you ignore it at your own peril*
• It is critical to take a systemic view of how we work to see how our process is working with or against the rules, or laws, of software development
• Management plays a critical role in software development when more than just a few teams are involved
• Managers should be coaches to the team and should be held accountable for improving the value stream. As coaches, they should notice when the team does not follow their own process, does not create explicit policies to follow or appears to be going down a rat’s whole. While they cannot tell the team what to do (that would not be effective) they can coach by noticing these situations and helping, even demanding, the team improve
• Flow and visibility must be attended to to improve the effectiveness of the entire organization
• While people are very important, systems are virtually equally important. In other words, it is not people over process it is people and process – or, as Don Reinertsen likes to state it – people times process. If either is ignored the total capacity is low.

Many agilists don’t hold these to be true. The Scrum camp in particular is split on these – many believing some of them many not. So in many ways there is not an agile community as much as several sub-communities.

If you are interested in this topic, you may find my earlier blog Differences in Beliefs Results in Differences in Approach.

* Note: Believing there is a science underneath our work does not imply there is little opportunity for creativity. NASA scientists in the 60s were very creative but still paid attention to the laws of gravity. Also, saying there is a science underneath software development doesn’t imply predictability. There is science under the weather, but the weather isn’t always predictable. But the science can lead to understanding and with it and feedback we can get some degree of control of our process.