How Scrum Helped to Evolve our Design System Team
Foreword
Many self-started design system teams eventually reach the level of maturity, where they no more consist of spare timers or allocated individuals, but ready to become a fully fledged team. Same happened with us — when the first full-time member joined our virtual team — we had to decide how to organise our work in this new reality. Already some time before that faithful event, and even though our virtual team mostly consisted of designers, we had an epiphany that design system project had more in common with the way developers work rather than designers. So we started to adopt some basic agile ideas, such as backlog, sprints and monthly demos. All of it was on a primitive and not quite efficient level, but it got the job done. However, this first contact with agile made us think that why not to go even further and try to adopt Scrum. Initially, our main goal was to improve the efficiency of our virtual team, so…
Why to try Scrum?
1. Keep focus on long term plans
As a design system community is expanding, so does the number of tasks and responsibilities. More products using the system means more support and maintenance work is expected from a design system team. Moreover, the number of component requests and bug reports is growing as well. All this leads to an overwhelming number of small tasks and constant distractions, as a result, the team ends up only reacting to requests and not developing the design system proactively. Following Scrum methodology helps to keep focus on larger tasks (stories and epics) as well as to prioritise and follow through on long term plans, that otherwise could have been lost in a daily ado. One example from Scrum on how to achieve the focus is to have a clearly defined goal for each sprint.
2. Managing a growing team
As a design system team grows, so does the need to align and sync tasks and responsibilities among team members. It becomes even more challenging, when a team has both members who only work on a design system and who are busy with other projects as well. This situation can create bottlenecks in communication and delays with shared tasks. Having well defined sprint plannings, dailies and reviews can be a good solution here. This is especially important, when all team members are working remotely. But ability to sync between team members is not the only possible benefit. Bi-weekly retrospectives allow to accelerate the internal feedback cycle, which helps to keep improving and adapting work process, as well as to keep motivation high. Last but not least, in general having a well defined work process makes it easier to introduce a new member to the team.
3. Unclear scope of tickets and no definition of done
What our design system team suffered from a lot was having an ambiguous scope of tickets and unclear task descriptions. This often caused a situation, where it was impossible to understand what exactly should be done next with the task and as a result the ticket just drifted with in progress status from one sprint to the next for months. This can become very demotivating. One solution from Scrum is to have a proper definitions of ready and done.
Doubts
Before deciding to give Scrum a try, we naturally had some doubts. First, that we were still more a design team, rather than a dev team, so we were not sure if Scrum would work with designers’ mindset. Second, most of our virtual team members were not able to dedicate full-time to the design system, in some cases not even a half. Most of designers were busy with the product UX tasks, and thus would not be able to participate at all Scrum meetings and contribute to every sprint. Third, we saw the design system as not just a product, but also a service and a community, therefore strictly following dev team’s way of working could have been limiting. As a result, we even considered to try and adopt Scrum only partially. Needless to say, we were wrong on all accounts. And a big role in dissolving our doubts and transforming us into a Scrum team was played by an…
Agile coach
The agile couch has helped us to go through the entire transformation. The process started from an introductory presentation about Scrum methodology — its values, principles, meetings, roles. The next step was a workshop, where the team had mapped the work process, which helped to align task statuses with the actual workflow, as well as to define missing skills to cover in the future.
Once the official (easy) part was done, the hard part started — to actually adopt Scrum and keep following the process and its values without deteriorating back to a chaos. Thus, it was paramount that the agile coach stayed with the team for several sprints observing all our meetings and providing valuable feedback on what could be still improved, as well as initiating fruitful discussions on how to increase our efficiency and support our motivation. Eventually we…
Adopted Scrum:
1. Clearly defined sprint goals
One of the key changes was to start defining sprint goals, that the team was ready to commit to. As mentioned earlier, this helped to keep focus on larger projects, and in addition with both improving task descriptions and clarifying definition of done, this lead to a dramatic increase in number of completed tasks.
2. Following meetings’ guidelines to get value from each meeting
Another important change was to have a logical sequence of meetings, where each meeting had a clear goal and a valuable outcome. Furthermore, having well defined methods and tools to facilitate meetings helped to keep team’s focus and spirit high. Later we took this idea of having structured meetings with expected deliverables and applied it to improve our UX design workflow outside the design system, and it did work wonders.
3. Continuous process improvement and feedback
Scrum methodology is not only about continuous integration of the product, but also about continuous improvement of the team. Sprint retrospectives allowed our team to have a regular time slot, where all members could evaluate our work and share their ideas on how to improve it. Furthermore, the short feedback cycles allowed to avoid team members’ burnout, by reducing the work pace. In addition, retrospectives provided a platform for the team to discuss how to better cooperate and sync with other teams in the organisation.
What was left out
Some parts of Scrum were either left out or slightly modified to fit our needs. After all, the main goal of Scrum is to not blindly follow the rules, but to increase value and efficiency of work we do. So if something from Scrum doesn’t bring any tangible value to the team, then there is no need to fully follow it. As a result, we decided not to estimate tasks, because maintaining it was too time consuming; we organised demos only every second sprint, not to overwhelm other teams with meetings; and we decided not to add some of process statuses and task types that were earlier defined during the workshop, because they added extra complexity to our work. Still, if in the future the team decides that some of these practices can improve our work, we will take them back into use.
Afterword
As it was mentioned in the foreword, before adopting Scrum our virtual design system team included many members who were often too busy with other projects and were not able to contribute on a regular basis. Back then our main goal was to improve the work of our virtual team, but something unexpected had happened — when the adoption process started, those team members who had other primary responsibilities decided to fully focus on them, while others, who were able to contribute more to design system, had become almost full-time members of the team. In a way, adopting Scrum helped to clarify everyone’s responsibilities and by creating a strong gravitational pull with well-defined process helped to transform a virtual team into the actual team.
… and so our transformation was complete.
