Star InactiveStar InactiveStar InactiveStar InactiveStar Inactive

Build an agile mind in a process driven environment

You're an Agile development company (software or ecommerce) and you have to work with either a company that is heavily process driven or none at all.  What to do?

Many Agile companies run screaming when they hear ‘process driven’ which smacks of waterfall or worse – Prince 2 or PMI.  More and more, software and IT companies interacting with large clients that do, or do not, have established project processes are having to meld the two approaches of Waterfall and Agile.  DSDM was one of the first Agile frameworks to incorporate Agile with Prince 2.  It sounds like they are mutually exclusive but the processes help to provide a framework for Agile timeboxes to develop. With the documentation signed off below by the client, a supplier can ensure that the agile sprints/timeboxes are not interrupted and the tasks are clearly defined.

Here are some processes that you should add to agile to maximise this project management style:


  • Discovery document.  Generally accepted by all Agile environments as being necessary but there’s a real need to align this with a Business Requirement Document (BRD).  If you leave it to the customer to provide the BRD you are opening yourself up to vast areas of change.  BRD acts as a baseline.


  • Statements of Work (SOW).  Most PM’s out there will be familiar with this document.  SOW is hugely important in order to ensure that everyone involved with a project knows the milestones and deliverables for each phase.  Sometimes this doubles as a Document of Understanding whereby all the roles and responsibilities are outlined for both the customer and supplier.


  • Business Requirements Document (BRD). This defines all the requirements and must provide the MoSCoW prioritisation for all requirements.  The client must sign off these documents before development can begin and it is likely to be part of a SOW.


  • MoSCoW Prioritisation.  This is of utmost importance to ensure the delivery requirements in the BRD are met, if not your project is highly susceptible to scope creep.  JIRA already gives this level of granularity but it’s very helpful for the customer and client to agree at the beginning of a project what is a Must Have, Should Have, Could Have or Won’t Have For Now.  Without this it’s very difficult to prioritise and a customer will insist that everything in the BRD is a Must Have and to be delivered during Phase 1 of a project.  Agile is all about delivery to a fixed budget to a fixed time.  To do that you need to agree with the customer on what requirements can slip so long as all the Must Have’s are delivered.


  • High Level Tech Overview and Integration documents. The client must sign off these documents before development can begin.  Again this is likely to be part of a SOW.


  • The Design Document. This should include user journeys of how functionality will work when used by a customer using the website.  The client must sign off these documents before development can begin. You can expect this to be part of a SOW as well.


  • Another useful tip, that I always try to stick to, is to restrict the number of design iterations to two before sign off. This helps to focus the client and reduce un-necessary noise.


  • Change Management. By this I mean Functional Clarification Documents and good old CR’s.  This kicks in after the BRD, HLTO, Integration docs and Design document, which are the project baseline, are signed off. The two flavours of Change Management are:
  • Functionality Clarification Documents are created post BRD sign off.  They are for when a JIRA task is raised but the developers have further questions that need to be answered before development can start or progress.  This document acts as a baseline. Once the client agrees on the clarification any changes to be made need to be covered by a change request in order to avoid the development team wasting time developing useless functionality.
  • A Change Request will cover any ‘changes’, however small, to the agreed design and functionality (including user journeys); a thousand minor or trivial changes are the same as many large ones.


  • A RAG status. This is a weekly status document that outlines the Risks, Assumptions, Issues and Dependencies along with a short term timeline and achievements from the previous week.  I think it is particularly useful for outlining Blockers that need senior stakeholder attention to clear.


  • Org chart. This outlines not just senior stakeholders but all stakeholders involved with a project; very useful for orientating any newcomers to a project.


  • Process flow chart. Ideally this should be developed for all the project items above and also include Go/No Go checkpoints, Steering Meetings, etc.  The idea is that it can then be shared with a client in order to show them that you have a process that has to be followed.  The client has to agree to this or the project can’t start.


  • Plan. This goes without saying that a plan of what will be developed and when, i.e. when QA begins, when UAT starts, go live tasks etc, must be developed.


  • UAT. Process driven clients will find ad-hoc testing difficult to plan for.  If you plan for the development and QA to be completed by a particular time then the client can plan the UAT of your solution.  This also means that you won’t have bugs being raised whilst you’re in the middle of a sprint. The UAT should be developed in weekly cycles with a period of a few days to a week for your development team to fix bugs and deploy the fixes before the next cycle of UAT. 


So keeping these processes in mind, waterfall-like processes can help cocoon agile timeboxes and allow you to run and deliver a smooth and successful project. I hope that was helpful!

Good luck with your next project!