About Our Kanban Transformation. Our first steps

Sources
1. Mike Burrows: Kanban from the Inside
2. Mike Burrows: Statik, Kanban's hidden gem
3. David J Anderson , Andy Carmichael: Essential Kanban Condensed
4. Anders Beskow, Kanban six core practices
5. Kanban in Action
Our context
1. Now
  1. There is a project developed by the Scrum-team
  2. The project has passed to the maintatance stage
    1. Users are actively working
    2. Improvements are constantly needed
2. Problems
  1. Slow response to change
  2. Long time to market
  3. The process is not clear for all participants
  4. The Sprint takes more tasks than the Team can perform
  5. Priorities are unclear
  6. New tasks can occur in Sprint time
  7. Work is comming from different points
3. We want
  1. Rapid response to changes
    1. More frequent releases
      1. To meet the needs of customers
    2. Flexible up-to-date backlog that meets the requirements of customers
  2. Continuous improvement of the process and product
    1. Reducing all types of wastes and costs
  3. Focus on customers
    1. High-quality product on time
  4. Increase the productivity and effectiveness of the team
    1. The possibility of maximum impact of each of the team members
    2. Balanced Team work
    3. Focusing on the CI / CD
Agree the transformation with all stakeholders
Kanban. Principles & Practices
1. Principles
  1. Start With What You Do Now
  2. Agree to Pursue Incremental, Evolutionary Change
  3. Respect the Current Process, Roles & Responsibilities
  4. Encourage Acts of Leadership at All Levels
2. Practices
  1. 1. Visualize
  2. 2. Limit Work in progress
  3. 3. Manage Flow
  4. 4. Make policies explicit
  5. 5. Implement feedback loops
  6. 6. Improve collaboratively, evolve experimentally
  7. Basis
WE USE
1. SDCA/PDCA
2. STATIK
  1. Systems Thinking Approach To Implementing Kanban
  2. 1. Understand sources of dissatisfaction
  3. 2. Analyze demand and capability
  4. 3. Model the knowledge discovery process
  5. 4. Discover classes of service
  6. 5. Design kanban systems
  7. 6. Roll out
The Board
1. We Use
  1. TFS board
2. Should reflect our ACTUAL workflow
3. Map our flow
  1. New
  2. Ready to Work
    1. In progress
    2. Done
  3. in Dev
    1. In progress
    2. Done
  4. Testing
    1. In progress
    2. Done
  5. Staging
    1. In progress
    2. Done
  6. Deploy
  7. Create Swimlanes
    1. Critical
      1. to track high-priority
    2. Normal
  8. We Identify all stages: work entering...work leaving
4. Determine Work Items
  1. USs
    1. As a [role], I want [feature], so that [benefit]
    2. Tasks
      1. Analytics
      2. Development
      3. BackEnd
      4. FrontEnd
      5. Testing
      6. Test design
      7. Test Execution
      8. Other tasks
      9. Tasks that require research, Data preparation, etc.
  2. Bugs
  3. What we can see on the card
    1. Card helps
      1. Facilitate decision making
      2. Help to optimize output
      3. Show the type and class of work
    2. ID
    3. Description
    4. Avatar
    5. Status
    6. DeadLine
      1. Clearly stand out from other information
      2. Can be used to provide a timebox for the work item
    7. Is Blocked?
      1. Why?
      2. Clearly indicate that the item needs your attention
    8. Type of work
    9. Size
      1. How to evaluate
      2. Story Points
      3. Size
      4. S
      5. M
      6. L
      7. Hours for each stage
      8. Ideal men-days
Set WIP for each stage
1. To work with fewer items at the same time
2. Respect WIP limits
3. A lower WIP is better....
  1. Will be additional discussed
  2. Try to find right balance
4. We limit WIP based on people
Determine Classes of service
1. Urgent
  1. Prioritized over other work
    1. Own Swimlane
2. Fixed Delivery Date
  1. To be delivered on or before a certain date
3. Regular
  1. Normal items, USE FIFO-style
4. Defects
5. Architectural
  1. without business value, technical task
Make explicit policies for each stage
1. Ready to work
  1. A clear description for everyone
  2. The necessary analysis is carried out
  3. Acceptance criteria are formulated
  4. A demo scenario is defined for the product feature (if necessary)
  5. Test Strategy
  6. Reviewed by P.O.
  7. Reviewed by Team
2. In dev
  1. All development tasks are closed
    1. Code review
    2. Unit tests
  2. The test design task is closed
  3. The acceptance scenarios are written
  4. The acceptance test cases were successfully passed
3. Testing
  1. The planned works is done
  2. The percentage of successfully passed test cases above 90%
  3. Unsuccessfully passed test cases are not critical
  4. Bugs is fixed and retest
  5. All test documentations is done
    1. Results of Session of Exploratory testing
4. Staging
  1. The test task is closed
  2. Regression testing is performed
    1. Bugs is fixed and retest
QUESTIONS & Problems
1. TEAM
  1. Regress takes to much time...
    1. Cut it!
    2. Develop new test strategy
  2. Are all stages for all work items required?
    1. No
    2. It depends...
  3. What to do with big US (3 months)?
    1. One US according WIP
    2. Swimlane for such work with own WIP
    3. ....
  4. Meetings?
    1. Grooming
    2. Retro
    3. StandUp
      1. every day
    4. when it is required
  5. When I tested US I found a defect. What should I do with bug and US?
  6. 1. US remains in Test 2. Create a bug-report 3.It is discussed with the Team and PO 4. PO prioritizes all new tasks, USs, bugs appearing on the board 5. Create a ticket to the developer with a description of the bugs
2. Business
  1. Not clear delivery time