Post-agile Project Delivery, Part II - The Mitigations

As promised, here’s a follow up to my previous blog on problems we’ve encountered using Agile-scrum methods when working as a distributed agency delivering client projects. In this instalment I’ll take a look at some of the modifications we’ve made to standard Scrum, to address those problems.

Photo of Steve Cowie
Fri, 2014-03-14 11:12By scowie

Audit for Agile

Before even starting a project we'll decide if it's actually suitable for Agile. As I pointed out previously, there are potentially indicators that a project can't be done Agile, such as the absence of a product owner or lack of scope for iteration. If a project doesn't lend itself to Agile we can forget a time & materials approach and go straight to a fixed-price, fixed-specification model. There may be aspects of Scrum process that we retain, such as having daily scrums, but we won't pretend that we're doing an Agile project just because we have stand-up meetings.


Planning and documentation

The Agile manifesto lists a set of values that underpin Agile thinking and two of those are valuing “Working software over comprehensive documentation” and “Responding to change over following a plan”. It’s no surprise that developers like these - who wants to write documentation or spend ages planning before you get your hands in the code? It’s not even surprising that clients might like them because clients are often in a hurry and like the apparent increase in speed that’s promised if you don’t have an extended planning exercise at the start of the project. Also, in our experience, clients are often convinced they’ve done all the necessary planning so why would they be paying us to do a load more?

I reckon both the developer and client are wrong here. What else would you do in life without planning? Even a visit to the pub entails deciding on coat, remembering your keys, fixing a time, maybe calling someone. Why on earth wouldn’t you be planning a software project?  I get the point that too much planning up-front may be pointless because you’re making plans when you don’t know how things will shape up, but for a lot of web projects that’s not really true. More often than not, we do actually know what we’re building, how long it should take, and how much money is involved. If that’s the case you might as well plan the project, and document it.

Our documentation will typically take the form of a project business plan, registers for risk and complaint, meeting agendas, user stories, technical implementation plan, and change log. The business plan could also be described as an implementation plan but we quite deliberately describe it as a business plan to emphasise the point that we are invariably building web applications that have a business goal in mind. Given that, we should define the goal, explain how what we’re making fulfills the goal, and how we intend to review it once the project is complete and in production.

I won’t go through every component in the business plan for now but some key highlights in relation to Agile are the communication plan and the MVP statement. The communication plan describes how the project will be documented, how project members will communicate, and how meetings will work. As a minimum there will be both a daily stand-up and a weekly management meeting. The stand-up will follow the normal scrum format of “yesterday I …, today I …, blockers are …”. The management meeting will vary but we’ve found a really good format is to have a single document for both agenda and minutes that gets updated each week. Whatever the format, a fixed component will be a review of the project’s Risk and Complaints register. Going back to the risk register helps the team to stop kicking the difficult cans down the road.

Possibly the most important part of the business plan is the statement of minimum viable product (MVP). We use the MVP to bridge the gap between fixed specification and time & materials based costing. The idea is that a project could deliver all kinds of things, but if we treat the MVP as a guaranteed deliverable, this gives clients assurance that they won’t just hire a load of time and then fail to get a result. Admittedly, this approach will only work if you have a client who understands there’s a difference between “must” and “should” features of a project, and also gets that if the “must” features amount to 100% of the budget, this isn’t an Agile project.

Once we move from high level planning where user stories and wireframes are produced, we like to have a sprint zero phase in which a lead developer works out exactly how things are going to be built.



In order to produce an MVP that will effectively form the basis of a binding contract between agency and client, we need to know it’s feasible, and that means we need to know what it is and how long it’s going to take. That means we either need a generous time allocation against a manifestly modest MVP, or we need a detailed time-base analysis of what’s going to be made, how it will be done, and how long each component will take.

Here’s an example from a recent project:


Add a pane with a newsletter sign up form.


Write a custom pane for the newsletter sign up form.

Make it able to be ajax loaded.

Add the message "Thank you! We'll send you an update when we publish new stuff."

Add the newsletter form to the panels page.

Email validation needs to be achieved.


Structure > Pages

Click edit on site_template

Click on content in the sitewide variant

Check that the Newsletter form exists.

Goto any page. Check that when the newsletter submits the correct thank you message appears.

Check that form won't accept non valid email address

Time estimate

3 hours

Sprint day

day one

The point here is we’re estimating in a lot of detail about what needs to be done. Frankly, developers will often struggle with this process because they rightly argue that by the time they do all this documenting and planning, they could have built the sodding thing. Very true for a simple task, but what about all the times developers tell you it will take four hours, and a week later they still haven’t built it?

The other thing about this type of granular planning is that if you commit to doing it on every project, there’s loads of scope for re-use of your estimates. How many times in Drupal do you build a view, create some panel panes, and style it up? This should be relatively easy to estimate.

So, now you have a detailed plan with accurate estimates in place, it’s actually possible to have a meaningful conversation with your client about what something’s going to cost, and what kind of MVP is deliverable within their budget. The client has potentially also got a coherent roadmap for ongoing development, so the planning exercise has an intrinsic value, rather than being a distraction from getting ahead with building.



As we’re working with time-based estimates, based on the tasks needed to deliver the user stories that make up the MVP, we also need to track the time actually spent. There’s a couple of obvious reasons for this. From a development perspective, we can learn how long things actually take so this will improve our estimates over time. Being held to account about time also makes developers much more cautious about throwing out time estimates when they lack essential information. We also have a firm basis for answering the question that’s foremost in the minds of most clients throughout a code sprint - how far are we off delivering the MVP?

To do the tracking we use a combination of Redmine for entering stories and tasks, and a custom application we’ve built called “Dplanner”. This is based on an older system called “Xplanner” and we decided to recreate its features in Drupal because it’s no longer under active development.


Design up front

You may well read articles on Agile where it’s described as an alternative to earlier processes such as Big design up front (BDUF). This can seem particularly relevant when working with Drupal because its modular architecture makes it really quick to slap together a bunch of modules to meet a given use case. In reality, this can be misleading. When organisations hire specialist agencies to work with Drupal they don’t want a bunch of modules; they almost certainly want a bespoke solution customised to their particular needs. Hopefully, they will be realistic enough to recognise that the whole point in using Drupal is so you can leverage aspects to achieve ‘out-the-box’ solutions for some elements, and that does imply working with how Drupal does things. However, the chances are they also want a fair amount of customisation, which is why they are hiring professionals in the first place.

The customisation issue becomes most obvious when dealing with visual rendering - how the site looks. Also, these days, it’s how the site looks and functions on all kinds of devices, view-port sizes, and browsers. Oh, and throw in how it works in multiple languages as a little extra. We’ve come to the conclusion that the safest and best way to address the rendering issues is to build an html prototype ahead of doing anything in Drupal.  Once we know the prototype is working across all necessary devices and viewports, and has accessible and standards-compliant code, then we can get Drupal to output that. The point is that we’re actually doing a lot of information architecture and user experience work up front; this is BDUF. Certainly we’re doing the design with a solid understanding of how features can be achieved in Drupal but we’re focused on what the user will be doing rather than on what Drupal does.  You can see more on this here.



At the heart of Agile-scrum is the concept of the product owner - the one person at the client side who takes ultimate responsibility for producing user stories, prioritising stories, acceptance testing, and the MVP. As I explained in part one, this is often the point of failure that calls into question whether Agile is even possible. To address this, we’ll audit our client’s ability to provide a product owner, and if necessary, coach the person given the role. If the audit shows that there is no product owner, then we will just stop pretending the project is Agile. The main differences from what’s been described is that the MVP is recognised to be a fixed specification and change is handled differently. In fact, in a relatively small project, there won’t be any change allowed. We plan up front, get sign-off on stories, wireframes and design patterns and that’s that.

Internally, we have a role that doesn’t exist in Agile-scrum: the project lead. In standard Scrum, development teams should be self-managing groups but we find that doesn’t really fit with the concept of a binding MVP. We need one person to step up and take responsibility for first evaluating that the MVP can be delivered on time, and second ensuring that as the project proceeds, that commitment gets delivered.

It might seem hard pushing this burden onto the lead developer but in fact it should make things easier. Firstly, it focuses the mind during the planning phase and encourages the lead developer to push back against the sales function. Secondly, it helps keep the rest of the team focused on not letting down the project lead, which probably works better than not letting down a client you might never even speak to directly as a developer.

This explicit recognition of ownership does need to be supported by having project lead coaching ahead of a project, adequate discovery and planning time before development commences, and a management structure that allows the project lead to raise the performance of team where it becomes a blocker. However, what it avoids is having ownership vested in company management rather than at the level of development team.



So, with all these changes in place, it’s up for discussion whether we’re really doing Agile-Scrum at all. Here’s an extract from the Agile manifesto:

We are uncovering better ways of developing software by doing it and helping others do it.

Through this work we have come to value:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

Reviewing the modifications we’ve introduced they all tend to rebalance the emphasis of the four propositions towards the right; we focus on processes, we think documentation matters, we treat MVPs as contractual obligations, and we like to have plans in place. So, can we claim to be Agile if we don’t seemingly adhere to the manifesto?

I’d argue that we are, despite having a sceptical view of many of the guiding principles. The point is that ultimately these are principles and values rather than set rules. What’s needed for almost any human endeavour is a framework that enables a group of people to collaborate creatively; our experience suggests that having well-formed processes and tools actually contributes to effective individuals and interactions rather than being an impediment. Our experience also shows that clients working with agencies need some assurance of results, and documentation, negotiation, and planning all contribute to that.