Comic Agilé Newsletter #2
Dear Comic Agilé fan.
It's time for the second installment of our newsletter with five classic strips and a brand-new one.
Enjoy!
Comic Agilé no. 153 - Apples and Pears
A Scrum Team’s Sprint Velocity indicates how much work (i.e., value) it can deliver in a Sprint, typically represented by the number of Story Points or User Stories that are "Done" in the Sprint. The metric is only for the Scrum Team and never for anyone outside it. If a Manager, Release Train Engineer or the like wants to use your team’s Sprint Velocity for anything, fight against it with all that you have, as it’ll only lead to undesired purposes, such as using it for reporting purposes (don't buy this reason, as it'll definitely turn into some sort of feedback loop back to the team).
Also, as the understanding of a Story Point varies from one Scrum Team to another, and this type of dynamics isn't very fruitful, the Sprint Velocity can and should never be used to compare teams. Rather, it’s an indicator that helps the Scrum Master delve into potential improvements areas (e.g., if the Sprint Velocity fluctuates a lot), and the Product Owner to use to forecast when the Scrum Team is likely to deliver Product Backlog Items or Product Increments (if it follows its current average Sprint Velocity).
But, all in all, just leave the Sprint Velocity with the team, will ya?
Comic Agilé no. 91 - Bottleneck
It’s a great idea to disperse Platform Team members into the other teams, so dependencies are removed, and those teams become more end-to-end.
However, if it’s not followed up with the needed knowledge sharing sessions (e.g., collective refinement or Pair or Mob/Ensemble Programming), the person-specific knowledge will just become an internal dependency.
Comic Agilé no. 205 - Grass vs. Glass
Like any other big change or initiative, if going agile is just a grassroot movement in your organization without the buy-in, support and sponsorship from Upper Management, it’ll eventually hit the glass ceiling and stop growing—i.e., when changes to ways of working need to be made outside of your own silo. Even though agile might’ve started out as a grassroot movement for software developers back, it’s for the whole organization today.
Therefore, an agile transformation should not be driven bottom-up or top-down, or have any direction, at all, really; in any case, without the passion and drive of the teams (the grassroots), it’ll never happen, and without Upper Management (the glass ceiling) in on it , it’ll never make a real difference. And when you do get the needed support from above, remember to take an agile approach to going agile, and slice your agile pilot so it can deliver end-to-end value making the lessons learned relevant for the rest of your organization.
Recommended by LinkedIn
Comic Agilé no. 197 - Tech Debt and the PO
As a Scrum Team, we’ll quite often find ourselves in a predicament where there’s a deadline to be met as well as Technical Debt to be removed. Here, you, as a Product Owner, are rightfully looked at as the person who orders the Product Backlog and, thus, the high-level priority of upcoming work for the team. Enablers containing infrastructure, refactoring, code optimization or re-architectural work are also part of the Product Backlog.
Therefore, instead of comparing apples (Features) to pears (Enablers), build-in this type of technical work into your Product Backlog Items (e.g., by identifying the work needed to meet the Non-Functional Requirements or live up to your (evolvable) Goal Architecture)). If that’s not feasible or acceptable, having dedicated Enablers is an option, but then, remember to explicitly allocate a rough percentage of the Scrum Team’s capacity to Enablers at Sprint Planning (and show how it aligns with your technical roadmap/Architectural Runway), so you don’t end up having to choose between Features and Enablers and, thus, between delivering business value and ensuring quality.
Comic Agilé no. 135 - Agile Coaching
Let’s admit it; many of us call ourselves Agile Coaches, but we don’t have the faintest idea about how to actually coach anyone. Rather, we’re glorified Scrum experts and agile sparring partners, which means that we’re really good at fixing agile issues, solving problems, and suggesting and implementing new ways of doing stuff so it’s aligned with our agile principles.
However, if we’re to really improve our organizations, we should invest much more of our time in becoming proficient in Professional Coaching, Change Management and other related disciplines than in being able to cite the Scrum Guide flawlessly.
Lyssa Adkins and Michael Spayd’s Agile Coaching Competency Framework or Barry Overeem’s Six Stances of the Scrum Master are great places to start to identify which disciplines Scrum Master should have a high level of proficiency in.
Premiere: Comic Agilé no. 286 - The Scope Creep
Don't let the scope creep uncontrollingly; inspect and adapt it with your stakeholders. Remember that, if you work with the Iron Triangle of Project Management, we want to keep the budget and timeline stable, but adjust the scope (and not the quality). Letting the scope creep (i.e., increasing the scope) should always be accompanied by an increase in the budget or an extension of the timeline).
What's coming up?
For some reason, linking doesn't work, so we've pasted the URLs below...
Thanks you for staying with us until the end! See you next month - and constantly We hope you have a nice weekend and keep using humor til articulate what really happens when agile meets reality :-)
Best regards,
Mikkel and Luxshan
Sr. Tech. PM | Sr. Scrum Master | AI Specialist | Software Designer
8moLoved it!
Business Agility Consultant and Agile Transformation Coach at Icon Agility Services
8moInsightful! This is like old school Dilbert for agile.
Helping Leaders Master Agility and Outperform the Competition
8moThis was the first newsletter that I actually enjoy reading! Thanks !
Digital Implementation | Application Portfolio Management | Programme / Project Management | Change Management | Software Development Management | Deployment Management | Vendor Management
8moVery well explained !! Thank you 😊