The 37signals Planning Philosophy Mistake
The interview focuses on his, and 37signal’s, planning philosophy of which the crux is that too many people over plan and that the best way to progress is to plan loosely stay relaxed and adapt as you build, rather than deciding exactly what to build before starting and while in motion trying not to deviate from the plan.
Busting your ass planning something important? Feel like you can’t proceed until you have a bulletproof plan in place? Replace “plan” with “guess” and take it easy. That’s all plans really are anyway: guesses. I think companies often over think, over do, and over devote to planning. So next time call a plan a guess and just get to work. Jason Fried, Let’s Just Call Plans What They Are: Guesses
In this article I’d like to expose a common and potentially damaging trait I’ve noticed in the web design and development community that has stemmed from 37signal’s philosophy and Agile methodologies.
37signals love and hate
Now let’s get one thing clear, I without question utterly admire the 37signals gang!!
The web applications they produce, such as Basecamp and Backpack, really are fantastic and I believe have spawned the beginning of an entirely new generation of web applications that we see today – web legends.
When I read Rework I found it to be such an inspiring read that I read the whole thing in one session due to its brilliant writing style and structure – literary geniuses.
Finally, when interviewed, each of them seems to be obscenely cool and intelligent while maintaining a completely relaxed and down to earth attitude – demigods.
However these guys have plenty of opposition to their way of thinking and working, for example…
Check out this interview of David Heinemeier Hansson by Jason Calacanis that at times gets a little fruity:
Or articles that have a similar tone to mine:
I think 37signals dominance in the web products field has distorted their ability to critique the client-based approach.
Imulus, 37signals Is Arrogant, And For Good Reason. But Are They Right?
…Really bad advice there, based on a bad premise. Sure, if you define planning as messy and preventing you from getting real, then it would be a waste of time. But is that planning?
Tim Berry, No, 37signals, Planning Is NOT What You Think
But although this article of mine may sound like just another one like the above that flat out disagrees with the 37signals mentality, it’s very much not…
Running Web Projects is not running a business
The problem I want to address is rather more abstract than if 37signals are right or wrong, I want to talk about the effect their attitudes combined with huge success and massive exposure have had on some web folk.
The problem is that I run into production teams that hero worship 37signals, read all their books, blog posts and podcasts and take away from it that planning is rubbish in web development and web projects. They use examples like the great success of Basecamp to confidently demonstrate their point and laugh at your seemingly old skool way of thinking.
When you insist on writing a functional specification before any development begins suddenly you hear the cry to “go Agile on this one” when it seems to be based on little more than knowledge from a few blog posts and an impression that it’s the way forward, that it will magically mean the web project is delivered quicker, to a better standard and probably on budget.
But getting infatuated with details too early leads to disagreement, meetings, and delays. You get lost in things that don’t really matter. You waste time on decisions that are going to change anyway.
Quote from Rework
However if you dig a little deeper and start to fire questions back at these guys n gals, accompanied with knowledge gained from really reading up on, and analysing, all different types of project management methodologies like Agile then you often you start to uncover a few uncomfortable truths.
The biggest one being that most of the people shouting about how running a web project in a Waterfall-esque way to begin with is old hat mistakenly think that the 37signals gang are putting forward a fantastic new model for delivering web projects for clients, let me say this loud and clear, THEY’RE NOT!
The guys at 37signals are always talking about two things, running a business and building and developing web application products – and believe you me there is a huge difference between developing a product to sell and delivering web solutions for clients.
Agile is not suitable for everyone
The reason I found Rework such a breath of fresh air was mainly due to the fact that the lessons they hand out about running a business and developing a product really resonated with me. On almost every page I was putting myself in the shoes of someone doing both of these things and the advice they give just made so much sense and was so against the traditional way of thinking – I was literally blown away by it.
However, as I read the small pieces on the topic of planning I started to connect what I was reading to things I was hearing at the time regarding how web projects should be run “in an Agile way” and I got really scared.
The harsh truth is that in most cases the people saying we should dump web project plans and functional specifications don’t know diddly squat about the commercial realities of delivering web projects for clients as a small digital agency – there I said it.
Why do I say this? Simply because if you take a traditional agency / client relationship where they pay you a fixed fee to produce a website or web application “as quick as possible” while they’re busy running their business, having few details nailed down before beginning production is a recipe for disaster and a massive risk, for both you and the client.
And because the client is often super busy running their business they rarely have the time that would be required in order to conduct an effective Agile process. They know what they want, they know exactly what their business needs online, and with a few challenges and alternative recommendations from you it’s time to nail things down to make sure both parties are happy and then build it.
In some cases, perhaps where a digital agency has a long standing relationship with a client or where the client has a particularly laid back approach, less pre-production planning may be ok – it’s all about risk analysis!
Or, it may be possible to change the way you work with your clients, something Paul Boag approaches in his excellent presentation “No Money, No Matter”. He talks about how he wants to try and change the traditional model of fixed cost projects and move to a more long-term relationship with clients where smaller more incremental projects are taken on that result in the evolution of a website rather than re-design – a great approach, a winner for both client and agency – but really hard to get a client to commit to unfortunately.
However, it’s shame to say it but more often than not, if it’s not written down beforehand exactly what a client is going to get, and signed off, the result is features are missed, defined too vaguely and ambiguously and leave the client with a solution that wasn’t what they had in mind – something the agency will have to do more work for, often for free, in order to rectify this – or in extreme cases the client will exploit these gaps in specification and squeeze more work out of you citing “When you said I’d get a News feature I thought you knew I meant like the BBC Homepage!” FML
This of course does not mean you don’t deviate from the signed-off proposal or functional specification, in fact I would argue that the most common and successful web project management approach in small digital agencies is a hybrid of Waterfall and Agile. Pawel Brodzinsk, an Agile and Kanban advocate, but also a very pragmatic guy, echoes my feelings when he says:
When you consider which methodology you want to follow think which one would be the best for your team and for your client. Don’t believe these fancy presentations telling you how Scrum is great or how Kanban is great. Ask presenters why this or that worked in their case. Ask when they failed and why – most of the time they won’t tell that unless you ask.
Pawel Brodzinsk, Agile Bullshit: Agile Is Good, Waterfall Is Wrong
Digital agencies tend to go Waterfall in the beginning in that you conduct requirements gathering, produce sitemaps, wirefames and a functional specification, all in sequence and with client sign-off as a pre-requisite for moving onto the next phase.
But then they often go slightly Agile during development as the budget remains fixed but the client is usually free to request higher priority features not thought of or needed at the specification stage and the agency will allow them in as long as impact on timelines and cost are addressed or other features in-scope are moved out of scope.
We can’t always work agile, and we can’t always work waterfall. We can work Agifall (I totally did not coin this, but love it)…or some sort of hybrid. I like to think that most web project managers who work with full UX, Creative (design and copy) and Development teams adapt each experience to their clients’ needs and the project needs.
Brett Harned, What’s The Difference
Then once a web project is live and a new pot of money exists to refine the system, you’ll rarely see a full blown functional specification for each new feature. The pot of money will be used to implement new features in isolation, put live and then move onto the next one until the money runs out, and if you’ve done your job right the client has received massive value from the features.
These approaches are very much not Waterfall, but that isn’t to say Agile doesn’t have its place…
Agile is for suitable for some
While not trained in Agile and therefore my opinions carrying little or no weight (oh well), from the research I’ve done, in general I believe Agile (or as some douche bags would mistakenly call it, the 37signals way) is suitable for large web application projects, especially internal ones that are constantly being refined, or anything that ventures closer to software development rather than website development.
It requires several things that smaller companies and projects rarely have e.g. a dedicated production team for the whole project, less emphasis on creative and design work upfront and very heavy client interaction to provide timely feedback throughout the project.
I used to work a lot with Nokia and they continually developed their global CMS using Scrum and it was perfect. Perfect because they had a huge core system in place – local agencies and other stakeholders would submit feature requests, they’d analyse them, determine what the priorities were and develop the features one by one in sprints.
Agile is often banded around as the “cool” way to do things, but when I question anyone seriously on it, the only people who seem to be successfully using it in the way it was intended are those who work on web projects that are big and are based on a large core system that is constantly being updated and refined.
People wanting to “go Agile” should be fully aware that it’s not really something you ‘try out’ in my opinion. Instead you could look at something like Kanban as a lightweight Agile style to trial before considering a full move – a full move to Agile is a very big strategic decision that requires a lot of change management, training and discipline!
But ultimately, and again I quote Pawel Brodzinsk, there is no ‘better’ web project management methodology, if it gets the job, leaves clients happy, is of high-quality and your business is making a profit then however you’re doing it is right!
You can do an equally crappy job under the banner of Agile as under any other. You can tell Waterfall stinks because Scrum is a thousand times better. Or you can tell Scrum stinks because Kanban is a thousand times better. And both will be equally false. On the other hand if your teams are well-organized the name of your approach is third-rate. You will deliver and will deliver quality. And yes, I’ve just said you can do it perfectly using one of old-school heavy-weight approaches grouped under the infamous ‘Waterfall’ name.
Pawel Brodzinsk, Who Cares If You Are Agile?
It may appear I’ve gone slightly off topic here but it’s all related…
Bringing it all back on topic
Ok, so I’ve wandered into the treacherous area of discussing Agile and Waterfall methodologies and their suitability for web project management in digital agencies, dangerous waters indeed, but it really is all to do with the point in hand.
The point being that I see and hear a large number of very talented people in the web community shouting and screaming that an Agile approach is the way to go.
But when you question them in any amount of depth the substance behind their argument is often based on a rather naive belief spawned from reading a few blog posts and books from some incredibly cool and successful guys like 37signals who preach to not over plan, or Andy Clarke who says to forget Photoshop and start mocking up concepts in HTML for the client – to just get building and adapt as you go.
But while reading these great articles they fail to recognise these guys are not giving advice on how to deliver web projects to clients in a digital agency environment, but how to run a business, develop a product or engage clients if you’re talented enough to be able to design and code to world class standards – not something many people are.
If you question them further on what they believe Agile actually is you tend to then get a few mumbles about “no functional specification” and “let’s have 15 minute stand up meetings” but not much more than that.
It’s at that point you realise these people are actually just repeating what they’ve read online and assuming its good because it’s said by ‘cool’ people and they want to be “cool” too – a totally understandable human trait, but dangerous if a Managing Director bases an agency’s strategy on it!
But just remember, being a good Web Project Manager means you possess the power to be incredibly empathetic, so put yourself in the developer’s shoes for just a moment and remember there’s always two sides to a story.
A developers perspective
I can’t help thinking however that when you get someone who clearly doesn’t understand 37signals or Agile speaking out about the benefits of it and how it should be adopted immediately, it doesn’t necessarily mean they’re just naive fools who have a lot to learn, but maybe it’s more sincere than that.
I believe a big reason these guys n gals latch onto Agile or 37signals-esque approaches is because they see it as a chance to skip all the ‘boring’ parts of their job!
Web developers who are passionate enough to keep up to date with people like 37signals, hungry enough to buy and read books like Rework and brave enough to speak out are almost certainly massively talented themselves and very creative people, and to them, functional specifications, prescriptive work broken down into features with defined functionality that’s been signed off leaves them little room for creativity and must make them feel like nothing more than robots at times – not a worse situation to find yourself in as a creative person.
So when they hear of a way of working that appears to cut all the boring parts out of their job and allows them the freedom to just get on with developing straight away it’s no wonder their eyes widen, their ears perk up and they want to jump all over it!
But even within the confines of prescriptive work and functional specifications, it is possible to let your team have some freedom, some room to experiment and bring new takes on already agreed functionality to the table – it’s your job as a Web Project Manager to listen to these ideas and if they sound great then to potentially rip up that part of the agreed scope and propose the new idea to the client and get approval.
Rob Borley hit the nail on the head on this subject in his latest post and really I want to quote it all here, but I think that’s naughty so I’ll just give you some highlights but it’s really worth reading.
Let them in on the solution. It can be tempting at times to solve (or try at least) all the problems yourself. It is much better to get your production team (designers and developers) in on the act as early as possible in the project. Allow your team the time and space to express themselves. Allow them to be creative; to try a new technique in a real project situation. Build some time into your schedules to allow for this kind of experimentation you will have a happier, more enthusiastic and, ultimately, more productive team.
Rob Borley, Give Your Team Room To Express Themselves
So before I get ripped apart in the comments section by developers and actual qualified Scrumasters, please note that I do know many people who work in digital agencies who adopt a proper Agile approach like the cool kids want and things work out great for them, be it on websites or web applications for clients – it most definitely can work.
All I’m asking is that the next time you hear someone demanding that they go Agile, to question them in depth about why they think it would be a better approach than they’re currently using, what they think Agile really is – and if at any point you hear well known agency names used to back up the theory, look into those agencies, find out what kind of work they do, do they work on large-scale web projects or knock out small to medium websites and web applications for clients.
Find out if it’s just someone saying what they are because they think it’s cool or if they really have in-depth knowledge and can put forward a great business case for the switch. Or perhaps consider it’s just a cry out to be given more freedom in their work, it could be their desire to be creative in their solutions just dying to get out – if so, try to facilitate it in your role as Web Project Manager, you’re in the perfect position to make that happen and it will almost certainly be beneficial to everyone.
But, if at ANY point you hear 37signals being held up as the ultimate piece of evidence that confirms how an Agile (less planning) approach works, please smack them on the botty, sit this person down and explain the differences between running a business, developing products and delivering websites and web applications to clients!
Working without a plan may seem scary. But blindly following a plan that has no relationship with reality is even scarier.
Quote from Rework
True for a 5 year business or product plan, not true for good web project plans. Ok, let the lynching begin…