i Lean Agile

Owned by jim mason
Last updated: Sept 30, 2024 by jimm1
8 min read

Key Points

coaching model:  every single coaching conversation. there are five contexts of Co-Active Coaching - listening, intuition, curiosity, deepen/forward, self-management.


References

Reference_description_with_linked_URLs__________________________Notes_________________________________________________________________
https://agilemanifesto.org/agile manifesto 
agile-safe-guru99.com-SAFe Methodology Tutorial What is Scaled Agile Framework.pdfSAFe Agile Framework overview
SAFe_ Here’s Where the Critics get it Wrong - Elabor8 Insights - Medium.pdfSAFe framework concepts - what's misunderstood
joelonsoftware.com-The Joel Test 12 Steps to Better Code.pdfJoel on Software - 12 steps

DZONE Scrum ceremonies review

Scrum Ceremonies The Unusual But Surprisingly Robust Guide gdrv

Scrum Ceremonies


https://www.knowledgehut.com/blog/agile/what-gaps-i-filled-
after-csm-certification-for-my-scrum-project		Gaps I Filled After CSM Certification For my Scrum Project


Key Concepts


Scrum Ceremonies - DZONE

DZONE Scrum ceremonies review

Scrum Ceremonies The Unusual But Surprisingly Robust Guide gdrv

Scrum meeting - standup

  1. The attendees of the daily scrum include the scrum team, the scrum master, and the product owner.
  2. What was done. What's next. What are the blockers
  3. Daily Scrums are held for team members to share what blocks they’re facing so other members of the team can provide help.
  4. Some teams have found great success in doing their daily scrums over Slack via chat.
  5. make every team member share if they are facing any obstacles keeping them from making progress. 
  6. Then, only developers who want to elaborate on their problems or provide solutions can stay; others can hop off the meeting and get to work.
  7. Focus on results not on sprint working hours, and you’ll have more success with your projects and your team in general.

Sprint Retrospective 

  1.  improve our working flows and thus deliver awesome results at the end of every sprint.
  2. retrospectives are held right after the sprint review at the end of the sprint
  3. great for clearing up bottled up feelings and emotions. Don’t let your team burnout; instead do a retro, and clear things out.
  4. share notes on what was good, what can be improved
  5. Retros should feel like a safe place where everybody can share their concerns. 
  6. Treat each other with respect and focus on fixing problems instead of blaming others.
  7. Address all the negative shit but keep the positive attitude on point - “everything is figureoutable.“
  8. Don’t let only one or two team members dictate the pace and direction of the meeting. Every single member of the team should be active during the retro; that way, it feels more energetic; it bonds the team.
  9. You can suggest that team members jot down their thoughts on notes before the scrum event if that would make it easier to participate in the conversation

Retro Prep

  1. start with a round of admiration. Basically, tell your colleagues what you most admire about them. 
  2. Before the retro, you can spend some time going through standup notes, email threads, chat logs, tickets to gather all kinds of quotes.
  3. Write them down along with the owner of each quote, and make the team guess who said them. Quite often, the team will guess right and even recall the situation
  4. One of the most thoughtful questions you can ask is, “Why are we doing this?” 

Collect team inputs 

  1. Draw 3 columns and place the words mad, sad, and glad on top of each one. 
  2. Make the team write down events, on sticky notes, during which they felt mad, sad, or glad. And then you can ask the following questions:
  • What was difficult about this user story?
  • What was the fun part of it?
  • Did you see any repeating patterns?
  • Do you have any suggestions on how to handle similar situations in the future?
  1. You can try the “speedboat” method. Draw a speedboat. Attach a strong motor to it and a heavy anchor.

Get team insights

Asking questions can be quite helpful as well:

  • What were the roadblocks? What were the challenges in this Sprint?  What's the impact if they didn't exist?
  • What went well this sprint?
  • What did we learn?
  • What should we do differently next time?
  • What still confuses us?

Retro Decisions

  • Each team member writes down two action items for the next iteration. 
  • The team reviews all suggestions and narrows to 1 or 2 to implement in the next sprint

Scrum Method

Delivery done in Sprints

Prereqs to Sprints

  1. Project resources
  2. Project Charter
  3. Project funding
  4. Project support
  5. Project Structure
  6. Project Documentation
  7. Project Governance


Sprint Roles

  • Product Owner
  • Scrum Master
  • Team
  • Champions
  • Sponsors
  • Consumers


Agile "GAPS" - customize

  • DOQ - Definition of Quality 
  • DOR - Definition of Ready
  • DOD - Definition of Done

Sprint Process: Plan, Deliver, Review, Assess


  1. Sprint Planning
  2. Execution
  3. The Sprint Review
  4. Sprint Retrospective

Sprint Planning

Sprint Plan - What and How decisions

  • print planning is about coming up with the complete sprint plan for your next iteration.
  • According to the Scrum guide, There are 2 main questions that the sprint planning ceremony:
    • What can be delivered in the Increment resulting from the upcoming Sprint?
    • How will the work need to deliver the Increment be achieved?
  • selecting the right PBIs (product backlog items) and then ordering them by priority in the sprint backlog.
  • break their PBIs into smaller tasks that would take them no more than 2 days to complete each. 
  • create Epics and Stories to define details for solution delivery based on use cases
  • add dependency links as needed

Sprint Goal 

  • a mature scrum team is supposed to deliver between 85 and 115% of the planned work every sprint. 
  • allot 10% of its capacity to build out the product/sprint backlog before the start of the sprint
  • items from previous sprints aren’t considered to be the main work of the new sprint. No points should be credited to completing work from previous sprints.

Backlog Refinement as needed 

  • detail, improve, estimate, and prioritize the PBIs in the sprint backlog as changes occur. 
  • PO and at least one member of the team are the required attendees
  •  set a time limit, of 10 minutes for example, per each backlog item. 
  • Planning poker - assessing the difficulty of each task, one developer might score 1 while another 5 on a scale of 1 to 5 (where 1 is easy and 5 extremely difficult). 
  • Discuss reasons for scores - come to the mode



Sprint Delivery - Execution, Standups


  1. Standups normally daily
  2. Identify what's done, what's in next, what are the blockers
  3. Create update reprioritize Jira tickets as needed
  4. Work as a team to resolve issues, blockers, prioritizations



Sprint Review

  • What’s been done during the sprint?
  • held to encourage collaboration and make the team operate as a whole so it can grow. 
  • allows developers to showcase their work to stakeholders; thus receive feedback and improve the way they approach work in future sprints. 
  • the dev team reviews what went well, wrong, and how team members handled difficulties throughout the sprint.
  • As opposed to the scrum retrospective where “the how” is discussed.
  •  demo work is presented to stakeholders by the PO.

  • whether the sprint release was successful or not:

    • What did the customers like about it?
    • What did they dislike?
    • What’s hard to understand from a customer POV?
    • What changes do they want?
    • What new features do they want to be added?
    • Has the market changed? Do they have different problems?
  • talk about how the market reacted to the new release, and then offer suggestions to improve the product.
  • the product backlog can be frequently adjusted, especially during the sprint planning session for the next sprint.


Sprint Retrospective


  1. How well was the sprint done?
  2. How can Sprint planning, estimation and prioritization improve?
  3. How can Sprint execution improve?
  4. How can Sprint quality improve?
  5. How can Sprint productivity, velocity improve?
  6. How can team skills improve?
  7. What changes are needed to plans?
  8. What changes are needed to the team?


Coaching team members

https://www.scrum.org/resources/blog/how-scrum-master-can-be-co-active-scrum-coach

understand the roles and the individuals

coaching model:  every single coaching conversation. there are five contexts of Co-Active Coaching - listening, intuition, curiosity, deepen/forward, self-management.

Scrum Values - courage, focus, commitment, respect and openness are the lifeblood that breathe life into Scrum

Coaching principles

fulfillment helps coachees make choices that are aligned with their life purpose and core values.

balance can help the coach get the coachee get unstuck from beliefs that are no longer serving them.

process helps coachees experience all the ups and downs of their lives and be with emotions that they have trouble being with


SAFe framework - use common sense and fit to purpose to implement

SAFe_ Here’s Where the Critics get it Wrong - Elabor8 Insights - Medium.pdf






ART - Agile Release Train

The Agile Release Train (ART) is a framework for software development that involves multiple teams working together to deliver value. The ART process is based on the idea of a train, with each agile team representing a train car. The teams work together in timeboxed iterations, called Program Increments (PIs), to plan, develop, and deliver features. 
Here are some key aspects of the ART process: 
  • Collaboration
    The ART structure encourages collaboration between teams that might otherwise be siloed. 
  • Predictability
    The fixed cadence of the PI allows for a reliable and predictable delivery of software. 
  • Flexibility
    The decoupling of release and deployment from the development cadence gives the organization flexibility over when and how to release to customers. 
  • Alignment
    The ART process involves aligning ART priorities with the overall portfolio strategy. 
  • Planning
    The PI planning process involves teams creating and agreeing on PI Objectives, and Business Owners sharing business and customer context. 
  • Backlog
    The ART backlog includes the features that need to be delivered in a PI, which are then broken down into user stories for the sprint level backlog


LeSS Agile Framework



https://www.atlassian.com/agile/agile-at-scale/less

Agile teams are made up of product owners, scrum masters, software developers, and others who work collaboratively to address complex problems through the creative delivery of valuable products. Scrum is one of the more popular agile methodologies that teams use to develop, deliver, and sustain complex products. Yet only recently have we effectively addressed scaling scrum in the enterprise with scaled agile process frameworks like Large-Scale Scrum (LeSS).

LeSS is a framework for scaling scrum to multiple teams who work together on a single product. It starts with a foundation of one scrum team, as defined by Ken Schwaber and Jeff Sutherland in the Scrum Guide, and applies to multiple teams who work together on one product. 

This is further refined in the book Large-Scale Scrum: More with LeSS, by Craig Larman and Bas Vodde. The authors condensed their years of experience to define LeSS as a framework to deliver value while reducing complexity and waste.

The LeSS framework seeks to apply the principles and ideals of scrum in a large-scale enterprise context as simply as possible through defined rules and guides. Its simplicity has earned LeSS the label of being a “barely sufficient” framework, but that’s not meant to cast it in a negative light.

The LeSS framework structure

LeSS was forged through more than 600 experiments that involved expanding the practice of scrum, which at the time was thought to only support small, colocated groups. The LeSS experiments, guides, frameworks, and principles were created to support the needs of larger numbers of teams. In addition, LeSS rules were later released to better define and provide guidance on how to implement and execute LeSS and offer guides for adoption.

Principles, frameworks, guides, and experiments

Principles

LeSS defines 10 principles for applying the value, elements, and overall purpose of scrum across an enterprise. They help create more responsible teams with greater customer focus and collaboration. Teams focus on learning, transparency, and delivering customer-centric values that product organizations need to remain competitive and responsive. Here’s the complete list:  

  • Large-Scale Scrum is scrum
  • Empirical process control
  • Transparency
  • More with less
  • Whole product focus
  • Customer-centric
  • Continuous improvement towards perfection
  • Systems thinking
  • Lean thinking
  • Queuing theory

Frameworks

LeSS offers two configurations: Basic LeSS for two to eight teams (10-50 people) and LeSS Huge for more than eight teams (50-6000+ people). 

LeSS Huge starts with the Basic LeSS foundation in place and adds a key role – the area product owner (APO) – and additional artifacts and meeting changes. It’s recommended to start with Basic LeSS in your organization – to experiment, experience, and get feedback – before jumping straight into LeSS Huge. There are two suggested approaches to LeSS Huge adoption:

  1. One requirement area at a time, focused on a requirement area within the larger product
  2. Gradually expanding the scope of work of the team, definition of done, and the product definition

This allows an organization to build team experience with LeSS, expand throughout a product area, and gain management support, before scaling LeSS throughout the whole organization.


Less Differences

LeSS shares five main components akin to other frameworks for scaling agile: inspiration from the Agile Manifesto and its 12 principles, cadence through sprints/iterations, synchronization across the organization, its roots in scrum, and quality development practices such as DevOps, CI/CD and test-driven development (TDD). But there are other distinguishing characteristics that set it apart from the rest.

Beyond this, in LeSS, sprint planning is broken out into two parts: 1) all teams come together to decide how to best divide the product backlog items and 2) teams plan their sprint, while collaborating and communicating with other teams to deliver the product backlog items.

Aside from these points, other ceremonies such as the daily scrum, sprint review, and overall retrospective, have their own nuances in LeSS.

Less vs Safe frameworks

Contrary to LeSS, SAFe requires additional roles, including the Release Train Engineer (RTE), Solution Train Engineer (STE), and Epic Owners. It also includes processes, artifacts, and organizational changes that some organizations may not be ready to take on; even despite starting on equal footing with agile teams successfully running scrum. LeSS Huge does provide some differences of Basic LeSS, but for the most part is not as complex as other frameworks.


Agile Product Management Journey

Agile-Product-Managers-Can-Build-Better-Products-by-ProductPlan.pdf link

Agile-Product-Managers-Can-Build-Better-Products-by-ProductPlan.pdf file



Potential Value Opportunities



Potential Challenges



Candidate Solutions



Step-by-step guide for Example



sample code block

sample code block



Recommended Next Steps