Last week I attended the Advanced Agile Development class, organised by Xebia and given by Alistair Cockburn. With this post, I try to make my notes persistent for future reference.
these are my notes. they are far from complete. as seen from this tweet, the class was really advanced :)
But I did survive!
- craft; deepening (life long learning) skills in a medium (for instance a progr language); shu-ha-ri
- cooperative game; all about strategies (invent, decide, communicate)
- flow management; manufacturing lines; palette size
- self awareness/ personalities; everybody is different, look at the personalities in your team
- design as a knowledge acquisition; try to get as much knowledge as you can with every step
Learning takes place in three stages:
- SHU - learn a skill; copying a technique step by step
- HA - collect techniques; search for other techniques to try.
- RI - blend and invent techniques; knowledge and experience are combined into something new
Do not try to become RI without really archiving that level. Otherwise you are just picking techniques and doing something that you do not understand.
good trick > technique > process > dogma It starts with a ‘good trick’, that becomes a technique, which is formulated into a process and that becomes a dogma. You have to bring everything back to a ‘good trick’. There are no rules. Master agile and reach RI level.
The speed of the project is the speed at which ideas move between minds
- what are conditions to facilitate speed: colocation, …
- attitude: ego, fear, self preservation, …
Programming is Community Theory Building Communication is touching into shared experiences
Development is a cooperative game: Invent, Decide, Communicate primary goal: deliver working software secondary goal: set up for the next game (maintenaince, new release)
Design looks like manufacturing if we use ‘decisions’ as inventory. Let the decisions flow through the team. Find the bottleneck and fix the process.
Remove waste. Example: tracking bugs is waste, we need to fix them.
Design is knowledge acquisition
Software development is like knowledge acquisition. Eliminate risks early on.
- business risk: are we building the right thing
- social risk: can they/we build it
- technical risk: performance, compatibility
- cost schedule risk: see if features change the costs of other parts of the project.
trim the tail: first do risk, then do value, then do the fine-tuning/glossy/polishing slicing helps with trimming the tail; build complete vertical-slices of user stories.
Properties of success projects
- frequent delivery; quick visible progress; stakeholders can give feedback; little steps so little errors
- reflective improvement; evaluate to improve
- close/osmotic communication; communication should be easy, everybody should be involved
- personal safety; willing to listen to others & ability to speak without fear to be damaged; trust for everybody to be part of the team
- focus; knowing what to work on, having time to work on it; distraction
- easy access to expert users; quick and better feedback on decisions
- technical environment; trust to try stuff out; unit tests/ CI/ version control
- sunshine/visibility; transparency; be honest when failing; motivation