This experience report illustrates the adoption and adaptation of Agile practices in a software startup, Datatellers. The case studies a first transformation failure followed by a second success. From a team angle, keys to this accomplishment have been identified in shared team mindset and care for the company culture, while a principle-driven and bottom-up process based on continuous experimentation has helped in the transition to new practices.
1. Introduction
Few months ago we found ourselves in Datatellers, a software startup located in Bolzano, moving to a new office. It was Marco’s first day of work, whereas Francesco had already worked there for the last 6 months. We decided to take advantage of the change of the working environment, since the company just moved to a new office, and a week later we started the company’s second Agile transformation trial that led us to the main content of this experience report.
One of the founders of the company, dealing with the facets concerning project management activities, aware of the need and the possibility for an improvement in the development and managerial processes, started collaborating with us aiming for a company-wide adoption of the Agile methodology. Initially, we evaluated the context, including the company environment, the workflow processes and resources, and we extensively discussed a previous failure of Agile transformation that happened few months before our arrival.
Thanks to these initial reflections, we realised it was not going to be a linear process; several aspects of the current company status needed particular attention, one of this was the multiple business facets given by the unusual business model running in this startup. Since the beginning we knew a main challenge that we were going to face would have been the introduction of Agile practices into a multidisciplinary team, composed by designers, developers, content managers, and journalists. Nonetheless, we noticed a culture with flat leadership in the company and some agile values and principles already applied, in details:
- Business people and developers must work together daily throughout the project.
- Build projects around motivated individuals. Give them the environment and support their needs, trust them to get the job done.
The concept in the Agile manifesto “Individuals and interactions over processes and tools” (Beck et al. 2001) was already valued.
Nowadays there is an intense discussion in both academic and practitioners world about what in detail characterizes a company that is considered Being Agile against Doing Agile. With our experience we want to take Datatellers as an example of a small organization embracing Agile methodology, without the strict need to adopt the ‘by the book’ practices. That is, we are going to highlight how in our scenario different kind of transformation led to failures and successes. Moreover, Agile has to be considered as a spectrum; there is more than one way to achieve agility. Indeed, the reader will be able to grasp from our experience an example where only particular Agile principles can be in place whereas others can be missing.
The little secret is the “Datatellerity” (Datatellerità in Italian), something that we consider, in retrospect, one of the key ingredients of the success of Datatellers. Although seeming to us like an abstract and singular concept, once analysed it presents specific characteristics that can aid picturing how it constitutes. “Datatellerity”, in our meaning, can characterise both the individual and the team. In the first case every single member has an innate attitude for kindness, loyalty, humbleness, and meta-competencies such as the continuous quest for improvement, the aim for perfection, and the attention to details. Secondly, whenever a team is composed by people with these characteristics, it will keep its momentum thanks to collaboration, enthusiasm and sense of belonging. In regards to the latter, we found it arose in our case in the form of shared interests both during work shifts and the rest of the time.
Before going on telling our experience, we need to specify that with Agile we mean the ability to be prone to changes. This report is organised as follows. In the next section the reader is provided with key information describing the context in which we operate. The third and fourth sections unveil the story of a first failure and a second success in the adoption and adaptation of Agile methodology. After that, we discuss our main learnings from this experience. In the last section a different perspective of the story is introduced through the principles of the Modern Agile movement. Finally, with our case we hope to provide an example of differences and overlaps between Being Agile and Doing Agile. We are going to exploit the root of the current Datatellers agility and the failures the company faced on the way to embrace Agile values and principles.
2. Background
2.1 The company
Datatellers is a SME located in the new technology park in Bolzano, Italy. The team currently includes few journalists and content managers, one designer, some interns helping in the business and marketing side of the company and around eight in place developers. The products are tailored software platforms, to analyse and visualize data related to specific business needs of our clients, e.g. Business Intelligence dashboard, predictive analytics systems. The typical user of our software is a business analyst or a director-level employee looking for insights on their own services. From a technological perspective, open-source support to our solutions is highly encouraged. It is to be noted that the current business model is based on the embracement of change, not just seen as something to accept, but as a resource to seek. Moreover, Datatellers’ business also includes some Spin-offs. The main one, while sharing resources and employees with its parent company, works in the Data Journalism field, with several parallel projects ranging from web-agency activities to local tourism and economy magazines.
2.2 Atmosphere
Friendly, trustworthy, creative are three adjectives that identify our working environment well. As we already mentioned, we believe that the positiveness of the relationships within the team lies in the personal aspects of each individual. Humbleness, willingness and curiosity to interact with each other are what we endorse. In such an environment everyone feels safe and free to express themselves. Therefore, we developed habits to enhance interactions and ensure such atmosphere. Below we present an example of such activity.
The Late Breakfast
Against a strict working time and micromanagement, it’s our custom to start a tough working day with a coffee together outside the office. This becomes a must when more team members are late in the morning.
2.3 Changes and challenges to face
In the last year, the company went through drastic changes, both in the business and in the team composition. From a Lean Startup perspective, we could say there have been several pivots such as Business Architecture Pivots, Technology Pivots and Complete Pivots (Bajwa 2017). In details, there has been a quick turnover of interns, mainly with computer science backgrounds, and the work that was first assigned to employees working remotely, has been progressively internalised, while aiming to build a stable development team. As we are going to describe in the next section, these changes caused several problems in the development process and at the management level.
2.4 Who we are
As university students we found Datatellers while looking for our internships. Despite joining at different times, we had a similar experience covering the same job position. It did not take long to realize the common interest in Agile and to push this transformation forward. We planned this with our manager and the two of us took the responsibility of designing and implementing the process. Our background and understanding of Agile topics comes, for the most part, from academic research knowledge and our personal interests.
3. What was before: first failure
During late 2016, the manager assessed the ongoing and completed projects, highlighting crucial flaws in the development process, such as delayed deadlines or incomplete tasks and felt the need for an improvement in project management. The lack of a methodology and structure of workflow processes was believed to be the cause of such flaws. In line with the objective of delivering value more rapidly, doing Agile was thought to be the natural choice.
The initial willingness to change and “do Agile” led to a quick first trial. The process was based on a top-down approach, where practices were implemented through the imposition of specific tools, e.g. Trello and Asana (Table 1), to team members from our manager. The whole team was required to follow the new practices. Journalists and Designers, struggling with the recently adopted tools couldn’t manage to integrate them into their daily routine.
Table 1. Practices adopted in the first transformation trial
This first trial corresponds to what is known as Kaikaku, which means drastic and radical change (Fitzgerald 2017). In detail, analysing that experience in a second moment, we came to the conclusion that the main reason of this struggling has been the lack of an evident improvement provided by the tools themselves. The latter could have probably been affected by the nature of the job activities that generally saw Content Creators dealing with short tasks and quick deliverables (i.e. magazine articles, web components design).
One of the other reasons for the failure has possibly been the wrong choice of the initial adopted practices, e.g. the usage of tools with a strong collaborative component among people not enough educated over the methodology. Moreover, such tools require the overall team collaboration in order to get the most out of them. Only the in-place team was targeted by the transformation, so the excluded remote workers quickly became the bottleneck in the development process. This is also the main reason why the dev-team did not play a leading role in this first attempt. To this day, we are not sure whether the internal dev-team, counting two members, would have fully profited from the transformation advantages, since both developers were following different kinds of projects, i.e. one was responsible for the web agency activities, and the other one for the development of tailored software platforms.
4. What We did then: second trial and success
Conscious of the first failure and aware that the agility mindset was already pre-existent, we decided to give it a second, more aware, spin. We still considered the improvement of the value delivered by the company one of the main goals of the transformation. Thus, we focused on practices that could ease the development process. These are the ground concepts we based the structure of our transformation on.
In agreement with our manager, we began the transformation last October. Along the process particular attention has been given to favour kaizen events over radical steps (Fitzgerald 2017). Such preference led us to apply incremental improvements that will be later recognised to be a key for the success of this experience.
Leading the choice of tools, aware of everyone’s background skills in the team, we could make sure that the introduction of each new practice would be perceived by the colleagues more as a proposal than as an imposition. This was enough to convince everybody to believe in the advantages offered by this transition. We observed how successfully the non-dev team naturally followed the working pace given our new iterative workflow. With the time passing, the team was opening to discussions related to the ongoing transformation and its advantages.
Considering the growth of the number of software projects, we soon faced the need for a shared versioning system, a self-hosted GitLab instance. The longer-term aim was a working continuous deployment stack that we implemented transparently towards colleagues. Nowadays, it may seem trivial for a developer to work with software like git, but, in order to perform efficiently, collaborators are required to have good knowledge and confidence in such tools. After the versioning system and the setup for continuous deployment, we decided to go on with the same tool that first failed, the Kanban board. In this second trial we opted for a physical board in the office. Before describing the singular design choices behind our Kanban, we will provide the reason leading us to use this rather than a software solution. As the first trial taught us, a digital board where every task is shared with some colleagues, or even with the whole team, goes against the principles of keeping a safe working environment, since novice users, not aware of the real value underlining the tool, tend to see only the negative aspects of it, i.e. they can feel the pressure of a controlled environment. On the other side the physical board allows for a gradual introduction, giving space to habituate to the practice.
Figure 1. Kanban board in the iMac box
The board is purposely hidden inside an iMac box instead of hung on a wall, in line with the friendly environment and with the company policy regarding the confidentiality between Datatellers and their clients. That choice allowed us to gradually introduce the board to each individual member of the dev-team and helped us educate less experienced colleagues. Post-its were categorised with a two- or three-letter identifier that eased the recognisability of everyone’s tasks, and each one was numbered, to better keep track of the current workload. It became natural to spread post-its (also adopting criteria such as associating height and position as indicators of metrics such as priority or difficulty) in each column of the Kanban board, but for the “Done” column. The latter would hold one unique stack of completed tasks symbolising the amount of work done and that could be felt as a tangible success.
In parallel, we began our routine of Standup Meetings, investing five to ten minutes in front of the board-box every day, while discussing achieved tasks and bottlenecks or problems we were facing. In our opinion, it is interesting to notice how these meetings became shorter and shorter overtime, showing us how noticeable improvement and adaptation was ongoing. Up until now the team never felt the need to systematically perform dedicated retrospective meetings. Our choice was then not to push on this practice further than trying them out a couple of times with limited and selected people. Besides, we spend a significant amount of time together outside the working environment. In such situations we often start discussing and reflecting about work, what is going well, what is not. In case of a future adoption, one concrete challenge would be to organize and take decision for a common time to perform the meeting due to the high number of projects going on in parallel, and different working times.
A summary of the practices, both Agile and non-Agile, adopted in this transformation process has been reported in Table 2, along with their implementation as tools or habits and the corresponding team reactions.
Table 2. Practices adopted in the second transformation trial
Half a year after beginning the transformation process, the results became crystal clear to us. While still there is space for an improvement, the ability to face changes and challenges is now increased in terms of efficiency at any level, from the developers’ daily activities to the project management ones. We performed a more systematic assessment of the achieved agility, with a semi-structured group interview, involving the main protagonists of our experience: the manager and the initial dev-team. The interview structure has been based on the Agility Assessment Framework (Conboy 2004). With open questions we discussed the advantages brought by the transformation comparing them to the previous company asset. All the five dimensions of the framework have been examined during the conversation. A consistent improvement was denoted across each dimension, proving the value of agility in the company development processes.
5. What We Learned
5.1 Mindset value
Since our role in this transformation was a conjunction of decision making and observation, we were able to grasp the underlying mindset of the whole team, realising its role as the key of the transformation’s success. Though from our experience it cannot be considered a sufficient ingredient by itself.
5.2 Adoption as experiment
Like in a Lean Startup context the transformation can be addressed as an experiment to learn. Failure in adopting practices can happen even in an Agile-prone environment. Given that, it is better to fail fast and if possible in a safe environment, to be able to better understand and observe how the team reacts to change.
5.3 Education & Culture
Another learning point in our experience was the importance of education and culture spreading within the team. Practices alone can be tough to be accepted by such a multidisciplinary team, that is why it is fundamental to discuss advantages and challenges that each practice carries on. A success factor of such educational culture lies on the mutual trust among team members that gave us space to propose single practices while, continuously observing the results of their adoption.
5.4 Bottom-up dissemination
The bottom-up approach brings the advantage of indirectly involving everyone in the decision process and helps the forerunners fine-tune the speed of this Agile transformation. In our situation the transformation required to be encouraged by our role as forerunners. We believe change is easier to face when one is motivated rather than pushed towards it. Our aim was and still is today to lead this transformation process by having spontaneous and enthusiastic followers that are willing to experiment, confront and discuss.
5.5 Principles-driven
Principles and practices do not constrain each other. In fact, we have seen how different adaptations of a set of practices can fulfil the same principles. That is, principles over practices has been the way to go for our experience. As we can see from Table 1 and 2, the usage of new tools was not the real problem in the first transformation failure. Considering that, during the second attempt, simply a different introduction of the same tool was sufficient to be successfully accepted.
6. From a different perspective: modern agile
In 2016, Kerievsky gave a keynote speech at Agile2016 on the Modern Agile movement (Kerievsky 2016). The goal of this movement is to update the almost twenty years old Agile Manifesto in the light of the last years adoptions of Agile methods in companies. The movement is framework free and principle driven. That is, the twelve principles of the Agile manifesto have been reconsidered and mapped to four principles, influenced by other methodologies, as Lean Software Development and Lean Startup (modernagile.org). In the last years this movement gained credibility and we strongly believe in it, so here follows an attempt to analyse our case considering the four Modern Agile principles.
Two principles concern the people and the culture in the working environment: “Make people awesome” and “Make safety a prerequisite”. Regarding these, we explained how the team including managers and chiefs is already always concerned about colleagues and about the establishment of a working environment, that aims not only to make people feel safe, but also to enhance collaborations and constructive interactions among people sharing the same office. To back this in Datatellers we have a good rest area, used mainly for having lunch or even just a beer. Moreover, we don’t skip birthdays and always find a way to celebrate good results or special occasions and share some nice moments together.
On the other side, the other two principles are more related to the continuous improvement concept: “Experiment and learn fast” & “Deliver value continuously”. As we already mentioned we worked a lot to improve the development and deployments pipelines.
One aspects that is underlined by more than one principle concerns client relationships. We still consider this point one of our main limitations. In fact, due to the high ratio of projects over resources, we can currently manage to have only the minimum amount of meetings with clients in order to prototype and build incrementally, but this can still be extensively improved. Another technical aspect that we are pushing is the integration of quality gates in the continuous deployment pipeline. Finally, one interesting new activity we are about to start within the company is a short knowledge sharing session, in which we plan on investing around one hour every second week.
We conclude stating that we believe in Modern Agile, and we are going to push forward this project and continue our search on an improved working environment.
7. Acknowledgements
This experience would not have been possible if it were not for the team at Datatellers. During the drafting of this Experience Report we realised that the trust and collaboration that was placed in us both by the management and all our co-workers is remarkable, other than highly rewarding for us. Thank you for being so Datatellers! Special thanks go to our shepherd Viviane Santos, who patiently guided us through the right way to envision our story and be able to communicate it in the most effective way possible.
REFERENCES
Beck K., Beedle, M., Bennekum A., Cockburn A., Cunningham W., Fowler M., Grenning J., Highsmith J., Hunt A., Jeffries R., Kern J., Marick B., Martin R., Mellor S., Schwaber K., Sutherland J., Thomas, D. “Manifesto for Agile Software Development”, 2001. [online] Agilemanifesto.org. Available at: http://www.agilemanifesto.org/ [Accessed 15. March 2017].
Bajwa S.S., Wang X., Nguyen Duc A., Abrahamsson P. ““Failures” to be celebrated: an analysis of major pivots of software startups”, Empirical Software Engineering No. 22, October 2017, pp. 2373 – 2408.
Fitzgerald B., Stol K. “Continuous software engineering: A roadmap and agenda”, Journal of Systems and Software Vol. 123, January 2017, pp. 176-189.
Conboy K., Fitzgerald B. “Toward a Conceptual Framework of Agile Methods: A Study of Agility in Different Disciplines”, Proceedings of the 2004 ACM workshop on Interdisciplinary software engineering research (WISER), California, November 2004, pp. 37-44
Kerievsky, J., Modern Agile Keynote, Agile 2016 [online] https://www.agilealliance.org/resources/videos/modern-agile/ [Accessed 15. March 2017]
