Ensuring Agile Design and Development work in harmony
By Warwick Gill, Principal Consultant at Freethinking
I recently attended the Johannesburg chapter of World Information Architecture Day 2017, and was struck by one particular presentation focused on how Agile methodologies have a tendency to constrain design – particularly in large, complex organisations.
It rapidly became clear that the premise of the presentation was that in order to ‘feed the beast’ (the development team), the quality of the Design input needed to be compromised. While accurate in many organisations, this compromise is entirely unnecessary. We shouldn’t reduce Agile implementation in general, to the concept of a sprint.
A sprint is a development concept, and only a development concept. The principles behind a sprint can certainly be leveraged by the other disciplines involved in the delivery of working software, but if the sprint is the only focus, the delivery of business benefit will be compromised.
For sprints to be effective, the development team must be the delivery constraint – if the team feeding the development team is the constraint, it is impossible to optimise flow, and results in waste, or low quality.
The natural response to this statement is to ask how one can then create optimal flow without excess capacity elsewhere in the system? The solution lies in acknowledging that business features are not the only thing that feeds the beast.
So what else feeds the beast?
Technical debt: Mostly ignored until the system becomes unstable – technical debt needs to be identified and added to the backlog. Often these items can be taken into a sprint without significant design or business input and can be used to supplement flow and allow an earlier blockage to be cleared.
Design debt: Yes, it’s a thing. If you believe in an iterative approach to the delivery of software, design debt will be incurred. Portions of design will be done without the knowledge of an informing item that is discovered in a later iteration and the original design will need to be altered.
Architecture requirements: Architecture is simply another input into the backlog – the requirements must be prioritised in combination with the product and design requirements and can often create sufficient flow to consume the entire development capacity if not managed tightly.
Production feedback: The usage of the software seldom conforms to the intended use. Data and feedback on what is working and what is not is a key source of input into the backlog that is mostly ignored.
This list is not intended to be exhaustive, but rather to highlight some of the common items that are overlooked and create unnecessary pressure on the analysts and designers to create work for the developers.
“A sprint is a development concept, and only a development concept… If the sprint is the only focus, the delivery of business benefit will be compromised.”
Design is broad, and deep
The second thing contributing to reduced quality is the failure to recognise the broad spectrum of skills involved in Design. The continuum of development functions in large organisations tends to incorporate architecture, system analysis, infrastructure design, development and testing while the design continuum in particular tends to include “we have a UX/UI/CX/SD” person in the team.
The problem is similar, although less pronounced, in the business analysis area. In any value delivery stream, there are long-running work-streams and short iterations for delivery. It is critical to clearly identify and articulate the long-running work-streams in design to ensure sufficient capacity is provided. These items include:
User experience strategy: While usually an intervention up-front, an effective strategy is under constant review and change based on new evidence discovered during research, user testing, utilisation analysis or implementation of new/old technology (such as the recent re-launch of the beloved Nokia 3310 feature phone).
User testing: User testing is another long-running workstream that enables the refinement of the strategy and experience while testing
The last component contributing to the lack of quality is the continued approach of compartmentalising skills. In many organisations there are still distinct hand-offs between analysts, designers and developers and the discussion focuses on what comes first – analysis or design. The answer to that is simple: both and neither.
Effective Agile delivery teams leverage the skills available in the team – and tend to not obsess about which discipline owns a particular skillset. The trio of the lead analyst, designer and developer should be joined at the hip to ensure optimal flow and quality output and the design and analysis teams should operate as one unit.
It requires that individuals be less precious about their area of expertise and become focused on the goal of delivering value.
Ultimately, Agile methods do not constrain design quality. Through recognising the varied sources of development work, creating awareness and capacity for long-running design tasks and collaborating effectively with delivery stakeholders, Design quality can be achieved while ensuring optimal velocity.