We are currently working on an exciting project to deliver a social media application in the creative sector. The project is being run as an Agile project. IndigoBlue is supplying the scrum mastering, project management and coaching for the client and the recommended the technical partner, which is developing the application.
The partner for the application development and web is relatively small, and uses an associate type resourcing model for design and project management; this seems to be working well. The management of design in the project is proving to be the most interesting and challenging of tasks. By design, I am referring to the design and presentation (UI and UX) of the online application, as opposed to the architecture or taxonomy.
The project is currently estimated to run over 16 two-week sprints, with an increment estimated for delivery at Sprint 7. The project has to become financially self-sufficient shortly after launch so there is significant focus on the early delivery of features which can be monetised from Sprint 7.
The processes in support of the project and development are well organised and already producing good progress. Adequate and appropriate documentation is in place, including a legal contract with a focus on collaboration, Project Initiation Document and an Overarching Plan. The Project Initiation Document includes many of the critical project-related processes as well as the details around governance, product ownership, change control, measurement and reporting.
The ethos of the client organisation is to champion and promote excellence in the creative industries, so the look, feel and performance of the application is more critical than ever. The application development team are participating actively in the Agile processes and in particular the story preparation and acceptance. How to approach the design relative to the approach taken to coding the application has proven an interesting challenge to resolve.
One point of view is that design should be treated no differently from any other aspect of design or in fact the underlying application code, and that in order to complete the sprint, the focus should be on the minimum viable product. There is another point of view that a significant proportion of the design has to be completed up front and then adapted into each sprint as required. It is worth reading a colleague's blog on the connected subject of getting UX design right first time.
The approach to design we are trialling works as follows. The design is determined as a critical part of the acceptance criteria in sprints where design (UX) is of significant relevance in that sprint. Frivolous pixel-perfect design is avoided in each sprint, though at the same it is fair to say that the quality of the completed design standard is high, with little design debt being carried forward. This is because without the high standard, the design acceptance criteria would not be achieved.
Alongside this, the design team are in the early sprints creating a catalogue of design features so that where a future sprint requires a search or an action button, these assets will already be complete and available at a far lower overhead in future sprints.
Update: This approach worked extremely well. The UX and UI design received very positive feedback from users post-launch, and design features were added to the catalogue as the application continued to develop. The site, Hiive, was launched on schedule in March 2015 and was later Highly Commended in the category of Digital Project of the Year at the 2015 Computing/BCS UK IT Awards.
If your organisation is seeking support in de-risking an Agile project or programme, please get in touch.