Becoming Agile
Achieving results quickly using transparent processes, shared between the team and clients.
In the current state of flux and constant change, the traditional production flow, vertical, inflexible, and above all, not shared with clients, can no longer offer an efficient, time-effective approach to teamwork and to the creation of quality products.
In early 2014, we decided to explore some different practices and methods for managing and organizing teams.
Our objectives were:
- to break free from situations in which one or two people were the sole, indispensable custodians of a project or of the technology used;
- to speed up our product launch times, right from the conception process;
- to work on several projects concurrently without losing efficiency;
- to deal better with changes to projects already underway;
- to improve communication regarding tasks and progress between the team and clients.
The Agile methodology, and specifically Scrum, was chosen to explore what was for us a new approach to team and work management.
Scrum is an empirical method, and our position was equally so: we did not worry unduly about performing Scrum "by the book”, but rather, we sought to experience the advantages and disadvantages for ourselves.
Compared with other Agile methods such as Kanban, Scrum involves time-boxed development cycles known as sprints; these are a good way to maintain high productivity and concentration levels, and to limit deviations from the project.
We decided to try this new approach on a software project, sharing the vision and objectives with the client.
Starting out: the team
The first step was to create two new roles to support the development team: the scrum master, a team member who would handle team management and facilitation, and the product owner, nominated by the client, who would establish the vision and priorities for the project.
The development team was made up of people from Chialab and from our partners at Channelweb.
We immediately set about defining the rules and the Scrum meetings with the team: sprint planning, daily scrum, sprint review, sprint retrospective.
We added a meeting called “weekly scrum”, in which, once a week, the client was included in a daily scrum, in order to update them on the ongoing situation in a transparent way.
During this initial “empirical phase”, there was a feeling that we were really wasting a lot of time in discussions instead of working.
Soon the team realized that the time apparently wasted in discussions was time gained in our work, because we were always on the same page in terms of the objectives set by the client and by the market.
The fact that we constantly worked with imminent deadlines (the 2-4 weeks of each sprint) was at first perceived as putting us under pressure, but it increasingly became a normal part of the routine that we faced with absolute calm and confidence.
Responsibility was no longer on the shoulders of a few team members, or on the “traditional” project manager. It was distributed between the various roles, thus helping us to work with greater focus and efficiency, leaving scope for all members to make decisions about the tasks to be performed: everyone became the manager of his or her own area of competency.
The development team autonomously decides how to carry out the technical and design aspects of its work, increasing its responsibilities and its sense of satisfaction.
The scrum master oversees the entire workflow, and can handle any team problems, motivating and engaging the team in moments of work sharing and helping it to grow.
The product owner takes care of the business side, and by remaining in touch with the rest of the team, always knows how the project is going, and can foresee its impact and development on the market.
Thus, each team member is focused on his/her own role, but at the same time, is synchronized with the development of the project as a whole.
Having all started using Scrum together, both developers and managers, it took us a couple of years to realize how effective the method is relative to a traditional waterfall model, but now none of us would go back to a traditional management system.
Results
Once the basic Scrum method was properly established (it is summed up in a brief guide just a few pages long), the team members autonomously decided to adopt further Agile-derived practices in the management of their workflow, in a constant growth process.
Agile and Scrum are not definitive solutions, but a set of methods and tools that help you improve your work.
Thus, the team managed to achieve its objectives independently:
- with moments of sharing such as pair programming, code review and the scrum meetings, technologies and project decisions were more widely shared, rather than remaining the “property” of a few team members;
- by involving all the necessary roles in the realization of the products, release cycles have become frequent, complete and more widely shared;
- the team has been involved in several projects using scrum, making it easier to share resources and skills between projects;
- scrum has helped us to share project and market decisions with the client, modifying the product itself during the development phase in order to adapt to respective needs;
- one consequence of this is that trust between client and team has increased, as they share horizons and choices, working together to help the products grow.
Experimenting with the method outside of software development
Having gained awareness and efficiency in software development, we decided to export these techniques to other parts of the studio, such as the page layout of text books, despite a lack of satisfactory literature on Agile methods in this type of field.
This experimental period on non-software projects was of limited duration, on one specific project, without directly exposing the new organization to the client (this is not always an advantage, especially not in the test phase).
The scrum master from the software development team coached the page layout team, explaining the principles of Agile and Scrum, and preparing the team to test the method.
The first step was to hold a retrospective on current workflows, and to try to identify the strengths and weaknesses of the team.
Subsequently we tried to split the work up into sprints, creating a simple subdivision and estimation of the work into two-week cycles.
Then a physical board was created, on which to view the progress of the project using post-its on which the various tasks for completion were marked; a “daily scrum” was organized to ensure our work was well coordinated.
We nominated a product owner and a scrum master among the internal team members.
At the end of each sprint, a review was held to assess improvements or changes in workflow.
The experiment lasted for three sprints, or six weeks.
What we learned
Applying the scrum method “to the letter” did not work very well in this case.
The division into cycles was ill-suited to the type of processes used for these books, which were difficult to split up into smaller portions of time, and it was hard to synchronize the different processes, which were not always linear and predictable.
For this reason, the daily scrum didn't make much sense: often people were repeating the same information.
What worked?
The distribution and structuring of roles into product owner/scrum master/development team was fundamental. Many hold-ups in the workflow were due to a lack of clarity in the distribution of responsibilities and competencies. Making these roles clearer led to an immediate advantage in the decision process and in the sharing of responsibilities.
The retrospective was maintained, but shifted to the end of the processing cycle, and not tied to fixed blocks of time (sprints).
Conclusions
The definition of roles according to Scrum was a tangible advantage for both software and other projects: for this reason we decided to extend this strategy to all Chialab jobs.
Now, in addition to the operative roles, each project has two figures who effectively replace the traditional role of the project manager.
In order to avoid confusion with Scrum, the role of the product owner has been renamed “project leader” and the scrum master has become the “workflow leader”. Together with the development team, they autonomously decide how to manage and share the responsibilities and tasks of their work, and whether to adopt Agile methods or not.
Once a month, administrators and persons in charge come together for a short meeting to get up to date on the progress of works and resources.
We can conclude that Agile and Scrum brought direct improvements in software development, where they were better suited to the type of work, while the adoption of certain Agile principles on non-software work led to a better distribution of roles in the management of the work.
The important thing was to experiment, and to quickly grasp which methods to continue and which to drop, through a process of trial and error.
Manuel Zanettin
Is this still Scrum? I’m not sure, but does it really matter? Anything that works for you is right, anything that doesn’t is wrong.
Henrik Kniberg
Crisp/Spotify/Lego