The Cluetrain Manifesto

I just finished reading this book called The Cluetrain Manifesto. I read about it on someone’s blog a long time ago, and had it on my reading list for a while. Then recently, my close friend Kiran recommended it to me again, and so I picked it up.

I liked it! Sure, it is a little repetitive at times – the book is kind of a collection of essays by a group of four authors – and they cover overlapping grounds. However, for most people the book will be one of two things – a) a whack on the side of the head, or b) a reinforcement of what they might have been thinking.

The basic premise is simple – the Internet has changed the way markets behave, and companies need to respond and engage the new markets in this new way as well. Nothing new, huh? Still, how many companies are truly doing it?

In fact, from the above, it might even seem a rather dated book. After all, it was written in 1999, when it was a fact that the Internet was new, and not well understood, and companies were jumping onto the bandwagon. The authors explain that the Internet is not just some new medium to advertise on, or set up websites that dispense corporate-speak. It is a place where people (existing and potential customers) can talk, have a conversation. And these people talk about companies, and share experiences about them. They swap reviews – both good and bad, they analyze companies’ strategies, they come up with ideas for improvement, so on and so forth. It is up to the companies to participate in these conversations and gather what they should from them.

Smaller companies are sometimes good at doing this. They actually know many of their regular customers by name, and gather plenty of feedback and ideas on what they could do more or better. However, there are plenty of companies out there, that even today, do not respect truly their customers, or think they can get away with being a corporation that doesn’t need to truly engage with their customers in a human-like manner. If you’ve ever been treated badly by a large company, say an airline company or a rental car company, then you know what I mean. Most people are pretty clear about the difference in service they should expect when they’re dealing with typical large corporations versus small, mom-and-pop outfits.

And that’s the point. Companies need to get off their high-horse of being a business, and become more like the normal people that work in them. After all, they’re customers too, from someone else’s perspective. Companies sometimes do this during the startup phases. And as they expand (when the distance between the producers and the consumers grows beyond a certain point), they lose this human-ness, and become a faceless corporation that is impersonal and forbidding. If the founders can truly inculcate this and the rest of the principles outlined in The Cluetrain Manifesto, they will find that it becomes another secret-weapon that can be wielded against their more traditional, large corporation-type competitors.

A decent read, I’m sure at least a couple of ideas will stick.

How Lean and Agile are different, not that it matters

This post is an attempt to clear the air a little bit around this issue. First off I want to make it clear that, in my opinion, the theoretical distinctions between the two concepts are not important enough for teams to change anything they’re doing to produce good software. In other words, who cares what you call it?

However, it is useful to understand what each concept is. This allows you to have clear conversations about issues and solutions, and it also makes it easier to see what needs to be done at every level to improve the overall throughput of the team or organization (or, indeed, of the entire value-stream.) The way I see it, Agile and Lean are similar in many ways, and they really complement each other the rest of the way.

Agile

Agile is a framework that focuses on iterative-development and feedback to build out a software product. Agile focuses on quality by making things like test-driven-development, continuous integration, and refactoring essential pillars of the process. By definition, agile fosters the creation of an adaptable and evolving team process – it accommodates the fact that each project is different, and processes need to fit the situation. Agile also emphasizes communication and collaboration over documentation – thus, it enables teams to move quicker by resolving things face-to-face. It also considers the customer a part of the team, thereby ensuring maximum feedback reaches the ultimate users, and allowing them in turn to change the course of the work product.

Agile methods usually measure things within the software development world – number of stories (scope), estimates (time), velocity (speed). This in turns drive costs and budgets.

Overall, Agile can be thought of as a framework for the software-construction (planning, development/QA, release) part of creating a product.

Lean

Lean, on the other hand, is a management philosophy. Ultimately, it focuses on throughput (of whatever is being produced) by taking a strictly systems-level view of things. In other words, it doesn’t focus on particular components of the value-stream like code-construction or QA, but on whether all the components of the chain are working as efficiently as possible so as to generate as much overall value as possible. Value, of course, includes things like high-quality, and optimized for time and resources.

Lean is based on several things – queuing theory, the theory of constraints, concurrent engineering (set-based development) and delaying commitment to the last responsible moment. Careful metrics (only the ones that truly measure throughput: this often means going one level up) is an important part of lean – this allows everyone to be objective about everything. Speaking of which, Lean software recommends measuring things across the value chain – and as extended as that chain can be. It recommends measuring return on investment (ROI), customer satisfaction, customer usage patterns, market share, and so on. This in turn drives budgets and costs within the software organization.

Where they’re similar

Both Lean and Agile focus on people – over pretty much everything else. They both focus on inspecting and adapting – in order to improve the work-product and efficiency in producing it. In other words, feedback is critical – from people, from customers, from stake-holders, and from the product itself. They’re both quality focused, and they encourage early discovery and more importantly, prevention of defects.

The area where they complement each other most, is in the breadth of their world-view. Agile is usually focused very much within the software development team or organization, Lean focuses on the entire system that includes as many workers, partners, customers, external stakeholders as possible.

How they fit

Having made these remarks, I’d like to present this picture – it is a way I like to think of the way Agile and Lean fit together. It is sort of a stack – Lean is a foundational framework, Agile sits on top of it. I’ve also taken a shot at depicting some of the building blocks within each.

How Lean and Agile fit together

It doesn’t really matter

I’ve found that after incorporating more and more aspects of Lean into your Agile processes, the distinctions start to blur. In the end, Lean subsumes everything, and ultimately, the only thing that matters is whether the organization delivers what customers want and like, how fast they can deliver it, and how much money the organization and its customers can make together.