Topic Title:  How to Keep Kanban from Feeling Waterfall?
Initiator:  Beth Galambos

Participants:  Shannon Hausey, Abbie Field, Marilyn Brislin, Jakob Andersen, Wendy Culpepper, Karam Labban, Rochit Gupta, Tracey Long, Laisa de Almeida, Chip Caddell, Alejandra Rodriguez, Jamie Leatherman, Daniel Bridges, Lani McDaniel, Jamie Fulmino, Monica Hernandez

Discussion Highlights:
Issue – Just moved from Scrum to Kanban for back end process team.  Feels like it is more Waterfall than Kanban.  Collaboration is lacking between Devs and QA.  QA is not very involved in development discussions, and are hands off until tickets / stories are handed off for testing.

Currently doing weekly refinement sessions, bi-weekly demos, bi-weekly planning.  Looking for other ideas, guidance.

Ideas for Action/Next Steps:

• QA Skillset – focus on technical skills needed, and ensure all have systems process knowledge.
• Have Devs do automation testing before passing off to QA to catch issues early.
• QAs can lead story writing efforts / take ownership of work from start to finish (this applies to all team members – Devs, QAs, SAs, etc.).  This promotes leadership and accountability.
• Provide better training (agile, cross-team training, process, technical) for all team members
• Add review column to board prior to pulling it into “To-Do” to ensure it is ready to pull. This will help with stop-starts. Stories should not be pulled in unless they are truly ready.
• Add comments (JIRA or other platform) with questions or to identify blockers that need to be addressed prior to pulling work in.
• More detailed visibility on cycle time for readiness vs. just sitting in “To-Do”.
• Run a design sprint one sprint prior to development starting.  This does not require the entire team – you can get volunteers or have set “Readiness” team (tech lead/arch, lead QA, product owner, SA…) 
• Test case design (QA and Dev collaboration)
• Technical grooming
• Use automation as much as possible
• Establish strong processes and standards
• What is definition of done?
• What is definition of ready?
• Ladder of Leadership – use to identify red work (doing) vs. blue work (thinking) – coach the team and empower them to take ownership and lead efforts.  Change thinking to “what do I intend to do” vs. “what will I be told / assigned to do”.
• Use WIP limits! Don’t allow additional work to come into sprint / board without assessing the committed work already in the queue, and making adjustments to retain WIP limits. This is key to efficiency.
• Don’t allow one person to work on two (or more) tickets or stories at once. Stop starting and start finishing.
• Auto-rotate Scrum Master (shadowing) for new hires or struggling teams.  For newbies:
• Sprint 1 (first two weeks) – Learning sprint.
• Sprint 2 – Active working sprint.
• Sprint 3 – Shadowing sprint.  This is where the new hire (or assigned team member) will shadow the Scrum Master, owning facilitation in meetings, removing impediments and blockers, and serving as Product Owner in the demo for that sprint.  This process breaks psychological barriers and helps overcome fears.  Builds knowledge and promotes participation and ownership.
• Use an on call schedule with specific owners (weekly or by sprint) to limit production support disruptions to overall team.  On call person will own vetting an issue and taking it to product owner for prioritization.
• Alignment – host a “dress rehearsal” meeting with Product Owner, Scrum Master and Technical Architect/Lead to align on goals for refinement and planning prior to meeting with the entire team.