Agile is not a family of processes or a product, rather it's a specific cultural mindset. And to effectively introduce Agile, you must understand the culture of the organization you are attempting to change.
I agree with the general thrust of the book, but would like to offer a few counterpoints to several sub-themes.
Kanban and Culture
Sahota uses the Schneider Culture Model as the basis for qualifying various Agile approaches. (See explanation by Sahota). I think this can be useful, but where I differ with Sahota is how he arrives at his conclusions. To understand where Agile fits in the model, the Agile Manifesto is analyzed as well as a culture survey of agile practitioners. Agile is then qualified as mostly collaboration and cultivation.
Sahota's analysis qualifies Kanban as mostly compatible with Control culture. He doesn't arrive at this by surveying knowledgeable and experienced Kanban practitioners, but rather just on his interpretation of Anderson's Kanban Principles. This is a disappointing omission. I understand why that data is not included, as no such survey probably exists. But nevertheless, it undercuts the weight of the analysis. For Agile, Sahota presents the sentiments of a broad number of Agile advocates. For Kanban, Sahota presents his own understanding of Anderson's high level principles. I was glad to see an appendix of alternate views included at the end of the book. A survey of Kanban advocates would likely reflect something similar.
Beyond my concerns with the analysis, it is worth exploring this qualification model further. Simply saying a principle belongs to one cultural quadrant or another (or somewhere in between) is lacking.
Take "Limit WIP" for example. At first glance, it appears to be focused on the system--something Sahota attributes to the company-oriented side of the model. But when I observe this in action, it is apparent to me that limiting WIP is a challenge to a company-oriented mindset. Limiting WIP is one of the best ways to help people reduce their dependence on the tools of anti-collaboration: functional specification documents, architectural diagrams, and meetings. Systems with extreme levels of WIP need ways to persist all that knowledge for long periods of time. And when when almost all available working time is devoted to knowledge persisting, there is no oxygen left for collaboration. One could think of limiting WIP as a mini "Green" initiative right in the middle of a software group. It helps protect the delicate ecosystem that allows people-oriented cultures to grow and flourish.
Try this for yourself. At the outset of an engagement with a company-oriented culture, ask the people who depend on traditional project schedules what they think of limited WIP and its first offspring, a Pull system. Do you suppose they think it's a cultural fit?
Another example, at the practice level, is how standups are conducted in Kanban compared to Agile's flagship approach Scrum. In Scrum, the meeting iterates over team members, who are asked: What did you do yesterday, what do you plan to do today, and what are your impediments. On the surface it sounds very people-oriented doesn't it?
In Kanban, the meeting iterates over work items, not people. Work items with impediments are noted. People are implicitly trusted to be doing the work; they don't have to be asked everyday. Even though the Kanban approach is about the work or the system, the resulting cultural and social attitude is much more people-oriented than the approach that is supposed to be people-oriented (Agile manifested through Scrum).
These are just two examples. My former colleague Phil Ledgerwood, blogged about the effects of visualizing the workflow.
These are just two examples. My former colleague Phil Ledgerwood, blogged about the effects of visualizing the workflow.
The difference I'm trying to illustrate is the observable outcomes when principles and ideas are put into action through specific methods. A static analysis of principles in a vacuum is inadequate. So to use the Schneider model further, the Kanban mindset recognizes a cultural pressure present in company-oriented cultures. The dominant aspects of this cultural pressure is usually harmful to the people side of the Schneider model (collaboration and cultivation) in knowledge work organizations. To help alleviate this, Kanban practices redirect this pressure to the system, and away from the people. So when an organization with a company oriented culture says they want to improve their software projects, Kanban and limited WIP challenges the project schedule pressure. That cultural pressure is redirected to the system instead, allowing people to cultivate a more people-oriented culture.
I agree with Sahota that Kanban is an appealing approach when faced with a control or company-oriented culture. But it is not because Kanban is accommodating to those cultures, it is because Kanban takes an evolutionary and incremental approach to challenging those cultures.
Cargo Cult Agile Mindset
My second counterpoint is not a direct critique of the book, but rather a commentary on a prevailing and persistent theme in the Agile community. The book just got my anti cargo cult juices flowing.
Over the last few years, many Agile leaders have warned against a Cargo Cult Agile approach that only mimics Agile practices and processes without understanding the real value is in the cultural mindset. I support this understanding and the distinction is a valuable lesson for people new to Agile.
Full disclosure: I am completely supportive of the Agile way, being Agile, and not just doing Agile, etc. I find great value in aspects of XP, Scrum, and Kanban and use them in my work. I also see much value in the Lean mindset.
However, I see a similar pattern emerging with the community's focus on the Agile mindset. We write about Agile failure rates, Agile adoption vs. transformation, etc. And I am concerned for those learning about Agile, that they will see the Agile mindset as the destination, not a means to improvement.
Let's step out to a second learning loop for a moment and take a look at our language. We lament our failed Agile transformation initiatives not because of the continued poor organizational performance, but because we failed to instill the Agile mindset and all the cultural trappings. We differentiate between an Agile adoption and an Agile transformation, as if the Agile mindset is the end goal. We make statements like "Culture is the #1 challenge to Agile Adoption." Instead, why don't we state that culture is the #1 challenge to organizational improvement? Is Kanban Agile? Does it really matter if it helps organizations improve?
However, I see a similar pattern emerging with the community's focus on the Agile mindset. We write about Agile failure rates, Agile adoption vs. transformation, etc. And I am concerned for those learning about Agile, that they will see the Agile mindset as the destination, not a means to improvement.
Let's step out to a second learning loop for a moment and take a look at our language. We lament our failed Agile transformation initiatives not because of the continued poor organizational performance, but because we failed to instill the Agile mindset and all the cultural trappings. We differentiate between an Agile adoption and an Agile transformation, as if the Agile mindset is the end goal. We make statements like "Culture is the #1 challenge to Agile Adoption." Instead, why don't we state that culture is the #1 challenge to organizational improvement? Is Kanban Agile? Does it really matter if it helps organizations improve?
When we describe our efforts in terms of organization improvement, it challenges us to think about where we really want to go as an organization. If I may channel Denning here, we would have choices between maximizing shareholder value and delighting customers.
One of my fears is the development of a Cargo Cult Agile Mindset in our community. Even though it's the state of the art now, there is no guarantee it will always be that way. Imagine for a moment what the state of our community might be in the future (distant, or not so distant). I can image a team of software professionals registering impediments during a collaborative exercise, and one of those impediments could be the Agile mindset itself. "If we could only get senior management to let go of their insistence on that legacy Agile mindset, we could really make some improvements."
The Agile mindset as an impediment... Sounds crazy doesn't it?