SlideShare a Scribd company logo
Flow Based Product Development
A Venture of A Product Development Team in December
2019Abstract:
A pictorial case study about this product development team I coached- to move from mandated Scrum process to a
much leaner Scrumban process, teaching the team value of “flow” based product development, in conjunction with
team practices such as process eval “futurospective”, GetKanban gamification, distributed mob programming &
behavior driven dev/testing.
Key takeaways:
1. Transition From Output to Outcome can happen only when the team focuses on “flow” based product
development.
2. Technical practices like mob programming and BDD increase the team collaboration and productivity.
3. Mob programming is probably the leanest of all XP practices, in that it cuts the time it takes to develop shippable
code!
4. Transition from waterfall/big-bang/compliant process culture requires shift to focus on the 4 values of agile
manifesto.
5. Look for opportunities to inject Lean principle of (faster) flow in everything team does! 1
Issues with Scrum
Process
Long scrum duration (3 weeks mandate)
leads to mini-waterfall.
Short scrum duration (<= 2 weeks
sprints) with distributed “siloed tower”
teams creates heavy planning overhead.
Responsiveness to unplanned work
requires breaking the mandated process
or using Kanban in parallel.
Try Scrumban
Process
Implement flow-based process without
artificial boundaries.
Communicate immediately and
efficiently.
Monitor, measure and optimize the flow.
Typical Transformational Challenges- Doing Agile vs. Being
Agile
2
Process Framework Evaluator “futurospective” –
Powerful questions make team decide what will work for it
Powerful Questions Explanation
Planning:
Despite the PO trying to do so, is it impossible to lock down the scope
for your chosen timebox?
Do you have more than 25% scope churn during the chosen timebox?
Scrum: Scrum works best when requirements are stable for the duration of the Sprint so that the team can commit to their delivery.
Kanban: Some scope change can be accommodated. By dropping the fixed timebox, Kanban can allow teams to adapt more easily to quickly changing priorities.
Scrumban: Iteration planning is done at a regular interval, with the goal of planning is to fill the slots available - not fill all of the slots, and certainly not to determine the
number of slots.
Decomposition:
Even after trying your best, is it impossible to break features into
incremental pieces of value to be delivered within the chosen timebox?
Both Scrum and Kanban work best when you break your work down into small incremental pieces. The Scrum Sprint timebox can help new teams recognize deficiencies (work
not completed at the end of the sprint) and adapt (retrospective).
Scrumban: Can you decompose work to lock scope for the timboxed duration?
Estimation:
Is it hard or impossible for team to size the work in the chosen timebox?
Does estimation take more than 3 hours?
Kanban: Kanban removes the overhead of estimation in favor of measuring cycle time for like sized items. Work should be comprised of similarly sized activities for Kanban.
Scrum: Scrum absolutely requires that all work be estimated so that the team can commit to the sprint.
Scrumban: Scrumban does not require estimation.
Responsiveness:
Is your top priority to optimize responsiveness to customer needs?
Must work begin in the current timebox -cannot wait until the next one?
Kanban has a strong focus on cycle time, where Scrum has a stronger focus on Velocity.
Both can be tuned to provide very similar output, but Kanban has the flexibility to lower batch size to reduce cycle time at the potential cost of productivity.
Predictability & Productivity:
Is your top priority predictability and productivity for larger projects?
You can achieve predictability and a high level of productivity using any agile framework.
Scrum provides more guidance on how to handle release planning and progress tracking so is preferable for new teams.
Process Oriented Culture:
Does your team culture demand higher degree of process ceremonies?
Although Scrum has fewer ceremonies and artifacts than many other methodologies, it has more than Kanban and can more easily be integrated into a culture requiring them.
Shared Team Members:
Do you share engineers with other teams?
Does your team lack all the required skills to complete the work?
Scrum: Scrum teams work best when they do not have dependencies on people outside of the team
.
Kanban: With Kanban, others can see when there is work for them to do and pick it up at that time.
Variety in work (complexity & size):
Are your work items of approximately similar size & complexity?
Both Scrum and Kanban work very well with similar sized work items.
However, in Kanban the variability between different sized items makes it difficult to adhere to SLAs.
Source: Steven Sanoff
(PayPal)
3
Tools & Practices for Increased Collaboration!
GetKanban Simulation workshop for gaining
insights by team members producing ideas
about making “flow of work” even more efficient,
while staying with constraints around existing
software process!
4
Setting up a Scrumban Board with existing value stream
Ready In Dev Ready for QA Ready for
Release
Ready for
Deploy
Done
Expedite Production
issues, security
issues
Release 1 User Story
Ready for
Development
Development
and Test
Automation
Running Test
Automation in
QA
Running Test
Automation in
Staging
Deploying in
Production
Running in
Production
Release 2 ...
Intangible Other Unplanned
Work
• Start where you are! (step one of Kanban method).
• Use Classes of service and work-types that matter to the
team!
5
Managing Flow Efficiency with Effective Collaboration
Cumulative Flow Diagram
• Tracks delivery of quarterly goals.
• Exposes delays and bottlenecks.
Control Chart
• Measures cycle time.
• Enforces efficiency and predictability.
6
Tools & Practices for Increased Productivity!
Being Behavior-driven
even when scripting test
automation with Gherkin
Pairing & Mobbing
when necessary- e.g.
prod/InfoSec issues
User Story
Mapping
for Demo
prep
7
• Provides flexibility, but requires discipline!
• Allows the team to adjust and self-organize.
• Improves visibility of execution issues.
• Enforces teamwork and rapid communication.
• Less time in meetings, more time being productive.
• It is an advanced agile technique requiring fundamental agile skills.
Learnings and Experiences
8
• Flow masters working on perfecting their skills.
• Finding the right amount of meeting time for agile ceremonies.
• Review progress and take guidance from team of agile coaches.
• Discuss and efficiently interface with other teams.
• Publish our findings in team blog.
Next Steps
9
Efficient Flow = Effective Collaboration & Productivity = Faster
Outcome
Being Behavior-driven
even when scripting test
automation with Gherkin
Pairing & Mobbing
when necessary- e.g.
prod/InfoSec issues
User Story
Mapping
for Demo
prep
GetKanban
Simulations for
getting new insight
by team’s own ideas
about making “Flow”
even more efficient
10

More Related Content

Kin2020- flow based product development- an experience report

  • 1. Flow Based Product Development A Venture of A Product Development Team in December 2019Abstract: A pictorial case study about this product development team I coached- to move from mandated Scrum process to a much leaner Scrumban process, teaching the team value of “flow” based product development, in conjunction with team practices such as process eval “futurospective”, GetKanban gamification, distributed mob programming & behavior driven dev/testing. Key takeaways: 1. Transition From Output to Outcome can happen only when the team focuses on “flow” based product development. 2. Technical practices like mob programming and BDD increase the team collaboration and productivity. 3. Mob programming is probably the leanest of all XP practices, in that it cuts the time it takes to develop shippable code! 4. Transition from waterfall/big-bang/compliant process culture requires shift to focus on the 4 values of agile manifesto. 5. Look for opportunities to inject Lean principle of (faster) flow in everything team does! 1
  • 2. Issues with Scrum Process Long scrum duration (3 weeks mandate) leads to mini-waterfall. Short scrum duration (<= 2 weeks sprints) with distributed “siloed tower” teams creates heavy planning overhead. Responsiveness to unplanned work requires breaking the mandated process or using Kanban in parallel. Try Scrumban Process Implement flow-based process without artificial boundaries. Communicate immediately and efficiently. Monitor, measure and optimize the flow. Typical Transformational Challenges- Doing Agile vs. Being Agile 2
  • 3. Process Framework Evaluator “futurospective” – Powerful questions make team decide what will work for it Powerful Questions Explanation Planning: Despite the PO trying to do so, is it impossible to lock down the scope for your chosen timebox? Do you have more than 25% scope churn during the chosen timebox? Scrum: Scrum works best when requirements are stable for the duration of the Sprint so that the team can commit to their delivery. Kanban: Some scope change can be accommodated. By dropping the fixed timebox, Kanban can allow teams to adapt more easily to quickly changing priorities. Scrumban: Iteration planning is done at a regular interval, with the goal of planning is to fill the slots available - not fill all of the slots, and certainly not to determine the number of slots. Decomposition: Even after trying your best, is it impossible to break features into incremental pieces of value to be delivered within the chosen timebox? Both Scrum and Kanban work best when you break your work down into small incremental pieces. The Scrum Sprint timebox can help new teams recognize deficiencies (work not completed at the end of the sprint) and adapt (retrospective). Scrumban: Can you decompose work to lock scope for the timboxed duration? Estimation: Is it hard or impossible for team to size the work in the chosen timebox? Does estimation take more than 3 hours? Kanban: Kanban removes the overhead of estimation in favor of measuring cycle time for like sized items. Work should be comprised of similarly sized activities for Kanban. Scrum: Scrum absolutely requires that all work be estimated so that the team can commit to the sprint. Scrumban: Scrumban does not require estimation. Responsiveness: Is your top priority to optimize responsiveness to customer needs? Must work begin in the current timebox -cannot wait until the next one? Kanban has a strong focus on cycle time, where Scrum has a stronger focus on Velocity. Both can be tuned to provide very similar output, but Kanban has the flexibility to lower batch size to reduce cycle time at the potential cost of productivity. Predictability & Productivity: Is your top priority predictability and productivity for larger projects? You can achieve predictability and a high level of productivity using any agile framework. Scrum provides more guidance on how to handle release planning and progress tracking so is preferable for new teams. Process Oriented Culture: Does your team culture demand higher degree of process ceremonies? Although Scrum has fewer ceremonies and artifacts than many other methodologies, it has more than Kanban and can more easily be integrated into a culture requiring them. Shared Team Members: Do you share engineers with other teams? Does your team lack all the required skills to complete the work? Scrum: Scrum teams work best when they do not have dependencies on people outside of the team . Kanban: With Kanban, others can see when there is work for them to do and pick it up at that time. Variety in work (complexity & size): Are your work items of approximately similar size & complexity? Both Scrum and Kanban work very well with similar sized work items. However, in Kanban the variability between different sized items makes it difficult to adhere to SLAs. Source: Steven Sanoff (PayPal) 3
  • 4. Tools & Practices for Increased Collaboration! GetKanban Simulation workshop for gaining insights by team members producing ideas about making “flow of work” even more efficient, while staying with constraints around existing software process! 4
  • 5. Setting up a Scrumban Board with existing value stream Ready In Dev Ready for QA Ready for Release Ready for Deploy Done Expedite Production issues, security issues Release 1 User Story Ready for Development Development and Test Automation Running Test Automation in QA Running Test Automation in Staging Deploying in Production Running in Production Release 2 ... Intangible Other Unplanned Work • Start where you are! (step one of Kanban method). • Use Classes of service and work-types that matter to the team! 5
  • 6. Managing Flow Efficiency with Effective Collaboration Cumulative Flow Diagram • Tracks delivery of quarterly goals. • Exposes delays and bottlenecks. Control Chart • Measures cycle time. • Enforces efficiency and predictability. 6
  • 7. Tools & Practices for Increased Productivity! Being Behavior-driven even when scripting test automation with Gherkin Pairing & Mobbing when necessary- e.g. prod/InfoSec issues User Story Mapping for Demo prep 7
  • 8. • Provides flexibility, but requires discipline! • Allows the team to adjust and self-organize. • Improves visibility of execution issues. • Enforces teamwork and rapid communication. • Less time in meetings, more time being productive. • It is an advanced agile technique requiring fundamental agile skills. Learnings and Experiences 8
  • 9. • Flow masters working on perfecting their skills. • Finding the right amount of meeting time for agile ceremonies. • Review progress and take guidance from team of agile coaches. • Discuss and efficiently interface with other teams. • Publish our findings in team blog. Next Steps 9
  • 10. Efficient Flow = Effective Collaboration & Productivity = Faster Outcome Being Behavior-driven even when scripting test automation with Gherkin Pairing & Mobbing when necessary- e.g. prod/InfoSec issues User Story Mapping for Demo prep GetKanban Simulations for getting new insight by team’s own ideas about making “Flow” even more efficient 10

Editor's Notes

  1. References: https://www.scrum.org/Portals/0/Documents/Scrum%20Guides/2013/Scrum-Guide.pdf http://www.crisp.se/file-uploads/Kanban-vs-Scrum.pdf (Chapter 6) http://leansoftwareengineering.com/ksse/scrum-ban/ http://www.eylean.com/blog/2013/04/scrum-vs-kanban-vs-scrumban-iterations-work-routines-and-scope-limits/ http://www.netobjectives.com/blogs/why-contrasting-scrumban-and-kanban-belies-lack-understanding-both http://www.ontheagilepath.net/2013/09/scrum-kanban-scrumban-fast-overview-and.html Kanban Applied to Software Development: from Agile to Lean What is Best, Scrum or Kanban?