In late 2012 I was in the semi-final of a pitching competition at the Dublin Web Summit looking to gather fame and funding for my new startup - Fluid UI. After the initial presentation there were questions from the judging panel, including one which caught me by surprise and has haunted me to this day. I was asked: “Given how everyone in the software industry is adopting agile development, isn’t the need for prototyping kind of…obsolete?”
It’s something I hadn’t considered deeply before that time and, thinking on the spot, I flailed out an answer to the attendant crowd that was wholly inadequate. I had simply never imagined a conflict between the two approaches or that one would make the other obsolete. The use of short sprints with requirements captured visually in prototypes seemed too obvious to me to be anything other than the right way to do things.
It has been a passion of mine since that day to show how agile and prototyping work together to reinforce each other’s strengths and shore up each other’s weaknesses. Now, in the aftermath of that question and with 14 years of learning since the Agile Manifesto, I can firmly stand behind the fact that combining the two approaches results in a high quality, design lead, efficient software development process.
Some of the greatest thinkers about software development came together to discuss the failures plaguing software project delivery in early 2001. Together, they created and signed off on the Agile Manifesto. The Agile Manifesto forged a new way of thinking about software development and was a watershed moment in the battle against the inflexible and failure prone Waterfall process that was dominant at the time.
While accepting the need for various activities in the development process, agile prioritised 4 pairings over their alternatives:
These concepts were radical in reducing management overhead and creating a more flexible approach to developing software. This approach delivered value to stakeholders in smaller (weekly, fortnightly or monthly) iterations. From agile, iterative development methodologies like scrum with its product backlog and sprints quickly gained acceptance in the global software development community.
Agile development processes have not been without criticism however. Even one of the original signatories of the manifesto, Dave Thomas, has written that it is time to kill the movement. While this might seem to be extreme given improvements agile brought over waterfall, understanding the limitations of the approach is also key to improving it. And once we do understand them, it becomes quickly obvious that design thinking is necessary to move agile to the next level.
Many of the weaknesses of agile tend to revolve around:
Lack of predictability Prioritisation happens early in each sprint based on updated feedback, making a longer term view of the product evolution more difficult.
Weaker architecture and design The above shorter term view and rapid iterations (sprints) can result in a lack of time to design and implement rock solid designs and software architecture.
Added rework The flexible approach to requirements and the lack of a strong change management process can result in added rework, slower overall delivery and buggier software.
Developer centric view The primary measure of success in agile is “working code” and this can negatively affect discussions around customer expectations, the quality of the UI or support documentation.
Since the agile manifesto, many new tools have been created which allow for far better communication between stakeholders than was possible when the manifesto was written.
Software development methodology and tools timeline
On the development side, tools like Github arrived to take responsibility for managing code, bugs and milestones. Dedicated design tools initially came in the form of desktop apps like Axure and Balsamiq, followed more recently by online tools like our own Fluid UI. Now there are over 60 different solutions worth trying. Each has their own strengths and weaknesses, but all are intended to improve the level of collaboration between designers and the rest of the team. By using these improved tools, designers can effectively merge the concept of people over tools into a single, aligned approach while also improving the capacity for planning and reducing the likelihood of rework.
Like other aspects of software development, the importance of design is far better understood now than it was in 2001. Design has also become significantly more important to success in business - user experience is now as important to a product as functionality or stability.
<some sort of concept integrating design into agile workflow?>
To be delivered in the most efficient manner possible, the UI, copy and graphic design needs to be completed in advance of the relevant code being written. Meaning that the design:
1. must be ready before the start of the sprint, or
2. the sprint must be performed in such a manner that the developers are productive achieving other goals while the design is being created.
In the first case, we are pushing towards a more waterfall type approach and this may also impact design productivity by having to hop constantly between different sprints. In the second, we are placing barriers on what can be done in a sprint and the team may not function as smoothly.
The first option, parallel design requires a little more forward planning, with the design team working on the design for the following iteration and providing support as necessary for the current iteration.
If there is a large bug debt or architectural debt in the product, you may be able to align your design and development processes to a single sprint by allocating fixing time or architectural improvement time during the first few days of the sprint.
Agile doesn’t address the need for prototyping, but efficient software development requires it.
It is no longer good enough to develop “working code” - delightful usability is now the entry price of any great product. Prototyping addresses many of the shortcomings of agile and is a flexible technique that brings value regardless of how it is managed in the development process.
Software development is also a team sport. Designers therefore have a second critical role to play. Their primary role will always be to interpret the needs of the user and to create a beautiful experience that solves the business problem at hand - something that prototyping tools are great at. But designers must now also play a role in shoring up the weaknesses of the agile approach and building a newer, more efficient process using the tools and techniques specifically crafted for their role in modern development.
