the_rollout_a_novel_about_leadership_and_building_a_lean-agile_enterprise_with_safe_by_alex_yakyma
Differences
This shows you the differences between two versions of the page.
Next revision | Previous revisionLast revisionBoth sides next revision | ||
the_rollout_a_novel_about_leadership_and_building_a_lean-agile_enterprise_with_safe_by_alex_yakyma [2017/02/09 11:25] – created hpsamios | the_rollout_a_novel_about_leadership_and_building_a_lean-agile_enterprise_with_safe_by_alex_yakyma [2020/06/02 14:21] – external edit 127.0.0.1 | ||
---|---|---|---|
Line 13: | Line 13: | ||
What I liked in particular about this book is the way it brings some SAFe concepts down to earth. No longer are we talking about an "Agile Release Train" but rather we are understanding that the reason an ART works is because there is they "plan together, execute synchronously, | What I liked in particular about this book is the way it brings some SAFe concepts down to earth. No longer are we talking about an "Agile Release Train" but rather we are understanding that the reason an ART works is because there is they "plan together, execute synchronously, | ||
- | I also liked the explanation of themes, epics, and capabilities. It sometimes seems like these concepts have been blown up to be intentionally confusing. But the explanation in this book (themes as filters for epics, epics being a longer term investment necessitating a business case, if your value stream is too big to line up with an ART, split it by capabilities) helps keep the conversation grounded. | + | I also liked the explanation of themes, epics, and capabilities. It sometimes seems like these concepts have been blown up to be intentionally confusing. But the explanation in this book (themes as filters for epics, epics being a longer term investment necessitating a business case to allow you to make (appropriate) centralized decisions in a largely de-centralized environment, if your value stream is too big to line up with an ART, split it by capabilities) helps keep the conversation grounded. |
- | Recommended for any business leader who has done " | + | Recommended for any business leader who has done " |
+ | Some interesting observations: | ||
+ | |||
+ | * On the fractal nature of an agile implementation and why we should do PI planning face-to-face: | ||
+ | * On why agile at team level is not enough: "The new process deployed on top of a traditional management mindset is like an old ship: patched everywhere you can imagine. She seems watertight in calm seas, but as soon as the slightest turn in the weather hits the sails, she will wreck on the reef of organizational impediments. And when all patches suddenly come off—one after another—nothing can save her. She goes down." | ||
+ | * On why we do PI Planning Event: "These two days provide critical alignment in terms of what and how the teams should be building in the PI. You’re right: PI planning is an investment, but so is the PI itself. We have significant problems building new functionality, | ||
+ | * On observable milestones " | ||
+ | * On the role of the change agent: "A successful change agent must ensure that there’s no unproductive tension between themselves and the stakeholders. Any antagonism, even latent, may inhibit the transformation and must be promptly resolved. It’s up to you to make the first step." | ||
+ | * On why the agile approach works better than the traditional approach: "The traditional mindset progressively builds blindspots and inhibits learning. Surrounded by all kinds of numbers, we have no ability to really tell where we are in the process. Being separated into silos, we fail to learn and introspect as a whole. We need to put all the pieces of the puzzle together." | ||
+ | * On the Kanban board for a transformation team: "We built the board based on a simple observation: | ||
+ | * Why normalize points: "Let me ask you this: you all use story points to express your team’s velocity, but how about the velocity of the entire program?" | ||
+ | * Why not use some kind of "uber points" | ||
+ | * On the role of an RTE: "Being selective in terms of where to apply one’s major effort is vital to an RTE." | ||
+ | * On why teams over-commit all the time (and need management help): "The teams themselves can have flawed instincts and regularly take on more work than they can actually accomplish." | ||
+ | * On the goal of PI Planning: "The goal of the PI planning is not to go into depth on each story, defining acceptance criteria, etc. The goal is to understand the bigger picture view, and for that, focusing on dependencies, | ||
+ | * On why an ART works: "Plan together. Execute synchronously. Review the results together" | ||
+ | * On why architecture is not an isolated capability delivered from on-high: "“If you want people to inherently and naturally follow certain rules, simply stating those rules or announcing them won’t get you there. People won’t be able to respond the way you need them to because that information will remain superficial in their mind. What you want instead is to have them deeply care about those constraints, | ||
+ | * On types of value streams: "There are two types of value streams: development and operational. Development value streams deliver software to the customer, while operational value streams offer a certain type of service. Every operational value stream has a development value stream associated with it: the teams that develop the software systems in support of the operational workflow." | ||
+ | * On use of capabilities: | ||
+ | * On the mindset change: "“If you dig deep enough,” I said, repeating almost word-for-word what Rachel had told me a year ago as she handed me a cup of ‘Sleepytime’, | ||
====== Want to Know More ====== | ====== Want to Know More ====== | ||
/home/hpsamios/hanssamios.com/dokuwiki/data/pages/the_rollout_a_novel_about_leadership_and_building_a_lean-agile_enterprise_with_safe_by_alex_yakyma.txt · Last modified: 2020/06/03 14:40 by hans