1. Random thoughts
1.1. Every team has lost a member besides mine. There is value in a ScrumMaster
1.2. Eric wants to make a cookie cutter format and force teams to do it. I should work to find why, what things does he need to know and can they be done with scrum.
1.3. Unification is project management. Getting metrics to micro manage engineers to make sure “they are even working” is project management.
1.3.1. Scrum is empowering teams to do what they need to do to succeed.
1.3.2. How can I be a successful ScrumMaster when my boss and product want to do project management.
1.3.3. You strip me of my power. Don’t communicate with me, expect me to “just go with it” and do things that are counterproductive. Now you want metrics that could be used to show we are doing poorly.
1.3.3.1. Teams are doing poorly because teams have no autonomy. They are order takers. Forced to work with people and do what they are told.
1.3.3.2. Forced deadlines
1.3.3.3. No communication with actual customers
1.3.3.4. ELT constantly changing their minds on what they want and giving customers deadlines.
1.3.3.5. These are the things killing productivity and culture. You’d know this if you ever read sprint reports.
1.3.3.5.1. I’ll give you the reports to show the productivity of engineers. But I’m going to make it scream the reasons they are failing. And it’s not the engineers. It’s ELT and middle management meddling where they shouldn’t.
1.3.3.6. Maybe I’m not what you want here. You want a yes man who just does whatever, regardless of the impact. That’s not my style.
1.3.3.7. Why do you assume every other idea is better?
1.3.3.7.1. Ethan’s framework is good. But i have far more agile knowledge than he does.
1.3.3.7.2. You’ve given Bron free reign to do what he wants in the name of lean. You haven’t given me free reign to do anything.
1.4. Cynefin
1.4.1. Simple
1.4.1.1. Sense
1.4.1.2. Categorize
1.4.1.3. Respond
1.4.2. Complicated
1.4.2.1. Sense
1.4.2.2. Analyze
1.4.2.3. Respond
1.4.3. Complex
1.4.3.1. Probe
1.4.3.2. Sense
1.4.3.3. Respond
1.4.4. Chaotic
1.4.4.1. Act
1.4.4.2. Sense
1.5. Committing to sprint
1.5.1. Commitment support mutual trust between product owner and development team as well as within the development team
2. Scrum is
2.1. Like chess, the scrum guide tells you how pieces can move. But as for how you play the game of Chess, there are many variations.
2.2. Delivering smaller more frequent releases
2.3. Relentlessly exposing organizational dysfunction and waste
2.4. based on values of honesty openness courage respect focused trust empowerment and collaboration
2.4.1. Honesty
2.4.2. Openness
2.4.3. Courage
2.4.4. Respect
2.4.5. Focused
2.4.6. Trust
2.4.7. Empowerment
2.4.8. Collaboration
3. Cross functional team
3.1. “Such as design, building, and testing working features.”
4. Where LiveView is off
4.1. Sprint reviews need to be at team level with stakeholder and customer
4.2. Product needs to work with actual customers
4.2.1. But which customers?
5. Definition of Done
5.1. At the end of the sprint the team should have a potentially releasable product (or increment of the product)
5.2. New Topic
6. Scrum benefits
6.1. Delighted customers
6.2. Improved return on investment
6.3. Reduced cost
6.4. Fast results
6.5. Confidence to succeed in a complex world
6.6. More joy
7. Scrum Practices
7.1. Roles
7.1.1. Product Owner
7.1.1.1. product owner is empowered Central point of product leader ship he is the single authority responsible for deciding which features and functionality to build and what order in which to build them
7.1.2. ScrumMaster
7.1.3. Development Team
7.2. Activities
7.2.1. Sprint
7.2.1.1. Commitment
7.2.1.1.1. by committing to sprints it helps us plan dependencies and allows other teams to know what is going to be accomplished
7.2.2. Sprint Planning
7.2.3. Daily Scrum
7.2.4. Sprint Execution
7.2.5. Sprint Review
7.2.6. Sprint Retrospective
7.2.7. Product Backlog Refinement
7.3. Artifacts
7.3.1. Product Backlog
7.3.2. Sprint Backlog
7.3.3. Potentially Shippable Product Increment
7.3.4. Story
7.3.4.1. Small in size
7.3.4.1.1. We make story small to limit the amount of dependencies so if changes are needed to be made they could be made quickly without affecting other stories
7.4. Rules
7.4.1. Described throughout the book
7.4.2. Small Planning
7.4.2.1. When using a Scrum we don't invest a great deal of time and money into flushing out details of requirements upfront because we expect the specifications to change as time passes and we learn more about what we are building