Why Design should be ahead of development in sprints
It’s no secret that agile development teams thrive on collaboration to deliver, which is the purpose of being agile. But, even with this fact as clear as day, there are deliverables that teams need to work with, and one of such teams requiring deliverables is the developers.
From experience, I can tell you one of the most frustrating things for a developer is having to re-code something she has already worked on before because time and resources are wasted. The essence of product management is to reduce risk, and one way to mitigate against this is to make sure that you don’t have to start all over for any project. Even when teams pivot, they pivot on already built projects and not from scratch because resources will always be a constraint.
SPRINTS IN AGILE DEVELOPMENT
At this point, it is essential to define clearly the terminologies used here. The agile development method is a variety of incremental and iterative product development methods used to develop products. This means Agile is the method of development different from waterfall, and it comprises other methods, e.g., Scrum, Kanban, XP, DSDM.
The waterfall method of development, just like a physical waterfall, is a systematic development from one phase to another. It is very effective in building large projects that consume a lot of expenses, and in this method, the requirements have to be clearly defined before any building starts. For example, in building a house, you cannot iterate back to the foundation after roofing. In making an airplane, you also need all the requirements spelled out before building because it is too high a risk to iterate during the building process.
Delivering to Developers:
Although I used ‘sprint,’ which is scrum terminology, this applies to other agile methods like Kanban. Scrum, a term coined from rugby, is when players are packing closely together with their heads down and attempting to gain possession of the ball. Two important things about scrum are that it occurs very often, and there has to be a collaboration between the team members to retrieve the ball.
One of the reasons why software development has adopted agile methodology is because of the ability to iterate quickly from learnings either from the customer or market changes that happen very quickly. When these changes occur, the easiest and safest way to start these changes is from the Design or prototype. It is important to note that no part of the scrum team should work in isolation, just like in an actual rugby scrum. This is the best way to avoid misunderstandings in hand-offs. So even though product managers write user stories, designers create prototypes, developers code, and testers test, everyone is still involved, each role-taking its lead at its critical stage.
Team velocity:
Relay teams in athletics run together but have different lanes in the same race, but they need to pass the baton to one another correctly and at the right time, with the team’s success hinged on both teamwork and performance on each team member-run. The same way two team members cannot run on the same lane, is the same way designers and developers should not be on the same sprint simultaneously. Although designers are encouraged to be ahead, the collaboration in scrum requires they be available if needed in the current developer sprint.
According to Dan Olsen in his book, The Product playbook. He says to achieve a steady flow of work, designers need to be at least one or two sprints ahead of the current sprint. So by the end of sprint N, design artifacts for sprint N + 1 and N + 2 should be finalized and ready for development work. This is a safe and reasonable approach, but product management is a mix of art and science, as I said in my previous article. The way you approach it might be different depending on your constraints or situation, but I firmly believe this is the best approach to building with agile.
