You are here

Agile and Web Development

 

For years at Moore-Wilson, we have believed that careful project planning and management ensures successful delivery, happy clients and therefore repeat business.

 

Tradition told us that if a project was dissected thoroughly and documented carefully and accurately long before any programming or design work was done, then by sticking rigidly to the plan, we would never be in a position where the budget or timeline was out of control, or the client didn’t get what was agreed at the beginning of the project. So, traditional planning and execution sound ideal for the web world doesn’t it? The more time you put into the thinking and planning up-front, the less room there is for the project to go wrong. Not necessarily.


The problem with pre-planning in great detail means that one of two things is likely to happen; you are unable to accurately document every last detail of what your client has in their mind (either because it’s hard to do so or there simply isn’t the budget to do so), therefore the delivered solution has a risk of not meeting their expectations. Or, you do plan in meticulous detail, spending 25% of the budget on some really detailed scoping, but this removes any flexibility in the project and essentially takes any control away from the client (they’ve signed the specification; heaven help them if they want to change it!).  Everyone knows the dreaded ‘scope creep’ that inevitably works its way into projects and with traditional project management either your agency’s bear the brunt of the costs, you tell the client ‘no’ or present them with an unwelcome extra bill.

 

As the scale of projects has increased from being one-man development and management solutions to large, multi-team solutions, isn’t it rather presumptuous of an agency to think we can accurately plan the full solution up-front in minute detail? Even if we can, should we put the pressure on our clients to know the smallest of details of what they want months before they get it? Furthermore, should we then penalise them with when they start to see the project take shape and realise it should work differently to how they first envisaged? It’s not effective project management if the budget or timeline is extended even if the agency can plop the signed-off specification back in front of the client to remind them of why their changes are costing money.

 

Luckily, Agile not only changes the way we plan projects, but also the way they’re developed and deployed. As a methodology, it’s appropriately named as Agile allows for projects to be well planned and for the work to be measured accurately, whilst allowing for a huge amount of flexibility. The client is also encouraged to keep a firm grip on the control of the project.

 

Agile doesn’t do away with any up-front planning at all; you still need to establish a project timeline, budget and overall vision for the solution, but that’s really where the up-front planning stops and production begins. It’s not quite as ‘jumping in feet first’ as it may sound; there is detailed planning required just not too much of it at once. Instead, the client team and the project managers agree to prioritise the functionality of the site and agree on the order in how it should be delivered. Early discussion with the development and design teams ascertains the expected effort that each of these high-level bits of functional theory are likely to take to deliver (so a timeline and budget can be created). Once the full list is established, the client and project team take the first few (highest priority) items from the list and plan the functionality in detail.

 

This method of only planning the next most important thing in detail means the client and agency is only defining the next most important piece of functionality remaining, meaning the client can choose to allocate more or less budget by changing the deliverable (or if the agency has underestimated the requirements they can quickly bring the client in line with the change). Only once the client accepts that the functionality has been delivered do they move on to the next priority.

 

Control is a major aspect of planning. If a client chooses to put more time and effort into the current functionality (and why wouldn’t they? It’s the next most important thing on the list), then Agile methodology means they quickly see the impact this change will have on the budget (if there’s no more money then think about which low priority functions will come out), or timeline (if there’s no more time then think about which low priority functions won't be ready by the deadline).

 

It’s all very well and good to plan projects in small, prioritized chunks, but how does your development team deliver functionality in small chunks? Well, it’s a fairly major change for traditional agencies to work to Agile development methods. Instead of teams of developers pawing over a large specification, and agreeing to deliver functional aspects on a long timeline with several milestones (most towards the end of the production from our experience), teams work in iterative bursts agreeing to take on a series of functions they believe they can code, test and deliver before the end of the short period. The production of the whole solution is split into a series of iterations (known as Sprints) which typically last anything from 2 weeks up to around a month depending on your company and the size of the project.  Prior to each Sprint, the client and project managers decide on which functionality they would like to see next (what is the next priority) and then the development teams agree to deliver what they can. Delivery with Agile means complete, working, tested code. i.e. if the client wants to see an events system working, the developers deploy working, tested event code for the client to review (and if necessary extend and through back into the queue). So production is in line with the planning; the client only focuses on the next thing they want to see and the project teams focus on delivering that by the end of the iteration.  It’s highly effective teamwork across the agency and the client is expected to join that team for the duration of the project.

 

Agile creates happy clients with solutions that are highly tested and expertly built, but above all, lovingly shaped by that client. Agile creates happy project managers because the need to keep a detailed focus on an entire project is reduced; just maintain the vision and focus on the most important functionality left in the queue (the iterative process means risks to budget or timeline are seen quickly).  Agile creates happy developers because it ensures they are kept informed of the current expectations, they have the support of their team, and real clear-cut goals to deliver every few weeks. Agile creates happy management too, largely down to how effective your staff are and how happy your clients will be.


Agile is a leap of faith for many agencies, but at Moore-Wilson we recommend the process. If you wait for the right opportunity to come along and change to Agile it might never happen, and change is never easy, but in the long-term Agile offers the flexibility a web agency needs to grow in our highly dynamic marketplace.

 

Martin Porter 2010 (C)

 

If you’d like to find out about the services that Moore-Wilson provides, please click here, or contact us to discuss an upcoming digital project.