RSS
2 Aug 2010

The 37signals Planning Philosophy Mistake

Author: thesambarnes | Filed under: Web Project Planning

An interview with 37signal’s David Heinemeier Hansson in this month’s .net magazine inspired me to finally write an article I first had the idea for after reading Rework.

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!!

An on purpose badly drawn meter that has Web 2.0 companies on it such as Google, Flickr and 37signals

The Web 2.0 cool meter (probably can be coded in CSS3)

Image source

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.

An 1970s black and white photograph of badly dressed office workers

The Waterfall Project Management team as seen by developers

Image source

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.

A screenshot of two of my Tweets from May saying I was worried about how people will interpret planning after reading Rework

Actual real proof that could be used in a court of law

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.

A screenshot of the first slide of Paul Boag's No Money, No Matter presentation

A fantastic presentation by Paul Boag, defintely go and watch it!

Image source

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.

A screenshot of Martin Crockett's Tweet from saying that digital agencies saying they use Agile are lying

Digital PM Martin Crockett is known for his diplomatic manner

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.

A screenshot of Andy Clarke's article on last year's 24 Ways website

Although I don’t agree with Andy, he looks way cool

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

In summary

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…

A picture of two toy monkeys playing with the head of a Stormtrooper toy

I’m pretty sure code monkeys will do this to me one day

Image source

Related reading:

This entry was posted on Monday, August 2nd, 2010 at 12:58 pm and is filed under Web Project Planning. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

30 Responses to “The 37signals Planning Philosophy Mistake”

  2. Great article.

    I’ve read up a lot on scrum, and have always had trouble imagining how to apply it. I am the PM on a small (5 people, but growing) digital agency. We mostly do projects in the size of $3000-15 000 range, and I have a really hard time seeing how we could benefit from going agile. We don’t always plan extremely thorough, but in my experience, most of what you mention is very easy for me to recognize and agree to.

    Scrum sounds very promising, but for small to medium web projects it is (or atleast seems) hard to apply.

  4. Sam, I like your article hear, it’s well thought out as always. In a recent proposal to a client I described our process as basically

    Waterfall => Agilish => Waterfall

    Where that represents planning & requirements analysis => design and development => testing and launch

    In my opinion both ends of a project need proper planning, waterfall style executions for successful delivery of web projects for a client. You can’t really ‘do agile’ on planning – it always comes down to a step by step process. In the middle though, knock yourself out!

    Finally it also doesn’t mean that whilst planning, a specification document doesn’t go through a series of quick iterations before sign off (very agile like) but each step comes one after the other?

    Bit of a ramble? Yes. Make sense? Not sure.

    Good article Sam.

  6. @Adam, pleased you liked the article. It’s defintely a good idea to research all different types of methodologies, especially when a small agency as you need to be really flexible on a client by client basis!

    @Rob, cheers Rob, you’re dead right about the planning at the start AND the end. I think I’ve only ever managed to close down web projects using a very structure end game – any deviation somehow always turns into the project crawling to end painfully slow.

  8. Great article Sam,

    I totally agree with you, I’m a big fan of David Heinemeier Hansson and 37 signals, but I do think he has a tendency to expect that his model fits all other businesses.

    Whatever the case I think they are a great inspiration for anyone building a web apps business. It challenges people cut to the meat of things, build, don’t procrastinate and most importantly, be realistic, keep your expectations in check. I’m sure we all have plenty of examples of people who want their projects to run before they can even walk.

    It doesn’t apply to all cases though, “just getting things out” can literally break your company if you aren’t careful. Planning, is absolutely essential if you want to avoid losses, when projects can carry this amount of risk (i think this applies for most agencies).

    I find methodologies like agile or even scrum work only when you have a team that works well together, and they are the only stake-holders in the project.

    Agile and scrum, are also good methodologies for fixing a broken client project. Not starting it.

    In agencies, the waterfall model works best. You just need to refine it each time to make sure it works for you and your clients. Rigidity can be avoided by building in some flexibility, such as defining feedback/input points, and iterations if clients doesn’t like something. At the end of the day your goal as an agency is to keep your client coming back and make a profit off each project. Some rigidity is a necessary evil.

  10. @Dimitri, you just got across all the points I wanted to, in a better way and in half the words – I salute you! :)

  11. Amy Grange says: August 10th, 2010 at 2:11 pm

  12. Great article, I was questioning my PM methods as I would be similiar to what you describe as Agifall! I would agree with everything you say where when you have a fixed price you need to detail what you can deliver or else it can ruin the project and relationship with the client.

    Really enjoy your blog!

    Amy

  14. @Amy, thanks so much :) and believe me I know the feeling of questioning you’re own methods, in a way it’s why I started this blog in the first place. I was running things a certain way that I’d developed to fit a small digital agency’s needs but it wasn’t one I was reading about, it was Agilefall!

    So I start a blog expecting to realise I am alone but no, there’s loads of us out there and many of us have organically developed a similar ‘methodology’ – it’s nice to realise you’re not alone huh :)

  16. This post reflects where I am with regards to project management techniques and software development methodologies. We’ve just completed a project that finished a little late and over budget (I was PM and front end development). In the development of this project I used the waterfall approach. Truth be told it is all that I know and has stood by me many times in the past.

    This time however there were a number of requirements that weren’t realised until during the development of the actual website. In reviewing what went wrong and how things might be improved going forward I see no need to use anything other than Waterfall. My improvements simply involve better handling certain elements of the project differently. I’ll not get into those here as that’s an internal thing.

    Time and time again all I hear about in the development of modern web projects is ‘agile this’ and ‘agile that’. So I’ve been looking into that. At a very high level it seems like this idea of Agilefall would be the best method. By which I mean running the project at high level using the waterfall technique (reqs, specs, dev, etc) but using agile for the actual development phase of the project. However I do not know enough about Agile to know this for a fact.

    I am now researching agile in more detail (‘Changing Software Development’ by Allan Kelly arrived in the mail yesterday) to see if I can understand it better. I am very curious to see how this plays out.

    Excellent article by the way! Very interesting.

  18. @Gareth, more interesting to hear how many of us feel and work the same huh! Thanks for you comments :)

  20. 37signals has done some incredible work and has paved the way for the rest of us web-based application developers to launch and grow successful products. But to blindly follow their philosophy is silly. You have to filter their writings through your needs, and when you do that, their views are not 100% applicable. We’ve ended up with a thousands of web sites that are basecamp clones redressed to represent someone else. But I think it’s time for someone to take the torch from 37signals and move on to the next thing, which in my opinion, is ending this trend of oversimplifying everything.

    Thanks for the thoughts. I am sure they resonate with a lot more people than you think. We’re just not as vocal as the fanboys.

  22. @John, too true. As with many topics I find there’s a lot of people who are of the same opinion but just aren’t as outspoken, or more to the point don’t know of an appropriate place to air their views, as opposed to the countless places to agree with trends.

    Filtering what thought leaders say into a a version that fits your particular business is crucial in taking away what you need and moulding it into a valuable exercise.

    Thanks for the comments John, wise words.

  23. Rob Stanford says: August 24th, 2010 at 9:53 pm

  24. Hi Sam,

    I have to say disagree with you on this one! I have been using an Agile approach for a little while now on a number of web projects for clients and have found it to be really successful.

    Our projects have only two phases on the critical path: planning and production. Planning incorporates Discovery and IA. Production incorporates our development sprints and testing. (We also run a design phase in parallel with our planning.)

    The key, in my opinion, is remembering that less planning isn’t *no* planning – ‘barely enough’ planning is what’s required. I still write a functional spec during the planning phase, but only include enough detail to get us by. The spec allows us to estimate with acceptable accuracy and to inform the client of the proposed functionality without going into deep detail that will likely change later on.

    Just because you are writing a functional spec doesn’t mean you’re not being Agile. If you’re doing your best to keep documentation to a minimum in favour of collaboration and working software, then you’re being Agile.

    Cheers for the thought-provoking article nonetheless.

  26. @Rob, I actually want to hear from more people like yourself who do disagree!

    So you guys start production with signed off designs and a high-level functional specification? Do you have separate front-end and back-end developers or developers that do both? How big is your company and what kind of projects do you do?

  27. Rob Stanford says: August 26th, 2010 at 4:54 pm

  28. Hi Sam,

    Our aim is to start production with the minimum of planning. I find that the sooner we show concrete work to the client, the sooner everyone engages and the more time is available to steer the project correctly.

    With that in mind, we run a short planning phase which begins by identifying goals, users and key user journeys with the client. I write this up as a list of high-level ‘user stories’ that we refer to as the functional scope. From this document we sketch a site-map and do some paper-based IA sketches, only for the more complex user stories. We then review with the client and begin a second iteration, using their feedback to refine the aforementioned documents. (During this time we also design a look-and-feel for the site based on two or three key pages.)

    This is usually all the planning we do before beginning production.

    At the beginning of each production sprint, the user stories to be tackled are fleshed out in greater detail and discussed with the client where necessary. We ‘design on demand’ within each sprint as we understand the requirements more completely. We also test fully at the end of each sprint so we can show a fully working subset of the site to the client without undermining confidence.

    All of this helps us be reactive to our clients changing needs without wasting time up-front planning features that change or are thrown out in favour of something different / better.

    Hope that makes sense! I’d be interested to hear your thoughts. I work for a small agency with 3-5 people on a project at any time. We find it works best separating front and back end dev, though that’s not always possible.

    Cheers, Rob.

  30. @Rob, thanks for the detailed response… really really interesting. If your 3-5 people work on the project together I can totally understand how this production cycle works for you as you’re all on the same page – often in small agencies those 3-5 people will be working on 5 projects and just not have time to be so co-ordinated.

    I really like the sound of your “relaxed” approached to planning though, it’s not a method I can map to any previous projects I’ve run and think “that would’ve worked”, but it clearly works for you so kudos!!

    Has this ‘lack’ of definites ever caused you issues with any projects? Such as a client pushing a little to hard for scope creep?

    I’m wondering if it’s just a completely different approach that if explained properly to the client, and managed well, can be just as effective – or is it the clients you have just differ from most I’ve had… are you working with start-ups mostly?

  31. Rob Stanford says: September 1st, 2010 at 11:27 am

  32. Hi Sam,

    The media and entertainment clients that I’ve worked with (Virgin, Sky, BBC, etc.) have all been keen to take an Agile approach. Likewise with the not-for-profits and charities. Those that have refused to work with Agile tend to be public sector clients, such as local councils.

    I believe an Agile approach can be beneficial for any project and the only obstacle to making it work is the structure of the client organisation.

    If I am working with a small group of project stakeholders, it is easy to explain the advantages by saying, “rather than use all the planning budget at the start, we think it would be beneficial to start production earlier and save some of the budget so that we can be reactive to your needs as the project progresses.”

    This is far more difficult if there is a complex hierarchy of managers and approval boards all hungry for documentation. This is the case for many local councils and the reason I use a waterfall approach in these cases.

    Regarding scope creep, I think it’s more of an account management issue than a planning issue. Regardless of whether you have an infinitely detailed functional spec or a high-level one, if the client wants a feature that’s not in there, should you do it? No, if it represents a new user story or doesn’t help achieve the project goals. Yes, if it’s relevant, if there’s time and if it improves the client relationship.

    Basically, having a high-level functional spec protects you from huge unplanned feature requests. Any disagreements over the smaller stuff won’t derail the project and comes down to an account management decision I think.

    What are your thoughts?

    Cheers,
    Rob

  34. @Rob, my thoughts are that your methods actually sound pretty sound, and to hear you will switch to a more Waterfall approach if need be more backs up your credibility of being a real world man :)

    I must say I’m intrigued… I’m starting to think that with the right foundations set down between client and agency it is possible than I thought to use a kind of Agile approach.

    A recent project of mine actually had no real budget for a full on spec and so a very high-level one was produced, as you say, to nail down the big rules (scope) and I simply made it clear that during development it would require both parties to just take a realistic attitude to any change requests – and what do you know, the project went well and the client was exactly that.

    I’m thinking that perhaps I’ve worked in a more Agile way than I’ve realised in some cases – maybe it does depend heavily on two factors, the management of the process and the client, and having the right client.

  36. Interesting reading. I’m an enterprise Java developer with years of experience in agile development. I’ve spent the last 10 years working for software development companies to produce bespoke software. Six months ago, after my then employer canned their next generation software and all the dev teams, I started work at a digital agency. My role is to manage existing Java projects, architect, design and implement an idea they have for their first ever bespoke software, and to introduce agile methodologies. It’s now become painfully apparent that the management structure here is naive and incapable of any proper management. Apparently, it is “rare” for people to work overnight, said one of the account managers, adding that in the last year they’d only had to do 4 overnighters. So alarm bells started ringing for me.

    The first work I did for them was produce a Java web application which had been severely underestimated by several orders of magnitude — way before I started. However, the deadline was fixed, and after a lot of effort on my part, it was delivered only a week late. All interested parties were informed of the underestimation and progress along the way, but it was a case of “la la la, we’re not listening”. The late delivery wasn’t good enough so I got a black mark against my name. Left a very nasty taste in my mouth.

    Nasty taste number two followed not long after. An account manager had quoted a client 6 days for adding a live news feed to a website, I guess, sometime in September. Beginning of October I was told that one of my developers was going on a training course for a certain CMS as the client’s web site was built with it. The course was a week and wasn’t anything to do with developing with the CMS Java API which we’d need to use. The expectation from the account manager was that my developer would return from the course and then spend the next 6 days implementing the live news feed. Extremely unrealistic don’t you think? Oh, but where’s the spec? Umm, there isn’t one. A spec eventually appeared on Oct 18th. The client has yet to review and sign it off. So, the last week and a half has been spent on the steep learning curve of the Java API and implementing pieces of the puzzle to prove we can do it — one of the CMS consultants said we were doing something rather difficult and he didn’t think it was possible so that we were on our own. Of course we had to discover sooner rather than later if it was at all possible.

    Despite the account manager continually checking up, knowing what we were doing, the whole spec was suddenly meant to be finished this week.

    Now they’ve decided that we’re not going to use the CMS API. So I’m off the project and one of the “traditional” developers at the company (i.e. PHP/MySQL sites and not Java-based ones) is taking over so that they can do one of the biggest hacks in history: introducing a PHP/MySQL stack into the client’s website. If I were the client, I know what I’d say.

    So, in my 6 months experience of working at a digital agency, I cannot in all seriousness ever recommend working at one. I can’t resign from here soon enough.

  38. @Java Biker, wow that’s some comment! But for some reason I find hearing stories, any stories, or other digital agencies fascinating (part enjoy the business aspect and part the gossip side I think :)

    Regarding warning bells on hearing an agency never pull ‘overnighters’… I actually cant agree with you that this is always a bad sign – often it’s a good sign of company organisation / respect for employees. In my experience if a company constantly has to ask employees to work overtime then it’s a warning sign that something is very wrong somewhere in the organisation and needs addressing.

    However, the fact you worked your socks off to deliver something that was underestimated and only delivered one week late sounds good to me. But just to put it out there, perhaps you were communicating your points in a way they didnt like rather than being wrong in what you were saying? I certainely have learnt the hard way on this one – always consider that’s the case.

    Now onto bitter taste #2… this just sounds horrible and you know what, sometimes in digital agencies this kind of thing just happens. In this particular case it sounds like a failure in multiple areas, but one thing you can always be sure of is failure at a project / account management level will always fall on the production team hardest.

    All I can say based on what you’ve said is it sounds like a rather poor quality management job done for this task and even worse communication.

    If I was in your shoes I would probably bite my lip and raise this as an issue with my line manager, but I would bet they already know about the issue and have had discussions about – if they havent, then youre absolutely right to want to leave, but I would say that NOT ALL digital agencies are like this!!!

    Sure they’ll be some serious breakdown in communications at one stage or another in any agency, as well as the occasional “WTF FML” moment, but I’ve never heard of any company that doesnt have these to be honest – the only thing I would say is if you really cant handle working with those kind of events happening you may be someone who is best suited to a corporate development environment? Somewhere with a lot of order and hierarchy? You may not get the advantages of working at a digital agency e.g. variety in work, deep end learning, project ownership etc. but you may get what you seem to be after, high levels of clear accountability on projects…

  40. Confusion leads to confusion. You can’t blame 37 Signals when it’s the noise than the signal that confuses your insight to claim a ‘mistake.’

    The noise are the folks that jump on the wagon; these folks are everywhere jumping on the next big thing without hesitation to go a mile to understand the inherent principles and fundamentals. They negate the scenarios and option to trial and error; opting to shout to the masses as if a t-shirt saying ‘go agile’ is going to make them friends.

    In fact, Agile is a value or principle it is not management. People and collaboration over process and tools is not management of a project; it’s a principle, holistically a value to hold on to.

    Agile Project Management isn’t scrum, as scrum negates the Business and Project level hierarchy of a project; you must not forget scrum is only the delivery layer; a project has 3 layers.

    I’m using scrum for the delivery, and DSDM for the Project and Business Layers. It applies agile values with rigor of stakeholder processes and planning, though light. It hits home the content than context which costs the delays. Blind process is avoided.

    I couldn’t recommend DSDM enough. 37 Signals applies only principles and values; it’s up to you to take them and allow that to assist your methodology and methods in project management.

  42. @Alex, thanks for your comments. Don’t get me wrong, I don’t think 37Signals have made a ‘mistake’ – far from it. As I say in the article I think they’re amazing and shine a much needed breath of fresh air on the digital industry from a commercial perspective.

    I also agree with you about the folk that will jump on any band wagon, and this article was targetted largely at them as a bit of a wake up call.

    As for Agile being about people and collaboration, yet again I agree completely, however, there are many out there who would not see this as “being Agile” by the mere fact there are not 15min stand up meetings or if they see a GANTT chart at any point during the web project.

    The fact you distinguish SCRUM from Agile shows you were not really the target for this article ;) As for mentioned DSDM, well, now you’re using big words my friend :)

    I like the look of DSDM but would be very curious to hear what kind of projects you typically work on Alex. On paper DSDM looks like something that could work well with larger clients rather than start-ups.

    Look forward to your reply, or if you’d prefer I could send you a Web PM interview sheet and publish it as an article where you could champion DSDM…

    “37 Signals applies only principles and values; it’s up to you to take them and allow that to assist your methodology and methods in project management.”

    A perfect summary :)

  44. I don’t really have something to add here… sorry.

    Just want to thanks Sam and other commenteers for the great insights I had after reading you all!

  46. @Bruno, you’re welcome :) Nothing wrong with just saying thanks!

  48. I totally understand about the desire to just roll up your sleeves and dive into a project with the Agile approach. It really is “cool” and appealing. In addition, I can totally appreciate the desire to bypass the arduous planning process in lieu of getting down to business. Let’s face it…it’s fun to create! It’s true, many a plans are wasted on ideas that never come to fruition. I hate that!

    However… I think we can just put our stock in that age old adage “measure twice, cut once”.

    “Do your planning and prepare your fields before building your house.” — http://bible.us/Prov24.27.NLT

  50. @Craig, you explained the point of my post in a couple of paragraphs – I must work on my efficiency ;-)

  52. I think, in short, Agile just doesn’t deliver value unless it is set up and run by the book. If you half-arse it – it just doesn’t work.

    You do plan in Agile – but you do it almost constantly. This freaks out clients. They don’t want you to plan every two weeks or every morning – they want you to tell them how much it will cost and how long it will take at the start. Then they want you to just do it – without bothering them too much.

    What I do think Waterfall can take from Agile, with regards to planning, is user-story based ‘features’ and ‘acceptance tests’. This keeps things in the domain of the real world and provides a language where the client, developers and PM can understand what’s being created, how well its going and how you know when you’ve got there.

  54. @David

    I completely agree with you. Some aspects of agile – be it scrum, kanban or any other technique – are very good, and could easily be implemented into waterfall.

  56. @David, you’ve summed it all up in three paragraphs :) as usual it took me two million pages to communicate that very point – I need to work on my efficiency!

    @Adam, absolutely agree. I’ve not yet come across a digital agency who uses Waterfall in the traditional sense at all. The less informed think it is because there are defined phases that run sequentially, but in reality in each of these phases there’s all sorts of iterative techniques going on.

  58. Great article.

    Just as you can have bad waterfall development (which led to the creation of agile methods), you can have bad agile development. Humans can distort anything, no matter how practical or noble.

  60. @John, I totally agree, but it’s rare you find those “cool” folk complain about bad agile… usually because it’s not true agile, or because they don’t actually care and just want to be able to tell people they work “agile” :)

Leave a Reply

Follow me on Twitter Connect with me at LinkedIn Subscribe to my Delicious feed Follow Global Personals Follow Volume Follow Rawnet.com