1. Self-organising squads
1.1. Advantages
1.1.1. Autonomy
1.1.2. Ownership
1.2. Disadvantages
1.2.1. No one takes responsibility
1.3. Defined
1.3.1. distributed control, i.e. absence of centralised control
1.3.2. continuous adaptation to a changing environment
1.3.3. emergent structure from local interaction
1.3.4. feedback, both positive and negative
1.3.5. resilience due to the system’s ability to repair and adjust
1.4. resources
1.4.1. http://confluence.int.corp.sun/confluence/display/ALP/Self-Organising+Teams
2. Flow
2.1. balancing demand to capacity
2.1.1. tips:
2.1.1.1. stop your backlog from consistently growing over time
2.1.1.1.1. practice saying NO in the mirror!
2.1.1.2. know your capacity!
2.2. collect metrics
2.2.1. tips:
2.2.1.1. remember the difference between cycle time and lead time
2.2.1.1.1. cycle time is easier to game so prefer lead time measures
2.3. trading off resource and flow efficiency
2.3.1. tips:
2.3.1.1. you might not be able to achieve 'one piece flow' but avoid being a hospital full of busy specialists and unhappy patients
2.4. even out the arrival of work
2.4.1. tips:
2.4.1.1. make sure you have a roadmap and use it to have conversations with customers
2.4.1.2. program in slack time, so you can deal with the unexpected bumps
2.4.1.3. eradicate SPOKs so you can better deal with uneven increases of demand (e.g. a flood of requests for same work type), decreases of supply (e.g. people on vacation, moving on, etc.), or, when Murphy's law strikes, both at same time!
2.5. focus and swarm on problems
2.5.1. tips:
2.5.1.1. Stuck work is vermon
2.5.1.1.1. use prevention and cure techniques
2.6. establishing a regular cadence
2.6.1. tips:
2.6.1.1. grow a discipline of delivery to a drum beat
2.7. minimising the size of work items
2.7.1. tips:
2.7.1.1. end-to-end (aka vertical) slicing of work
2.8. limiting work in progress (WIP)
2.8.1. tips:
2.8.1.1. treat WIP as a liability
2.8.1.1.1. it's inventory in Lean terms
2.8.1.2. prioritise flow right-to-left
2.8.1.2.1. pull work only when you are ready
2.8.1.2.2. pull (rather than push) delivery
2.9. Your team is not feature factory!
2.9.1. tips:
2.9.1.1. be quick to measure the benefit of a feature
2.9.1.2. be quick to decommission a feature that is not proven itself
2.9.1.3. be quick to challenge the perceived value of any new feature proposed
2.9.1.3.1. be quick to test and learn it, exposing the unvalidated assumptions
3. JIRA
3.1. make sure you are across what it can do
3.1.1. find the Jira gurus in your area and spy on them
4. Metrics
4.1. take time to understand what you want to improve and how you will measure it
4.1.1. but beware of Goodhart's law
4.1.1.1. "When a measure becomes a target, it ceases to be a good measure"
4.2. lead and lag measures
5. Product Ownership
6. Others:
6.1. Broken Windows theory
6.1.1. https://en.wikipedia.org/wiki/Broken_windows_theory
6.2. adaptive planning
6.3. Seize the Day
6.3.1. StandUp
6.3.1.1. Figure out the best possible day the team could have today, and agree what we need to do to make it happen
6.3.1.2. opportunity to check in on what is moving and what has stalled
6.3.1.3. Revised 3 questions
6.3.1.3.1. 1. What work items moved yesterday?
6.3.1.3.2. 2. What work items are going to move today?
6.3.1.3.3. 3. What work items are blocked?
6.3.1.3.4. This helps the team identify work they believe is in progress that isn’t moving
6.3.2. The goal of a team is to deliver a continual flow of value
6.3.3. Alternatives?
6.3.3.1. Since the stand-up isn’t about updating the Scrum Master or delivery lead, when should they be receiving this information? The most effective mechanism I’ve seen for this was when I worked in a team where team lead prior to stand up would visit people at their desk, where they feel safe and aren’t standing exposed in front of the whole team, and simply check in with them.
6.3.3.2. As well as listening to their update he can sense their mood, tell if they are upbeat or feeling flat or frustrated, and maybe ask some clarifying questions and think about how he can help as their team lead. It was less time-efficient for the team lead, but more effective for the team. This is servant-leadership at its best
6.3.3.3. Each morning, the IM would start the stand-up at the card wall with a brief update on the status of each work item. This would take no more than a couple of minutes, and then the stand-up could move on to the more important matter of what was the best possible day we could have today. It gave everyone a shared understanding of progress without the dreaded zombie stand-up.
6.3.4. Summary
6.3.4.1. Stand-ups are often dry and formulaic.
6.3.4.2. The goal of a stand-up is to figure out the most effective day the team can have. Anything else is noise.
6.3.4.3. Status updates should happen elsewhere.
6.3.4.4. Some teams have more than one stand-up per day. Some have fewer
7. Key Quotes:
7.1. "People will tell you what they want when you have given them what they asked for"
7.2. No one is always busy. It just depends on what number you are on their priority list
7.2.1. “You have to decide what your highest priorities are and have the courage pleasantly, smilingly, and non-apologetically — to say “no” to other things. And the way to do that is by having a bigger yes burning inside.” -- Stephen Covey
8. Time Management
8.1. Run TEAM YOU like you would guide your team
8.1.1. Direction
8.1.1.1. Are you clear on the next most important thing to work on?
8.1.1.2. Are you co-creating solutions rather than taking orders or imposing your solution?
8.1.2. Focus
8.1.2.1. Are you ACTUALLY working on the most important thing?
8.1.2.2. Are you doing too many things to be effective?
8.1.3. Execution
8.1.3.1. Are you delivering to your commitments/outcomes?
8.1.3.2. Are you getting better through experimentation and learning?
9. high performing squads
9.1. clear, meaningful mission and value proposition
9.2. are in mode: 'I want to' rather than 'I have to' mode
9.3. dependability between members
9.4. safe to experiment and fail (psychological safety)
9.5. maximises diversity of thought
9.6. low performers are naturally exposed and called to account/ejected
9.7. https://rework.withgoogle.com/blog/five-keys-to-a-successful-google-team/
10. Servant leader
10.1. Inclusive
10.1.1. Actually care
10.1.2. Take time to know each person
10.2. defined
10.2.1. self-reflects
10.2.2. values diverse opinions
10.2.3. cultivates a culture of trust, respect and acts with humility
10.2.4. develops others as servant leaders
10.2.5. puts others first, encourages and helps people beyond just work issues
10.2.6. sells instead of tells
10.2.7. listens intently and observes closely
10.2.8. thinks long-term and demonstrates persistence
10.2.9. holds himself and others accountable for their commitments
11. Ideal team player desirable attributes
11.1. Humble
11.1.1. Defined
11.1.1.1. I compliment or praise them without hesitation.
11.1.1.2. I easily admit to my mistakes.
11.1.1.3. I am willing to take on lower-level work for the good of the team.
11.1.1.4. I gladly share credit for team accomplishments.
11.1.1.5. I readily acknowledge my weaknesses.
11.1.1.6. I offer and accept apologies graciously.
11.2. Hungry
11.2.1. Defined
11.2.1.1. I do more than what is required in my own job.
11.2.1.2. I have passion for the “mission” of the team.
11.2.1.3. I feel a sense of personal responsibility for the overall success of the team.
11.2.1.4. I am willing to contribute to and think about work outside of office hours.
11.2.1.5. I am willing to take on tedious or challenging tasks whenever necessary.
11.2.1.6. I look for opportunities to contribute outside of my area of responsibility.
11.3. People smarts
11.3.1. Defined
11.3.1.1. I generally understand what others are feeling during meetings and conversations.
11.3.1.2. I show empathy to others on the team.
11.3.1.3. I demonstrate an interest in the lives of my teammates.
11.3.1.4. I am an attentive listener.
11.3.1.5. I am aware of how my words and actions impact others on the team.
11.3.1.6. I adjust my behavior and style to fit the nature of a conversation or relationship.
12. Cynefin
12.1. Different problems warrant different decision making approaches
12.1.1. Sweet spot of Agile is complex, Lean is complicated
12.1.1.1. Agile makes progress with incomplete information
12.2. Different problems warrant different decision making approaches, Cynefin helps you pair the right approach to the corresponding situation
12.2.1. Choosing a waterfall approach means you are in a safe complicated domain
12.2.2. Often problems have the appearance of complicated when they are really in complex domain (so beware)
12.2.2.1. Analysis paralysis is a tell-tale sign
12.2.2.2. Remember "People will tell you what they want when you have given them what they asked for"
12.3. Goal Move around to obvious
13. Improvement Kata
14. Work breakdown
15. Poor practices and how to fix them
15.1. https://medium.com/@stefanw/sprint-retrospective-anti-patterns-a2af52d75ac5
15.1.1. Stefan Wolpers has a whole bunch of other articles on anti-patterns for different Agile practices/ceremonies
15.2. see 'Bad Smells' slides from these JIT packs
15.2.1. p19 PO JIT
15.2.1.1. http://info.int.corp.sun/sbs/Agile/Documents/TNG/Product%20Owner%20JIT.pptx
15.2.2. p12 Showcase JIT
15.2.2.1. http://info.int.corp.sun/sbs/Agile/Documents/Showcase%20JIT.pptx
15.2.3. p25 IM JIT
15.2.3.1. http://info.int.corp.sun/sbs/Agile/Documents/Iteration%20Management%20JIT.pptx
15.2.4. p17 IPM JIT
15.2.4.1. http://info.int.corp.sun/sbs/Agile/Documents/IPM%20JIT.pptx