Agile development model in multi-project environment

Abstract

Agile software development has slowly but steadily become a part of modern software industry. Older development models, such as waterfall, are seen obsolete and less flexible in today’s software development environment. But how do current agile methods fare in place where there are multiple ongoing projects and sprint goals can suddenly change? This thesis observes current agile models in multi-project software development environment and tries to improve current model the evaluated team has.

The target team is a small, remote branch of medium sized organization consisting of nine members. The team utilized Scrumban — Scrum with Kanban — but it faced some problems. Rather than having one or two big projects, the branch did many smaller scale projects, and current model did not fit in such environment as good as it was thought. The team had some difficulties on communication between different projects, there was a noticeable amount of “ad hoc work” (issues that were not logged anywhere and were done independently) and metering the progress of the project was hard sometimes. A better model for the team was in need.

First, the evaluation team is briefly introduced and some more info on Scrumban, the Sprint cycle and what kind of projects the team usually has is given. Data gathering plans — surveys and interviews — is also described. After examining the survey and interview results, quality measurement, work cycle, resource allocation and learning were the topics that were widely discussed. Four goals were made: streamlining the work cycle, a way to measure progress, making learning easier during the work cycle and way to monitor the ad hoc tasks. After some analysis, the decision was to take values and principles from Kanban, such as workflow visualization and limiting Work In Progress (WIP).

The evaluation period lasted through two Sprints. The evaluation period was during COVID-19 pandemic but fortunately that did not affect that much to it. After the evaluation, feedback session and discussion about the new model was had. The overall impressions on better Jira board visualisation (personal swimlanes) were overwhelmingly positive and team decided to keep them after the evaluation ended. On other features, the team felt that they were good idea but needed some more time on execution. Overall, the team felt like the new model improved their ability to work agile but there was still some field on improvement, particularly on the learning field.

To sum up the thesis, the four principles that might help the team to choose and agile method are introduced: find what team is good at and what is lacking, do not be afraid of experimenting, think what parts you could automate and reflect on your changes.

Ketterä ohjelmistokehitys on hiljalleen mutta tasaisisesti tullut osaksi nykyistä ohjelmistoteollisuutta. Vanhemmat kehitysmallit, kuten vesiputous, nähdään vanhentuneina ja vähemmän joustavina nykypäivän ohjelmistokehitysympäristössä. Mutta miten nykyiset agile-menetelmät pärjäävät paikassa, missä on useampi projekti meneillänsä ja sprintin tavoitteet voivat muuttua yhtäkkiä? Tämä tutkielma havainnoi nykyisiä agile-malleja moniprojektisessa ohjelmistokehitysympäristössä ja yrittää parantaa arvioidun tiimin nykyistä mallia.

Kohdetiimi on pieni yhdeksän ihmisen etäinen haara keskisuuressa yrityksessä. Tiimi käytti Scrumbania (Scrum Kanbanilla), mutta heillä on ollut ongelmia. Yhden tai kahden suuren projektin sijaan haaralla on paljon pieniä projekteja, ja nykyinen malli ei toiminut kyseisessä ympäristössä niin hyvin, kuin ajateltiin. Tiimillä on ollut vaikeuksia tiedonvälityksen kanssa projektien välillä, huomattava osa työstä tehtiin ”ad hoc työnä” (työ, jota ei kirjattu minnekään ja tehty itsenäisesti) ja projektin kehityksen mittaaminen on vaikeaa välillä. On aika paremmalle mallille.

Ensiksi kohdetiimi on esitelty lyhyesti ja enemmän tietoa Scrumbanista, Sprint-jaksosta ja minkälaisia projekteja tiimillä yleensä on annettu. Tiedon keruu menetelmät (kyselyt ja haastattelut) on myös kuvattu. Kyselyn ja haastattelun tulosten tutkimisen jälkeen kävi ilmi, että laadunmittaus, työjakso, resurssien allokoiminen ja oppiminen olivat eniten keskustelua herättäviä aiheita. Tehtiin neljä tavoitetta: työjakson virtaviivaistus, tapa mitata kehitystä, oppiminen työjaksolla helpommaksi ja ad hoc tekemisen valvonta. Pienen analyysin jälkeen päätös on ottaa arvoja ja periaatteita Kanbanista, kuten esimerkiksi työnkulun visualisointi ja keskeneräisen työn (Work in Progress, WIP) rajoitteet.

Arvioinnin ajanjakso kesti kahden Sprintin verran. Arvioiminen oli COVID-19 pandemian aikaan, mutta se ei onneksi vaikuttanut juuri paljoakaan siihen.

Arvioinnin jälkeen oli palautesessio sekä keskustelua uudesta mallista. Vaikutelmat Jira-taulun visualisointiin (henkilökohtaiset työjakaumat) olivat yleisesti ylivoimaisen positiivisia ja tiimi päätti pitää ne arvioinnin loppumisen jälkeen. Tiimin mielestä muut toiminnot olivat hyvä lisä, mutta tarvitsivat lisää aikaa toteutukseen. Yleisesti tiimistä tuntui, että uusi malli paransi heidän kykyänsä tehdä ketterästi, mutta olisi vielä muutamassa kohtaa parantamista, etenkin oppimisen kannalta.

Lopputyön summaamiseksi, neljä periaatetta, jotka saattavat auttaa tiimiä valitsemaan ketterän menetelmän esitellään: löydä se, missä tiimisi on hyvä ja mitä puuttuu; älä pelkää kokeilla; mieti, mitä kohtia voit automatisoida; ja pohdiskele muutoksiasi.