Further answers to questions from Krista Jäntti

Here are some additional answers to questions asked from second guest lecturer, Krista Jäntti from Reaktor Innovations. Questions are answered in the same language as they are asked.

Why was Reaktor Innovations the best company to work at in Finland in 2008? How do you differ from other companies? Is there something in your project/people management style that makes you the best working place in Finland?

We contribute an exceptional amount of effort into the skills and well-being of our staff. We want to offer our employees the best opportunities for learning and personal development, and possibility to become top experts in their fields.

Our work is based on human values. The only way to succeed is to keep the best experts in the field committed to the company.

We see our employees as people, not simply resources. This thinking manifests itself in such things as flexible and reasonable working hours (no overwork as a rule).

Mitkä asiat projektinhallinnassa korostuvat silloin, kun projekti läpiviedään ketterillä menetelmillä?

• Luottamus täytyy olla kunnossa asiakkaan kanssa ja tiimin sisällä, koska tiimit ovat itseohjautuvia
  
• Läpinäkyvyys asiakkalle (projektin tila näkyy jatkuvasti, lisää ennustettavuutta ja vähentää arvailua)
  
• Asiakkaan sitouttaminen läpi projektin (joskus alkuinnostuksen jälkeen haasteellista)
  
• Muutoksien hallinta (hyväksytään se tosiasia, että muutoksia tulee ja ne käsitellään)
  
• Mahdollinen muutosvastarinnan hallinta, tiimin ja asiakkaan motivointi ja kouluttaminen silloin, kun ketterät menetelmät viedään uutena asiana projektiin
  
• Vanhan maailman tiimitaidot ja diplomatian tarpeellisuus eivät katoa minnekään!
  

Mitä tehdään, jos tuottavuus on yksinkertaisesti liian heikko tai ihmiset eivät innostu?

Tässä kysymyksessä viitataan ilmeisesti tiimiin ja timin tuottavuuteen. Täytyy lähteä etsimään ja purkamaan syitä, miksi tiimin tuottavuus on laskussa ja motivaatio kateissa.

• Vuodenajat: Ihminen on vuodenaikaihminen. Tuottavuus laskee aina ennen lomia, kesälomia tai joululomia, koska tiimin jäsenet ovat väsyneitä. Tämä on hyvä huomioida tehokkuusluvuissa, tiimin lomien suunnittelussa ja releasen aikataulua suunitellessa.
  
• Turhautuneisuus. Koska scrumissa tiimin jäsen valitsee itselleen työtehtävän, on joskus vaikea ilmaista muille tiimin jäsenille, että onkin tullut haukanneeksi liian suuren palan, asia on liian vaikea. Silloin työ ei tunnu etenevän ja motivaatio laskee. Lääke: Parikoodausvuorot. Pidetään säännöllisin väliajoin parikoodaussessioita, jolloin osaaminen leviää tiimin sisällä ja ongelmatilanteet purkautuvat.
  
• Väsymys ja jännite. Lääke: vaihdetaan välillä tiimin sisällä istumapaikkoja. Näinkin pieni asia välillä piristää ja alentaa kynnystä kysyä uudelta vieruskaverilta asioita.
  
• Tiimi ei keskustele, tai jos keskustelee, vain daily scrumin pakottamana. Lääke: yritetään keksiä tiimille yhteinen tekijä, vietetään vapaa-aikaa yhdessä jonkun mukavan asian parissa. Otetaan käyttöön daily scrumien yhteydessä ”daily scrum hug”, halausterapia J On tärkeää tuntea tiimin jäsenet myös persoonina.
  
• Pidetään joka sprintin jälkeen retrospectiivi, joissa voi purkaa tunteitaan
  
• Pidetään tiimit tarpeeksi pieninä (suurissa tiimeissä avoimuus kärsii)
  
• Aikatulun luoma stressi. Lääke: taklataan kohtuuttomat odotukset, pilkotaan tekeminen mahdolliseksi
  

Fakta: mistä tahansa joukosta ei voi kuitenkaan leipoa huipputiimiä!

Kuinka oleellinen osa (prosentteina työajasta) projektipäällikön työtä on uusien tekniikoiden aktiivinen opetteleminen/haisteleminen sekä prototyyppaaminen? Eli onko firmalle perusteltua kannustaa projektipäällikköä tietyssä määrin ”vain testailemaan juttuja” (konsultoimaan myös tuttujaan jne.), joista saattaisi löytyä tehostusta yrityksen toimintaan? Toisaalta jos projektipäällikölle ei sallita tätä mahdollisuutta, onko oletettavaa, että moni kyllästyy samaan tylsään työhönsä?

Näppituntumalla sanoisin, että 20% työajasta on uusien tekniikoiden etsimistä/opettelemista

Mitä eri projektinhallinnan työkaluja suosittelisitte ja miksi?

Scrum itsessään sisältää tarvittavat työkalut (product backlog, sprint backlog ja burndown chartit). Se, miten nämä visualisoidaan (excelissä vai whiteboardeilla) on oma valinta.

Does project management involve a lot of politics
-Yes it does. J

Haluaisin saada vinkkejä ja hyviä käytäntöjä viestintään hankalassa asiakassuhteessa.

Kukaan (tai hyvin harva meistä) on tarkoituksellisesti hankala. Jos asiakas tuntuu viestinnällisesti haastavalta, on selvitettävä, mikä on hänen oikea ongelmansa. Yleensä 90% ongelmista johtuu tavasta, millä asioita hoidetaan ja vain 10% itse ongelmasta. Joskus taustalta voi löytyä erilaisia poliittisia agendoja tai epävarmuutta, jotka näkyvät päällepäin asioiden hankaloittamisena. Tärkein ase on siis hyvät tuntosarvet, joilla kartoittaa tilanteen ilmapiiri, ennen kuin itse ongelmaa lähtee suinpäin purkamaan

Use Cases vs. User Stories?

• User Stories are comprehensible by everyone and easier to estimate
  
• Use cases are more formal, have more details and more relations
  
• Nobody really gets the entire use case set fully correct at the start, the set adds too much detail too early -> they'll change anyway, so why not use User Stories?
  
• It is easier to get users to write down what they really need on a card than it is to get them to see the difference between uses and extends -> user stories are quicker to write
  
• "I think the difference between using nothing and using either User Story or Use Case is more important than the difference between User Story and Use Case. " - Boris Maltha
  

Kommunikointi scrum-tiimien välillä?

Joskun tosiaan iso projekti vaatii useamman scrum-tiimin. Tällaisen projektin hallintaa kutsutaan Scrum of Scrumiksi.

Jokainen samaan projektiin kuuluva tiimi pitää daily scruminsa joko samaan aikaan tai sitten peräkkäin porrastetusti. Näiden daily scrumien jälkeen jokainen tiimi nimeää henkilön, joka sitten osallistuu vielä yhteen scrumiin, ”scrum-of-scrumiin”, jossa on läsnä jokaisesta tiimistä valittu yksi edustaja. Tässä scrum-of-scumissa sitten tiimien edustajat päivittävät statuksensa, ja jakavat tietouttaan sitten edelleen omalle tiimilleen. On tärkeää, että tiimin edustaja vaihtuu säännöllisin väliajoin, edustajan ei tarvitse olla Scrum Master.

Päivittäisessä scrum-of-scrumissa voidaan esittää myös ylimääräinen, neljäs kysymys: ”Onko jotain esteitä, mitä minun tiimini saattaa asettaa jonkun toisen tiimin tielle?”

Osa on sitä mieltä, että scrum-of-scrumia ei ole tarpeen pitää joka päivä, vaan 3 kertaa viikossa riittää.

Distributed Software Development

For those interested in the topic, the book Global Software Teams by Erran Carmel can be recommended as a starting point. Another notable researcher on the field of global software development is James D. Herbsleb. Many of my ideas and results presented at the lecture are based on Maria Paasivaara's PhD dissertation, which discusses about distributed product development practices from both manufacturing and from software development industries.

Recently, researches at SoberIT have been studying also the use of agile processes in globally distributed software development. This is a topic that wasn't covered too much during the lecture, but there are few articles that can worth reading:

• Paasivaara, Lassenius: Could Global Software Development Benefit from Agile Methods?
  
• Paasivaara, Durasiewicz, Lassenius: Using scrum in a globally distributed project: a case study
  

Scheduling software projects

Careful assessment, specification and estimation of project contents, context and constraints helps to create a feasible and sensible schedule for software project. While in some cases this means a lot of trivial, routine work, such as writing documentation or creating Gantt charts, often the most useful outcome from the scheduling exercise is the increased awareness of issues affecting the project. By forcing oneself to create a schedule that can be defended in a tough situation requires a lot of thinking, a lot of reasoning behind the decisions made. Creating the schedule itself is often trivial, but being able to do a great schedule is really hard work.

Software projects are unique by definition. This means that when we are planning a project it is very difficult to understand every aspect and every activity it takes to complete it. There will be changes. There will be surprises. There are issues that we know should be there, but we simply don't know what they really are. Planning for contingencies, adding buffer, managing risks is important. Managing expectations of various stakeholders is equally important.

Furthermore, just having a schedule does not add much value. Only a schedule, that is made visible to all relevant parties, that is monitored, and that is updated when needed, is really valuable. Creating a schedule, and never visiting it again during the project, is waste. The key to imperfection and inefficiency is to embrace waste, the key to better projects is to eliminate waste. If you don't want to monitor and maintain the schedule, why would you want to spend time creating one?

There are relatively few things project manager can do to control and steer the project directly. This doesn't mean that project manager doesn't matter. Understanding and acknowledging the situation the project has is the starting point for changing course. Analyzing, visualizing and discussing the situation to all stakeholders will help the project manager to make them committed to the change. At least they are aware of the situation, and the potential consequences.