Agile is the most popular process for building technology projects. The reason for agile’s popularity is obvious: it allows a business to be flexible and move at speed while undergoing constant learning in the process. Sounds great right and it is, particularly if as an organisation you are not completely certain what it is you want to build.
While the above statement is true, Agile does have it’s problems or shortcoming, and there are the two main problems with agile or at least in my experience.
The first problem is the lack of clarity that exists around what an organisation wants to build. Some of this may be due to ambiguity in the terms used to describe the target software, but that lack of clarity often causes problems which manifest in delays and ultimately more cost to the organisation.
The second problem would be the lack of design that seems to naturally accompany running an agile process. Now whether this is actually a byproduct of the first problem or an independent issue with the implementation of Agile running in your organisation is irrelevant. Most people will agree for one reason or another that agile seems to be synonymous with a lack of design.
Having consulted on numerous agile delivery projects I have seen time and time again the effects of having little or no design while running a complicated technology. I wanted to share with you a new process or method for running agile processes that will enable you to deliver projects much faster with much more clarity and while keeping your teams motivated.
Enter the design sprint. This is not a new concept. Somebody who operates in Product circles may well have heard of or come into contact with the design sprint. The purpose of this blog post is not to explain to you how to run a design sprint, that should be left up to the team at Google Ventures; they do a great job with the website. They even have a book. which you can find in this link. I will, however, release a brief overview of how this worked from building a Cloud Platform perspective in a later blog post.
Now we get to the interesting part, turbocharging your agile process.
Leveraging the design sprint in conjunction with the agile development process your organisation can deliver products much faster.
What usually happens when kicking off an agile process is a team of engineers find themselves in a room with a project manager and some unclear expectations or requirements, oh and a deadline, don’t forget the deadline. This is usually the beginning of the end in an agile Project. But the project will continue anyway, the budget has been signed off and you’ve already got a team of engineers ready to go. It is at this moment that your organisation should use a Design Sprint. Now, these sprints can be tricky, they will certainly feel awkward. Many engineers will struggle to contribute at first, however, stick with the process. After the first couple of hours, you will find that the once ambiguous, vague business requirement starts to take on a bit more meaning and better understood by more people in the room.
Having run design sprints with multiple teams I have seen first-hand, the size of productivity increase that can be seen when everybody on the team has a consistent vision of what they are trying to achieve.
Outputs of the design sprint even include diagrams and PoC’s enabling the team to prove or disprove a solution’s viability before committing to a direction and potentially wasting time and effort.
Following the Design Sprint the backlog can be planned more accurately as more people in the team will have a deeper understanding of what is to be delivered in the sprints that follow.
All of the above-listed benefits are great for a project team but what will most probably occur over the next few months is that productivity seems to decrease and estimations become less accurate. This is an indication that the team has evolved past the point of the previous designs and knowledge, they could almost certainly benefit from running another Design Sprint.
In order to turbo-charge your agile delivery, you will probably find that running a Design Sprint every quarter will give the team enough time and space to collaborate on the design and understanding of the requirements. The Organisation then has 5 sprints (assuming 2-week sprints) of Agile delivery, where they should really be seeing incremental improvements over the previous week’s deliveries. Using the stakeholder demos for feedback assists with confirming that your previous designs were actually correct and delivered to specification, remember that vague ambiguous thing which accompanied the team at the beginning of the project.
While it may seem that devoting 1 week to this Design Sprint in the quarter or project would slow down development, I strongly believe that you find this is not the case. Leveraging the Design Sprint together with a strong Agile process will really give your team the space to deliver your projects in a much shorter time-frame which ultimately enables your organisation to get revenue in quicker or move on to solving the next problem faster.
