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. Others:
4.1. Broken Windows theory
4.1.1. https://en.wikipedia.org/wiki/Broken_windows_theory
4.2. adaptive planning
4.3. Seize the Day
4.3.1. StandUp
4.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
4.3.1.2. opportunity to check in on what is moving and what has stalled
4.3.1.3. Revised 3 questions
4.3.1.3.1. 1. What work items moved yesterday?
4.3.1.3.2. 2. What work items are going to move today?
4.3.1.3.3. 3. What work items are blocked?
4.3.1.3.4. This helps the team identify work they believe is in progress that isn’t moving
4.3.2. The goal of a team is to deliver a continual flow of value
4.3.3. Alternatives?
4.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.
4.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
4.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.
4.3.4. Summary
4.3.4.1. Stand-ups are often dry and formulaic.
4.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.
4.3.4.3. Status updates should happen elsewhere.
4.3.4.4. Some teams have more than one stand-up per day. Some have fewer
5. Key Quotes:
5.1. "People will tell you what they want when you have given them what they asked for"
5.2. No one is always busy. It just depends on what number you are on their priority list
5.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
6. high performing squads
6.1. clear, meaningful mission and value proposition
6.2. are in mode: 'I want to' rather than 'I have to' mode
6.3. dependability between members
6.4. safe to experiment and fail (psychological safety)
6.5. maximises diversity of thought
6.6. low performers are naturally exposed and called to account/ejected
6.7. https://rework.withgoogle.com/blog/five-keys-to-a-successful-google-team/
7. Servant leader
7.1. Inclusive
7.1.1. Actually care
7.1.2. Take time to know each person
7.2. defined
7.2.1. self-reflects
7.2.2. values diverse opinions
7.2.3. cultivates a culture of trust, respect and acts with humility
7.2.4. develops others as servant leaders
7.2.5. puts others first, encourages and helps people beyond just work issues
7.2.6. sells instead of tells
7.2.7. listens intently and observes closely
7.2.8. thinks long-term and demonstrates persistence
7.2.9. holds himself and others accountable for their commitments
8. Ideal team player desirable attributes
8.1. Humble
8.1.1. Defined
8.1.1.1. I compliment or praise them without hesitation.
8.1.1.2. I easily admit to my mistakes.
8.1.1.3. I am willing to take on lower-level work for the good of the team.
8.1.1.4. I gladly share credit for team accomplishments.
8.1.1.5. I readily acknowledge my weaknesses.
8.1.1.6. I offer and accept apologies graciously.
8.2. Hungry
8.2.1. Defined
8.2.1.1. I do more than what is required in my own job.
8.2.1.2. I have passion for the “mission” of the team.
8.2.1.3. I feel a sense of personal responsibility for the overall success of the team.
8.2.1.4. I am willing to contribute to and think about work outside of office hours.
8.2.1.5. I am willing to take on tedious or challenging tasks whenever necessary.
8.2.1.6. I look for opportunities to contribute outside of my area of responsibility.
8.3. People smarts
8.3.1. Defined
8.3.1.1. I generally understand what others are feeling during meetings and conversations.
8.3.1.2. I show empathy to others on the team.
8.3.1.3. I demonstrate an interest in the lives of my teammates.
8.3.1.4. I am an attentive listener.
8.3.1.5. I am aware of how my words and actions impact others on the team.
8.3.1.6. I adjust my behavior and style to fit the nature of a conversation or relationship.
9. Agile Explained In 5 Minutes
10. Metrics
10.1. take time to understand what you want to improve and how you will measure it
10.1.1. but beware of Goodhart's law
10.1.1.1. "When a measure becomes a target, it ceases to be a good measure"
10.2. lead and lag measures
11. Product Ownership
12. Time Management
12.1. Run TEAM YOU like you would guide your team
12.1.1. Direction
12.1.1.1. Are you clear on the next most important thing to work on?
12.1.1.2. Are you co-creating solutions rather than taking orders or imposing your solution?
12.1.2. Focus
12.1.2.1. Are you ACTUALLY working on the most important thing?
12.1.2.2. Are you doing too many things to be effective?
12.1.3. Execution
12.1.3.1. Are you delivering to your commitments/outcomes?
12.1.3.2. Are you getting better through experimentation and learning?
13. Cynefin
13.1. Different problems warrant different decision making approaches
13.1.1. Sweet spot of Agile is complex, Lean is complicated
13.1.1.1. Agile makes progress with incomplete information
13.2. Different problems warrant different decision making approaches, Cynefin helps you pair the right approach to the corresponding situation
13.2.1. Choosing a waterfall approach means you are in a safe complicated domain
13.2.2. Often problems have the appearance of complicated when they are really in complex domain (so beware)
13.2.2.1. Analysis paralysis is a tell-tale sign
13.2.2.2. Remember "People will tell you what they want when you have given them what they asked for"
13.3. Goal Move around to obvious
14. Improvement Kata
15. Work breakdown
16. Poor practices and how to fix them
16.1. https://medium.com/@stefanw/sprint-retrospective-anti-patterns-a2af52d75ac5
16.1.1. Stefan Wolpers has a whole bunch of other articles on anti-patterns for different Agile practices/ceremonies
16.2. see 'Bad Smells' slides from these JIT packs
16.2.1. p19 PO JIT
16.2.1.1. http://info.int.corp.sun/sbs/Agile/Documents/TNG/Product%20Owner%20JIT.pptx
16.2.2. p12 Showcase JIT
16.2.2.1. http://info.int.corp.sun/sbs/Agile/Documents/Showcase%20JIT.pptx
16.2.3. p25 IM JIT
16.2.3.1. http://info.int.corp.sun/sbs/Agile/Documents/Iteration%20Management%20JIT.pptx
16.2.4. p17 IPM JIT
16.2.4.1. http://info.int.corp.sun/sbs/Agile/Documents/IPM%20JIT.pptx