Retrospektiivi: Pikatreffit

Tämä retrospektiivi on loistava jos tiimissä on hiljaisempia henkilöitä, joita on vaikea saada aktivoitua osaksi keskusteluita. Pikatreffit saa luontevasti kaikki keskustelemaan keskenään ja hakemaan ratkaisuja.

2016-11-02-10-21-12

Alustus

  1. Pyydä tiimiläisiä kirjoittamaan lapuille hiljaisuudessa 3 minuutissa niin paljon keskusteluaiheita kuin tulee mieleen.
  2. Pyydä jokaista valitsemaan yksi aihe joka on heidän omasta mielestään tärkein johon hakea ratkaisua.
  3. Anna kaikille 5 minuuttia aikaa kirjoittaa indeksikortin toiselle puolelle viisi sanaa tai lausetta ongelmasta johon he hakevat ratkaisua.
  4. Anna toiset 5 minuuttia aikaa ja pyydä piirtämään kortin toiselle puolelle kuva tai vertauskuva joka parhaiten kuvaa ongelmaa. Kuvaa ei näytetä muille vaan se on vain itseä varten.

Pikatreffit

  1. Aloita pikatreffit siten, että kehässä jokaisen vastapuolella oleva henkilö on tämän pari.
  2. Jokaiselle kierrokselle 5 minuuttia aikaa toinen selittää ensin oman ongelmansa ja sen jälkeen keskustella ratkaisusta. Pyydä ongelman esittäjää kirjaamaan muistiinpanoja mahdollisista ratkaisuista.
  3. Kierrätä pareja niin, että kaikki puhuvat kaikkien kanssa ja jokainen saa selittää oman ongelmansa kaikille.

Jos osallistujia on pariton määrä voit antaa parittoman seurata muiden keskustelua kuitenkaan kommentoimatta. Vaihtoehtoisesti pariton voi osallistua kolmantena pyöränä yhteen pareista. Tällöin kyseessä on swinger pikatreffit. Näistä vaihtoehdoista hiljainen seuraaja toimii paremmin koska kolmen hengen keskustelusta meinaa loppua aika.

Purkaminen

  1. Anna kaikille vielä 3 minuuttia aikaa valmistella oma ratkaisuehdotus pohjautuen käytyihin keskusteluihin
  2. Pyydä jokaista vuorollaan tulemaan eteen ja esittelemään mielestään parhaan ratkaisun jota haluaisi kokeilla seuraavassa sprintissä.

Lähteet

 

Miten tilaaja pystyy seuraamaan toimitusaikataulun toteutumista mahdollisimman yksinkertaisesesti?

burnup-kuvaaja2

Tämä postaus liittyy oleellisesti aikaisempiin postauksiini Miten varmistetaan se, että tilaaja saa sovitulla hinnalla mitä on haluttu? ja Voiko vauhtia käyttää tehokkuuden mittarina?

Yksinkertaisin tapa seurata projektin toimitusaikataulun etenemistä on burnup- (Burnup chart) tai burndown-kuvaaja (Burndown chart). Burndown-kuvaaja on erityisen hyvä silloin kun tiedetään etukäteen toteutettava laajuus. Burndown-kuvaaja soveltuu erityisen hyvin sprintin tai kiinteähintaisen projektin serurantaan. Yleensä projektin tasolla burndown-kuvaaja ei ole kovin havainnollinen, koska koko laajuutta harvoin tiedetään ennen projektin alkamista. Projektin etenemisen seurantaan sopii paljon paremmin burnup-kuvaaja.

burnup-kuvaaja2-selityksin

Burnup-kuvaajasta näkee yhdellä silmäyksellä nopeasti mikä projektin tilanne on. Burnup-kuvaajan oleellisimman elementit ovat toteutunut laajuus (vauhti), suunniteltu laajuus, sekä ennustettu laajuus. Yllä olevassa burnup-kuvaajassa sininen viiva kuvaa suunniteltua laajuutta, keltainen toteutunutta laajuutta ja ohut harmaa viiva ennustettua vauhtia. Tässä burnup-kuvaajassa on lisäksi näkyvissä oranssilla alueella ennusteen virhemarginaali perustuen tilastolliseen analyysiin toteutuneesta vauhdista.

Burnup-kuvaajasta voidaan arvioida onko projekti suunnitellussa aikataulussa katsomalla missä kohtaa ennustettu vauhti ja suunniteltu laajuus viivat risteävät. Lisäksi mikäli virhemarginaali on laskettu voidaan arvoida miten todennäköistä tavoitteen saavuttaminen on. Yllä olevasta esimerkistä nähdään, että suunniteltu laajuus valmistuu aikaisintaan syyskuuun alkupuolella (piste 1). Pessimistisen arvion mukaan suunniteltu laajuus saavutetaan kuitenkin vasta marraskuun alkupuolella (piste 3), mutta todennäköisesti laajuus saavutetaan jossain lokakuun alkupuolella (piste 2).

Esimerkissä olevan projektin kokonaislaajuus on elänyt varsin paljon projektin alkupuolella. Projektin alkupuolella on ensin karsittu laajuutta ja sen jälkeen se kasvanut voimakkaasti ja sitten taas laajuutta on karsittu vastaamaan alkuperäistä. Laajuuden pienentäminen tai suurentaminen vaikuttaa suoraan projektin kustannuksiin. Koska ketterää projektia tehdään kiinteällä tiimillä ja vakio mittaisissa sprinteissä voidaan suoraan kuluneen kalenteriajan perusteella arvioida projektin kustannukset.

Toteutunut vauhti näkyy ylläolevassa burnup-kuvaajassa keltaisella. Esimerkkinä olevassa projektissa kehitystiimi on kyennyt tuottamaan ominaisuuksia melko tasaisella tahdilla. Toteutuneen vauhdin pohjalta on sitten laskettu ennuste tiimin keskimääräisestä vaudista ja sen virhemarginaalista. Ennustettua vauhtia kuvaa ohut harmaa viiva oranssin virhemarginaali alueen sisällä. Esimerkistä näkyy virhemarginaalin kasvaminen mitä kauenmmas tulevaisuuteen yritetään ennustaa. Tässä burnup-kuvaajassa on ennusteessa otettu huomioon myös tiedossa olevat lomat ja sen takia ennuste on lähes suora viiva heinä-elokuussa (piste 4).

Burnup-kuvaaja on siis erittäin helppo ja visuaalinen tapa havainnoida projektin etenemistä. Burnup-kuvaajan hyviin puoliin kuuluu lisäksi se, että sen saa nykyään ulos lähes kaikista sähköisistä ketterän kehityksen työkaluista ja se on helppo piirtää taululle käsin tarpeen vaatiessa.

Voiko vauhtia käyttää tehokkuuden mittarina?

Tiimin vauhti

Ketterässä kehityksessä käytetään useasti käsitettä vauhti (velocity) tulevaisuuden ennustamiseen. Mikä tämä vauhti on ja voisiko sitä käyttää tiimin tehokkuuden mittarina? Lyhyesti sanottuna vauhti on ennustamisen työkalu ei tehokkuuden mittari. Tästä syystä vauhtia voi käyttää ainoastaan tulevaisuuden ennustamiseen eikä sitä voi käyttää kuvaamaan tehokkuutta millään asteella. Miksikö sitten? Jos kerran vauhti hidastuu niin eikös se ole paha asia?

Oleellista on ymmärtää ensin miten tiimin vauhti määräytyy. Ensimmäinen kysymys on tietysti, että mikä on vauhdin yksikkö? Onko se tuntia, päivää tai kenties ideaalipäivää? Vastaus on, että ei mitään näistä. Vauhdin yksikköä kutsutaan monesti tarinapisteeksi (story point), mutta yksinkertaisesti kyseessä on tiimin kehittäjien hihasta heittämä vertailuluku, joka kertoo minkä kokoisia vaatimukset ovat suhteessa toisiinsa.

Suunniteltu ja toteutunut vauhti

Sprintin suunnittelussa tiimi valitsee työjonosta toteutettavakseen vaatimuksia. Tiimi päättää täysin itsenäisesti paljonko se kykenee seuraavan kahden viikon aikana toteuttamaan. Tämän arvauksen pohjalta saadaan suunniteltu vauhti, eli paljonko tiimi arvioi kykenevänsä toteuttamaan seuraavan sprintin aikana. Valittaessa vaatimuksia työjonosta ei valittavien vaatimusten määrää perusteta aikaisempien sprinttien vauhtiin vaan kyseessä on aina uusi arvio sen hetkisen parhaan mahdollisen tiedon pohjalta. Monesti suunniteltu vauhti on hyvin lähellä laskennallista vauhtia.

Tiimin toteutunut vauhti määräytyy sen perusteella kuinka paljon vaatimuksia on saatu toteutettua valmiiksi asti. Valmiit ominaisuudet ovat oikeasti valmiita ja testattuja, sellaisia jotka voisi viedä tuotantoon vaikka heti. Toteutunut vauhti voi heitellä monista eri syistä. Näitä voivat olla esimerkiksi ulkoiset riippuvuudet, laatuvelka, sairastumiset tai toteutumisvaiheessa havaittu vaatimuksen mutkistuminen tai yksinkertaistuminen.

Ulkoiset riippuvuudet

Ulkoinen riippuvuus voi olla esimerkiksi kolmannen osapuolen järjestelmä, jota vasten ei päästä testaamaan heti. Tämä voi johtua esimerkiksi siitä, että järjestelmän toimittaja ei kykene tarjoamaan tarvittavaan testiympäristöä tai oikeuksia kahden viikon sprintin aikana. Tällöin vaatimus jää työjonoon auki, eikä sen pisteitä lueta mukaan tiimin vauhtiin. Kun testaamiseen tarvittavat ympäristöt ja oikeudet sitten lopulta saadaan kirjautuvat valmiit tarinapisteet siihen sprinttiin, jossa tarina lopulta saatiin valmiiksi. Toinen vaihtoehto on myös uudelleen arvioida seuraavan sprintin suunnittelussa jäljellä olevat pisteet vaatimuksista joita ei saatu valmiiksi. Tällöin pisteitä ”katoaa” koska osa työstä on jo tehty, mutta  seuraavassa sprintissä vauhtiin lasketaan vain jäljellä olleet pisteet.

Laatuvelka

Toinen yleinen tapaus joka aiheuttaa vauhdin laskemista väliaikaisesti on teknisen velan kertyminen. Ketterässä kehityksessä lähdetään siitä, että bugit korjataan välittömästi, eikä niitä jätetä työjonoon priorisoitavaksi. On kuitenkin melko yleistä varsinkin uudella tiimillä, että kaikki sprintiin otetut vaatimukset pyritään saamaan valmiiksi hinnalla millä hyvänsä. Saadakseen asiat nopeammin valmiiksi tiimi tinkii yleensä huomaamattaan laadusta, jolloin työjonoon kertyy bugeja eli tekemätöntä työtä. Tekemättömälle työlle ei koskaan anneta työmääräarviota, koska se pitää tehdä välittömästi pois alta, jotta se ei ala kertymään. Tällöin voi käydä esimerkiksi niin, että seuraavaan sprinttiin tulee valtava määrä bugeja edellisestä sprintistä ja näiden korjaaminen on pois uusien vaatimusten toteuttamiselta. Keskimäärin näiden kahden sprintin vauhti antaa siis kelvollisen ennusteen siitä paljonko tiimi saa aikaan suuressa määrässä tulevia sprinttejä.

Vaatimuksen mutkistuminen tai yksinkertaistuminen

Työmäärä arviointiin pyritään käyttämään kohtuullisen vähän aikaa, koska siihen käytetty aika on pois vaatimusten toteuttamiselta. Tästä syystä melko useastikkin käy niin, että yksinkertaiselta näyttänyt vaatimus mutkistuu huomattavasti kun sitä aletaan toteuttamaan. Tämä on erityisen yleistä  kun siirrytään uuteen vähän tuntemattomaan kokonaisuuteen. Tällöin vauhti putoaa verrattuna suunniteltuun kun asiat osoittautuvat monimutkaisemmiksi kun miltä ne ovat näyttäneet. Tämä kuitenkin tasoittuu seuraavissa sprinteissä kun tiimi oppii miten uuden kokonaisuuden kanssa tulee toimia ja uudelleen pisteyttää vaatimuksia uuden parhaan mahdollisen tietonsa pohjalta.

Voisiko vauhtia käyttää tehokkuuden mittarina?

Kiusaus käyttää vauhtia tehokkuuden mittarina on yleensä varsin suuri johtajilla, jotka eivät ymmärrä mikä vauhti on ja mitkä ovat sen rajoitteet. Vauhtia ei yksinkertaisesti voi käyttää tehokkuuden mittarina, koska se on itsestään mukautuva. Itsestään mukautuva tarkoittaa sitä, että jos tiimin tehokkuus kasvaa kun tiimi oppii alkaa se myös arvioimaan vaatimukset pienempinä. Tästä syystä äkillinen tehokkuuden kasvu saattaa näkyä toteutuneessa vauhdissa piikkinä, mutta tasoittuu nopeasti pois kun jäljellä olevat vaatimukset  uudelleen pisteytetään uuden tiedon valossa. Tällöin se mikä aikaisemmin oli kahdeksan saattaa nyt olla kolme verrattuna muihin vaatimuksiin. Lopputuloksena vauhti tasoittuu taas takaisin lähelle pitkäaikaista keskiarvoaan.

Voisiko vauhtia käyttää tulospalkkauksen perusteena?

Jos vauhdista itsestään tekee tavoitteen esimerkiksi tekemällä siitä osan tulospalkkausta ampuu helposti itseään jalkaan. Koska tiimi määrittää itse pisteet ja paljonko se kykenee sprintissä toteuttamaan, voi se kertoa ääritilanteessa kaikki pisteet vaikkapa kymmenellä. Tällöin pisteet ovat edelleen vertailukelpoisia keskenään, mutta ne ovat kärsineet vakavasti inflaatiosta. Lisäksi jos vauhdin asettaa tavoitteeksi kannustaa se tiimiä ottamaan laatuvelkaa ja toivomaan, että se ei ehdi alkaa näkyä projektin aikana.

Mihin vauhtia voi sitten käyttää?

Vauhti on itsestään mukautuvuutensa ansiosta aivan loistava työkalu tulevaisuuden ennustamiseen. Käyttämällä sprinttien vauhdin keskiarvoa ennusteena siitä paljonko tiimi saa tehtyä vaikkapa seuraavan viiden sprintin aikana on varsin hyvä arvio. Koska vauhti saattaa heitellä paljonkin yksittäisten sprinttien välillä ei sitä voi käyttää kuin suuntaa antavasti seuraavan sprintin sisällön arvioimiseen. Viiden sprintin keskiarvo on kuitenkin heilahteluista huolimatta luultavasti hyvin lähellä historiallista keskiarvoa. Excel velhot voivat vauhtihistoriaa hyväksikäyttäen laskea melko hyvätkin tilastolliset ennusteet siitä millä todennäköisyydellä yhden sprintin suunniteltu laajuus saadaan toteutettua tai mitkä ovat todennäköisyydet viiden seuraavan sprintin tapauksessa.

Tulevaisuuden ennustamisessa melko yleinen keino on myös käyttää laskennallista vauhtia, joka ottaa huomioon arkipyhistä johtuvat työpäivien vaihtelut sprinteissä ja yksittäisten kehittäjien lomat. Laskennallisen vauhdin laskemisessa käytetään vauhtikerrointa (focus factor), joka on laskennallinen kerroin joka ottaa huomioon työpäivät ja tunnetut lomat. Kun vauhtikertoimella kertoo vauhdin keskiarvon saa vielä aavistuksen parempia ennusteita.

Esimerkki todelliselta tiimiltä

Tiimin vauhti merkinnöillä

Yllä oleva kuva on todellisen tiimin vauhtikuvaaja. Tiimi oli tässä vaiheessa työskennellyt vähän yli vuoden yhdessä ja kaikki sprintit olivat olleet kahden viikon mittaisia. Harmaa palkki kertoo tiimin sprintin suunnittelussa suunnitteleman laajuuden. Keltainen palkki kertoo toteutuneen vauhdin. Harmaa alue ilmaisee laskennallisen vauhdin ja sininen viiva kertoo tiimityytyväisyydestä.

Kohdassa 1 nähdään kun tiimi aloitti ja luonnollisestikkaan sillä ei ollut vielä mitään käsitystä siitä mitä se saa aikaan sprintissä. Tämän jälkeen nähdää kuitenkin heti, että jo sprintissä 2 vauhti asettui aika lähelle sen tulevaa keskiarvoa. Kohdassa 2 nähdään uuden tiimin yritys ottaa laatuvelkaa. Kohdassa 3 tiimi vaihtoi uuteen kokonaisuuteen, jolloin vaatimukset osoittautuivat monimutkaisemmiksi kuin oli etukäteen odotettu. Kohdassa 4 nähdään kuinka laskennallinen vauhti reagoi kesälomiin.

Kohdassa 5 voidaan nähdä, että suunniteltu vauhti kurottaa sprintistä 22 eteenpäin aina korkeammalle kuin toteutunut. On varsin tavallista, että vauhdin pudotuksen jälkeen tiimi yliarvio oman toteuttamiskykynsä. Lisäksi nähdään, että toteutunut vauhti on välillä yli laskennallisen ja välillä alle. Tämän ei sinänsä pitäisi olla mitenkään tavatonta kun ottaa huomioon, että laskennallinen perustuu määritelmän mukaan toteutuneen vauhdin keskiarvolle.

MSSQL error ”The specified network name is no longer available”

This problem has been bugging us for a long time. When you try to connect to Microsoft’s SQL Server using IP address with SQL Management studio you get this error:
A transport-level error has occurred when receiving results from the server. (provider: TCP Provider, error: 0 - The specified network name is no longer available.) (.Net SqlClient Data Provider)

When you dismiss the error it just keeps popping up time to time but otherwise everything seems to work. This is caused by the Management Studio attempting to connect to the SQL Server by the server name reported by the server. This can happen for example when your production environment is isolated from intranet and servers do not have fully qualified domain names.

However this is easy to fix, you just need to change the server name to correspond to the IP address of the server:

sp_dropserver <current name>;
sp_addserver 'a.b.c.d', local;

After this you need to restart the SQL Server’s instance and you are done. You can check that the new name set correcyly by running:

SELECT @@SERVERNAME

Miten varmistetaan, että tilaaja saa sovitulla hinnalla sen mitä on haluttu?

2015-09-02 17.27.01

Otsikon kysymys on kystty minulta useita kertoja ja vastaus on; ei mitenkään. Toisaalta myöskään kiinteissä toimitussopimuksissa sitä ei oikeasti voida taata. Tästä tunnettuna esimerkkinä HKL ja metron automatisointiprojekti. Eivät ne tiukat sopimukset ja lakimiehet vie sitä projektia eteenpäin vaan ainoastaan osaavat ihmiset, jotka kykenevät järjestelmän toimittamaan. Tiukka kiinteä sopimus ei auta yhtään jos toimittajalla ei ole osaamista tai byrokratiaan menee enemmän aikaa kuin itse tekemiseen.

Ketterässä menetelmässä lähdetään siitä lähtökohdasta, että kaikki tekijä osapuolet ovat ihmisiä, kaikkine inhimillisine vikoineen. Esimerkiksi edes parhaatkaan ammattilaiset eivät kykene tekemään täydellistä vaatimusmäärittelyä etukäteen. Ihmisten aivokapasiteetti ei yksinkertaisesti riitä. Jos kerran vaatimusmäärittelyäkään ei pysty tekemään täydellisesti niin miten sitten tämän päälle tehty valmis toteutussuunnitelma? Ketterässä tekemisessä lähdetään siitä, että vaatimusmäärittelyä ja suunnitelmaa ei voi tosiaan tehdä etukäteen inhimillisten rajoitusten vuoksi.

Ketterässä menetelmässä tiukka vaatimusmäärittely ja suunnitelma korvataan kommunikaatiolla asiakkaan kanssa. Tästä syystä on välttämätöntä, että asiakkaan edustaja ja kehitystiimi istuvat koko kehitysprojektin samassa huoneessa ja vierekkäin. Tämä takaa sen, että kommunikaatio toimii pakostikin eikä synny vastakkain asettelua vaan ollaan yhdessä tekemässä yhteistä projektia. Lisäksi ketterässä menetelmässä tarjotaan asiakkaalle jatkuvalla syötöllä selkeitä ennusteita ja mahdollisuutta tarkastella miten muutokset laajuuteen (eli vaatimuksiin) vaikuttavat toteutusaikatauluun eli suoraan kustannuksiin.

Ketterää projektia tehdään käytännössä aina tuntihintaisena tällöin on varsin suoraviivaista ennustaa paljonko tunteja halutulla budjetilla saa. Kun asiakkaalle lisäksi tarjotaan koko aika selkeät työkalut siihen, että hän näkee mihin jäljellä olevat rahat vielä riittävät niin projekti ei oikein voi epäonnistua mitenkään. Käytännössä säädetään siis vaatimuksia niin, että budjetilla saadaan paras mahdollinen tuotos mitä sillä on mahdollista saada. Alkuperäinen kysymys on itseasiassa asenteellinen ja väärä koska se kysyy imperfektissä mitä on haluttu. Oikeampi kysymys on, että miten taataan, että tilaaja saa jäljellä olevalla budjetilla mitä halutaan tämän hetken parhaalla mahdollisella tiedolla?

Tämän lisäksi kehitystiimi toimittaa kahden viikon välein julkaisukelpoisen version järjestelmästä ja jos tilaaja ei ole tyytyväinen tiimin työskentelyyn niin hän voi päättää sopimuksen omalta puoleltaan milloin tahansa ja etsiä uuden kumppanin tai palata vesiputouskehitysmalliin. Lisäksi hyväksymistestausta ei tehdä projektin lopussa vaan parasta olisi, että asiakkaalla olisi toimittaa henkilö hoitamaan hyväksymistestausta päivittäin tiimin kanssa, jolloin lopussa ei tule enää yllätyksiä.

Scrum- ja lean-terminologia suomeksi

Lekmannin blogissa on melko hyvä sanasto scrum-terminologiasta suomeksi. Lekmannin blogissa oleva sanasto on sovittu yhdessä suomen merkittävimpien scrum-kouluttajien kanssa. En ole kuitenkaan löytänyt pätevää suomalaista sanastoa jossa olisi myös lean-sanasto mukana. Postauksen alussa on kopio suoraan Lekmannin blogista ja postauksen loppupuolella on Lean-sanastoa. Päivittelen omia listojani sitä mukaa kun törmään termeihin joille kaipaan käännöstä tai kun joku ehdottaa parempaa käännöstä.

Scrum

Tämä on suoraan Lekmannin blogista:

Alkuperäinen termi Suositeltu suomennos
Scrum scrum
Product Backlog tuotteen kehitysjono
Sprint Backlog sprintin kehitysjono
Backlog Item kehitettävä asia / kehitysjonon kohta
Product Backlog Refining
(ent. grooming)
tuotteen kehitysjonon työstö
User Story käyttäjätarina
Task tehtävä
Increment tuoteversio
Order järjestys / järjestää
Forecast ennuste / ennustaa (sprintin tuottama toiminnallisuus)
Product Owner tuoteomistaja
Development Team kehitystiimi
Scrum Master scrummaster
Scrum Team scrumtiimi (ts. tuoteomistaja, kehitystiimi ja scrummaster)
Servant Leader palveleva johtaja (ts. scrummaster)
Stakeholder sidosryhmä
Sprint sprintti
Sprint Planning sprintin suunnittelu
Daily Scrum päiväpalaveri
Sprint Review sprintin katselmointi
Sprint Retrospective sprintin retrospektiivi
Sprint Burndown Chart sprintin edistymiskäyrä
Product Burndown Chart tuotteen edistymiskäyrä
Sprint Goal sprintin tavoite
Done valmis
Ready valmisteltu (tehtäväksi)
Event tapahtuma
Artifact tuotos
Role rooli
Impediment este
Time-Box aikaraja
Velocity vauhti
Focus Factor vauhtikerroin
Refactoring refaktorointi

Lisäksi lisäisin tähän sanastoon vielä seuraavat omat käännökseni:

Alkuperäinen termi Ehdotettu suomennos
Definition of Done Valmiin määritelmä
Definition of Ready Työstövalmiin määritelmä
Release definition of done Julkaisuvalmiin määritelmä
Agile Manifesto Ketterän ohjelmistokehityksen julistus

Lean

Nämä termit olen yrittänyt itse kerätä kasaan eri lähteistä. Näihin voi ehdottaa muutoksia ja päivittelen niitä tähän blogipostaukseen sitä mukaan kun joku keksii tai tietää parempia. Tavoitteena on välttää fingelskaa aina kun se on mahdollista ja tarkoituksenmukaista.

Alkuperäinen termi Ehdotettu suomennos
Empirical Process Control empiirinen prosessinohjaus
Defined Process Control määritelty prosessinohjaus
Push ja pull työntö- ja imuohjaus
Iterative toistuva
Incremantal laajeneva
Muda / Waste hukka
Eliminating waste hukan karsiminen
 Activity toiminta
 Value adding activity  arvoa lisäävä toiminta
 Non-value adding activity  arvoa lisäämätön toiminta
 Muri / Overburden  Ylikuormitus
 Mura / Unnecessary variation  Tarpeeton vaihtelu