1. Contract
1.1. Estimate as good as possible
1.2. If projects releases sooner
1.2.1. only half of the remaining estimated work needs to be payed
1.3. if project releases later
1.3.1. only half of the extra cost is payed
1.3.2. other half is payed by supplier
1.4. equal incentive for both parties to go for maximum business value and minimum cost
2. kanban designs
2.1. swimmers & floaters
2.1.1. can be used as promotion scheme as well
2.1.2. juniors can be safely educated
2.1.3. swimlanes are always covered
2.1.4. floaters help out to get most value out
2.2. portfolio kanban
2.2.1. additional to team board
2.2.1.1. which is heavy on details on team process
2.2.2. a summary board on a higher level
2.2.2.1. near coffeemachine
2.2.2.2. very visisble
2.2.2.3. invite mgt/biz each time they want info
2.2.3. cards
2.2.3.1. projects or initiatives
2.2.3.2. markers
2.2.3.2.1. can be department
2.2.3.2.2. or risk indicator
2.2.3.2.3. colors or tags
2.3. annotate 'smileys'
2.3.1. when story is done
2.3.2. trigger point for retro's
2.3.3. how do you feel after this work is done
2.3.3.1. customer may be happy but are you ?
2.3.3.2. code kwality
2.3.3.3. risks under the hood
2.3.3.4. your design was'nt accepted by team lead
2.3.3.4.1. not enough time to discuss properly
2.4. don't stop until you have mapped the WHOLE system
2.4.1. from idea to delivery
2.4.2. why are things how they are ?
2.4.3. make it all visible
2.4.4. stay attentive for the politics
3. Coaching
3.1. Visualize the invisible
3.1.1. Map the Agile Manifesto (0-5) P&R | | | | | | P & T W S | | | | | | Doc
3.1.2. Map culture from the perspective of each role
3.1.2.1. look for differences
3.1.2.2. top circles are very hard to change
3.1.2.3. bottom circles are easiest to change
3.2. Bottlenecks
3.2.1. position
3.2.1.1. balance
3.2.1.1.1. upstream
3.2.1.1.2. downstream
3.3. How to decide what todo next
3.3.1. Risk
3.3.1.1. use graphs rather than tons of number in massive spreadsheets to communicate quickly and easy
3.3.1.2. cost of delay shape
3.3.1.2.1. Categories
3.3.1.2.2. use as swimlanes
3.3.1.3. impact
3.3.1.3.1. categories
3.3.1.3.2. use as tags on project cards
3.3.1.4. Market
3.3.1.4.1. Differentiators
3.3.1.4.2. table stakes
3.3.1.4.3. spoilers
3.3.1.4.4. cost reduction
3.3.1.5. Life Cycle
3.3.1.5.1. New
3.3.1.5.2. Market growth
3.3.1.5.3. Cash cow
3.3.1.6. simple reporting
3.3.1.6.1. when towards outside : start soon when towards inside : start late or : the bigger the surface, the faster you need to start this
3.3.2. source: David J. Anderson
3.3.3. Options
3.3.3.1. when future is uncertain
3.3.3.1.1. investigate in lots of options
3.3.3.2. can be discarted
3.3.3.2.1. when you need to release
3.3.4. start as late as possible
3.3.4.1. 85% of the Cycle Time (time it takes IT to get from specifiaction to implementation)
3.4. Metrics
3.4.1. Liquidity
3.4.1.1. # transactions on the board / time
3.4.1.2. the more transactions, the faster work flows through the system
3.4.1.3. while keeping # columns constant
3.4.2. bonuses
3.4.2.1. DON'T
3.4.2.2. people always optimize for the bonus
3.4.2.3. people generally don't optimize for the purpose of the bonus
3.5. WIP
3.5.1. limit
3.5.1.1. broken
3.5.1.1.1. do it if needed
3.5.1.1.2. do ASARP a retro about it to change process so that we never have this again (for this reason)
3.6. 'J' curve
3.6.1. most change intiatives experience a drop in productivity
3.6.1.1. BIG bang changes
3.6.1.1.1. revolution
3.6.1.1.2. big risk
3.6.1.1.3. high costs
3.6.1.2. Kaizen
3.6.1.2.1. keep drop within confort zone
3.6.1.2.2. let team get accustomed to change
3.6.1.2.3. most improvments are 'policy' changes
3.6.1.2.4. close the PDCA loop
3.7. Toyota kata
3.7.1. kata
3.7.1.1. repeatable pattern to practice
3.7.1.2. so that it can become a new habit
3.7.2. steps
3.7.2.1. B
3.7.2.1.1. sketch
3.7.2.1.2. fluctuations
3.7.2.1.3. Details
3.7.2.2. C
3.7.2.2.1. small changes
3.7.2.2.2. determine kaizen steps
3.7.2.2.3. set a date
4. Problem sources
4.1. Distributed teams
4.1.1. visual
4.1.1.1. BIG screens needed
4.1.1.2. strategical posisioned webcams
4.1.1.2.1. to capture whole team
4.1.1.3. interesting
4.1.1.3.1. a lot of effective teams often go back to fysical boards
4.1.2. audio
4.1.2.1. google hangout
4.1.2.2. Clearone Chat 6.0
4.1.2.3. always open
4.1.2.3.1. hear each other
4.1.3. bandwidth
4.1.3.1. need a lot to be effective
4.2. Interrupts
4.2.1. visualize unplanned work
4.2.2. contact person
4.2.2.1. only the one with the marker (ususally a silly puppet) can be interrupted
4.2.2.2. rotate role
4.2.3. treshhold for tickets
4.2.3.1. make ticket
4.2.3.1.1. if work is more than 'n' minutes
4.2.3.1.2. if there are dependencies
4.2.3.1.3. specialized work is required
4.2.3.1.4. visibility is needed
4.2.3.2. transaction cost vs value
4.3. Dependencies
4.3.1. when blocked (out of team's control)
4.3.1.1. append red post it
4.3.1.1.1. DOT-mark the duration
4.3.1.2. when unblocked, append to the back of the card
4.3.1.2.1. so you keep a log of dependencies
4.4. Specialities
5. Adoption
5.1. why so dificult
5.2. 75% of the teams do not get expected result
5.2.1. usually problem lies not in writing the software
5.2.2. most problems lie in 98% utilisation
5.2.2.1. cost of buffers are usually not taken into the equation
5.3. 70% does not want to go back though
5.3.1. 50% when adoption was pushed