22nd March, 2010
Process Toolbox, part four: Methodology
Time for the fourth of several excerpts from my @Media The Process Toolbox presentation. So far, we’ve looked at backbone, collaboration and audience. Now we can begin to refine the appropriate methodology.
In an ideal world…
Here’s a contentious approach that doesn’t always work in the real world. We know that we must often agree a budget and deliverables before work begins, and therefore it is rare that a client will trust a web team to make major decisions about exacting methodologies and deliverables once the process is running. It requires both sides to take a leap of faith at the very start.
Client collaboration is again key here, and should be valued over laborious contract negotiations because all parties need to be working toward the same set of goals. Yes, contracts are necessary, but the terms and details in a contract can exert great influence on whether the different parties are embarking upon a collaborative or a competitive effort.
So, after we gain an understanding of a business and its audience, we are faced with considering how we will use this research data to come up with a successful website.
And what kind of methodology will we use? It’s my belief that this decision is difficult to make at the early research stage. Often, only once a deeper understanding of the overall goals, and the needs of the intended audience is attained, can we make a decision on exactly which methodology to work with.
Sometimes a project will start, and there will be deliverables along the way, then it will end. Occasionally, we’ll need to manage projects as a series of phases. Some phases depend on the outcomes of others and therefore are worked one after the other, while others can run in parallel. There are many possibilities.
Waterfall: Research, process, build, test, launch, pub.
This is the most traditional project management methodology, usually referred to as a “waterfall methodology”, and it would be divided into recognisable phases such as Specification, Design, Build, Test, and Launch, each dependent on the outcome of the one before. Its referred to as a waterfall because development is seen as flowing downwards through the phases. The problem is, its all well and good doing so much upfront planning in the Specification phase, but when you get to the Build or Test phase, what happens if you realise you’ve planned for the wrong outcomes, or that the design you’ve created doesn’t quite work now that the site is being built? Its very difficult to go back up the waterfall! Still, many often find themselves working this way.
Agile: Research, process, build, test, launch, pub. Learn, repeat, relaunch, pub. Learn, repeat, relaunch, pub...
“Agile” means many things to many different people. Most likely, it means working in short iterations rather than using major phases. It is important to collect early, frequent feedback on each release and the processes, and then iterate, repeating aspects of key processes, building upon what has been learned, and ultimately releasing a better and better website over a project’s lifecycle.
Agile methodology is a response to change because our focus is on delivering as much value as possible to the project’s client and users. Rarely will users know every detail of every feature they want. It is inevitable that users will come up with fresh ideas, and perhaps just as inevitable that they will decide that some features they want right now will become lower priorities later.
For example, maybe an initial simple site should form the first “release” with the base level of user interaction required to meet business goals and audience needs. Of course, even a simple release needs to be thought through carefully, and measurably effective - but with room to develop and grow through further releases. With an Agile approach, everything remains open.
Sprint: Pub. Build, test, launch. Pub. Nervous breakdown.
I’ve little to say about the Sprint approach. It doesn’t appeal to me, but can be successful if the client and web team can collaborate effectively and swiftly through the discovery stages. In my experience, its usually the audience who gets left out of the collaboration. They often simply get what they’re given.
Process Structure: Rinse and Repeat
Ideally, we can design a relevant agile process, embark upon it, and then iterate that process, rinsing and repeating key areas of the process as feedback and understanding builds with each release, so we’re gradually releasing better products with more relevant tools or refinements.
Note: Slides designed by Gregory Wood.
- Part one: Backbone
- Part two: Collaboration
- Part three: Audience
- Part four: Methodology
- Part five: Roadmap
- Part six: Creativity
- Part seven: Convention
- Part eight: Prototyping
- Part nine: Narrative
This article was originally posted on Erskine Labs, September 2009.