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.

Interesting lectures from industry people

Today, I occasionally visited the starting lecture of T-110.6000 Internet and Computing Forum P. The first lecture by Tuomas Syrjänen from Futurice was about rapid software development. There were several ideas that could (and should) be interesting to people interested in learning and improving software project management and software development practices. As far as I understood, both the lecture slides and the video recording of the lectures should eventually become available at their web site.

In any case, I'm aiming at participating the lectures from that course, and based on today's experience, can recommend this to others as well. Of course, some of the future topics are not that well connected to software project management, but are nonetheless interesting.

Estimating software projects

There are several aspects of software project that can be estimated. Most commonly the target of estimation in software projects is the effort needed to complete the project. Based on the effort estimate, a schedule can be built for the project. In many cases, in order to estimate the effort needed for the project, it's size must be estimated.

The estimation techniques can be roughly divided into two categories: heuristic estimation methods ("expert estimation") and algorithmic models ("formal methods"). Heuristic methods are based on knowledge and experience of one or more individuals, while algorithmic models are more formally specified, and are based on quantifiable input on the project. Commonly it is considered useful to combine several methods, in the best case both expert and algorithmic estimation is used. When combining the methods, the underlying assumptions should be evaluated and assessed when comparing the results from different methods. While many techniques can provide fairly accurate results, the largest benefit can be indeed exploited by understanding how these methods come up with their respective estimates.

I have written extra material for algorithmic models. Hopefully this material, and its references, will help you to understand how function point analysis and constructive cost model should be applied to software project estimation. Also, the Wikipedia article on software development effort estimation is one starting point for more information. For recent research on software project estimation, I recommend to browse through the research articles by professor Magne Jørgensen from Simula Research Laboratory, Norway.

Lectures in MP3 format

The lectures of this course in mp3 format are now available at the Noppa page of this course. The files are totally unedited and unfiltered, so you may expect few minutes of delays in the beginning. Sorry for any inconvenience - I try to minimize my own work and reduce latency in publishing the files.

The links to mp3 are in the header, and stored on another server, as Noppa has a maximum limit of 50M per file :) Let me know if there are any problems.

Any comments or improvement ideas on mp3s are welcome.

Choosing process model

The selection of process model for a software project is a tedious task. There are many factors affecting the optimal choice of software process framework for a process. When selecting a process model, one must carefully assess the context of the project:

• Is the project small or large in terms of effort, schedule, or business value?
  
• How much risk is involved in the project? What is the relative importance of this project in comparison to other projects, and the overall activities of the company?
  
• How much changes can be anticipated? Is it possible to come up with stable, definitive requirements for the project up-front, or do we have to work on something, and rely on customer feedback for next steps?
  
• How many people are involved in the project, both directly and indirectly? How competent are they? Are they familiar with the process we are planning to use?
  
• Is the whole team located at same room, floor, building? How are we going to communicate during the project?
  

Also, in reality, there are several constraints in selecting the process model, often leading to suboptimal process choice for a given project. Especially in larger companies, there are often only one (or at most, a couple) process framework, that must be followed in all endeavours of the organization. If you are planning to use e.g. agile practices, and the organization is not familiar with the principles, are you able to get management buy-in for your ideas?

While the evolution of software process models have historically moved from document-driven (or plan-driven), waterfallish models towards more flexible agile methods, there still is no silver bullet process framework. New process models often aim to fix the problems of earlier paradigms and models, but as with most improvements, this often leads to other challenges. There is still relatively few research on using agile practices in producing large, complex software systems. In general, agile practices shed little (if any) light into issues related to software maintenance, or software as a service. Document-driven methods are strong with requirements engineering, while e.g. Scrum hides the issue behind the concept of Product Owner, and backlog items. On the other hand, agile practices highlight the importance of team motivation and (informal) communication; an aspect document-driven models often neglect.

The selection of process model affects management of software project in several ways. The pace and contents of interaction with the customer / end-user are highly affected by the software process model in use. The roles used by software development organization should be aligned with the software process model. Even the structure of the product to be developed must match with the chosen organization and practices of the software project team.

When considering issues with software processes, it is very important to keep critical attitude, and ask questions. There still are no simple answers to difficult questions.

For those more interested in software processes, TKK provides an excellent course on the topic.

Exercises

Hello all,

The exercises for the course have been published, please see assignments page in course web page for more details.

Last two exercises are made in groups, so you can start forming your team now. The course newsgroup may help you in this endeavour.

br,

Tuomas

Welcome to the Course, Spring 2009

Dear student of course T-76.5612 Software Project Management,

Welcome to the course, and to the course blog!

As the topic suggests, this course is about software projects, and how to manage them. We will be discussing several aspects of software project management, especially focusing on following issues:

• What is a software project?
  
• Constraints, goals and types of a software project
  
• Software processes in software project management
  
• Software project estimation
  
• Budgeting, scheduling and monitoring software project
  
• Software quality and risk management
  
• Leadership and management in software projects
  
• Distributed software development
  

In addition to lectures given by the course personnel, we will have guest lectures from industry with varying topics. As software project management is an art that cannot be fully taught or studied from theoretical perspective, I encourage you to explore all possibilities to exploit their insights and experience on software project management - you may learn how to do so with the lectures given by course personnel! Thus, I encourage you to be active during the lectures and throughout the course.

In addition to intellectual debates, it is worth to remember, that we are all human, and mistakes can and will occur; in any case you don't understand what is being said, or course arrangements just doesn't make sense to you, please ask!

The authoritative source of information for the course assignments is the course page in Noppa portal. Please make sure you have subscribed to course news, either by email or RSS. More specific instructions how to do so are available at the Noppa portal.

This blog will serve as auxillary communication channel during the course. Passing the course is completely possible without ever reading this blog, but more detailed insights and discussion about lecture topics and other interesting issues will be posted on this blog. As a rule, we aim at posting to blog after each lecture, to summarize the points from the lecture, as well as raise some important issues. We will also answer to any questions, in case any is raised (either in the lecture, or afterwards).

That said, I'd like to have active participation and discussion on the blog, for two reasons. Firstly, I hope interacting with you on this blog over the topics of the course will help both you and me to understand the discussed issues more deeply. Secondly, the blog can serve as very informal, yet effective feedback channel, so in case you have any suggestions or worries about the course format, exercises or software project management in general, please post a comment.

In this course, we will embrace activity. Therefore extra points will be awarded based on activity, both during lectures and in the blog.