While reading this post on Looks Good Works Well by Bill Scott, I started wandering about scale and methodologies. As Scott mentions, when he started using Extreme Programming in agile methodology, it worked for him when not taking it literally or dogmatically, but as guidelines that informed his process.
I wonder if that is not a result of scaling (up or down) the method to the process.
As I see Jason’s approach to work, it more and more seems like ideas that have arised from his own experience at 37signals, and thus are informed by many a characteristic of his own enterprise, such as scale, dynamics and communication methods. An excerpt of Jason’s key points from the article:
(note: this does not pretend at all to be a questioning or judging on Jason’s arguments, it is just a personal reasoning started by these points)
Keep your team small
– Forces you to focus on what’s important
– Clearer communication comes for free
– “Communication usually fails except by accident”Collaboration is about communication, not control
– Keep your team apart. Interruption is not collaboration. Interruption is the enemy of productivity.
– Encourage alone time
– Stay away from each other as much as possible
– Communicate more passively, less actively.Meetings are toxic
– Usually a symptom of a problem, not a solution. Mentioned a business leader in Brazil who advocates that all meetings are optional.
– Meetings convey an abysmally small amount of information per minute
– Require thorough preparation that people rarely do
– Tend to procreateInstead make tiny decisions
– Decisions are progress
– Progress is great for morale
Most of these points are sound and seem to tackle rather well some inner problems of company productivity. Yes, meetings consume valuable time in a rather unefficient way, and yes, uninterrupted time might prove as a very productivity-savvy tool, and yes, keeping your team small helps having an eye on mostly everything.
But (and this usually tends to be a big but) what if you’re handling the intranet design for such a multinational behemot as Dresdner Kleinworth or Accenture? How small your teams can be? How many conferences and meetings you might avoid before the team is completely uninformed? How many uninterrupted time you can have before you fall out of the client’s loop?
My way of seeing it, and where de weakness is, is that all that smart and sound advice is directed and intended for a rather small audience: that of start-ups, small companies, design studios; but it is not explicit in its wording.
Small is not necessarily better: Apple is great and big. Small teams can take care of some projects like Backpackit.com, but not British Gas’ many service websites.Tiny decisions help keep things being done instead of being talked about (as it happens in meeting-driven and design-by-comittee cultures), but in a big project scope can be missed.
I am in no way saying I am contrary to these guides; I am convinced they work, and I believe in most of them as great guidelines to improve your workflow, project and product/service. I just miss the appropiated context on where to apply them, or better, from where to rethink and adapt them to the existing context.
There’s a great book S, M, L, XL by architect Rem Koolhaas. It defines a common ground from where to think about scale inside architecture. His approach is that every scale has its own advantages and shortcomings, and we have to focus on them to exploit them at their maximum. After all, it seems rather unlikely to pretend that you can build the Pyramid of Giza over Agile Architecture. But that thought might be completely wrong.
That’s one thing I might start thinking and working towards, as little has been said on how big companies can benefit from these forward-thinking productiveness-driven guides.
