Collect and Send
With the help of a rational bit of Scrumban, OurCompose gets new features that even high-budget startups are looking for, like the dashboard, and it's own Ansible collection!
Intro
- These People Who Work From Home Have a Secret: They Have Two Jobs - WSJ
- 1Password 8 will be subscription only and won’t support local vaults
- Why is it so hard to be Rational
- Congrats on your $2m seed round…
News / Community Updates
OurCompose Developments
Integration Discussion - Bitwarden - Folders, Organizations, and Send
Grab Bag - What is Scrumban?
Scrumban is a hybrid of Scrum and Kanban. It combines the project management and product delivery focus of Scrum with the pull systems, workflow visualization, and process improvement of Kanban
The term “Scrumban” was originally coined by Corey Ladas in his 2008 paper, Scrum-ban, and expanded upon in his 2009 book Scrumban. The original goal of this methodology was to use Kanban to improve Scrum.
Problems needed to solved
- The rules of Scrum are not always enough to help [team members] get past their particular challenges
- Too many new ideas
- The “pre-backlog” keeps growing without resolution
- Product owners appeared to be be performing insufficiently well
- Frequently were being rotated, delegating/splitting responsibility, or being replaced by committees.
Recap
- Scrum is a product development framework
- Roles:
- Product Owner
- Scrum Master
- Team Member
- Scrum story format:
- _“As a
I want to <specific action I'm taking> so that ."_
- _“As a
- Time-Boxed Iterations
- Roles:
- Kanban is a method for changing and improving a team’s process
- Start with what you’re doing now
- Evolve using small incremental changes based on experimentation and data
- Set WIP limits for each stage in the process
- Detect when the workflow is overloaded and make adjustments to address the constraints that are the root cause of the overload.
- Establish a pull system based on kanban signals
- Teams self-organize around available cycles and self-assign tasks
- “Just as an unregulated index card on a cork board is not a kanban, time-boxed iteration planning is not pull”
- Start with what you’re doing now
What actually changes?
Team members use Kanban utilize systems thinking to analyze and understand their workflows.
Optimize Flow
Kanban’s visualization tools provide transparency that exposes “bottlenecks, queues, variability and waste”
Metrics can expose where the system is overloaded but the team has not discovered the source of the problem.
- Lead Time
- Concept to Cash
- Cycle Time
- Hands on keyboard
- WIP Limits
- Task Count
- Complexity
- Story Points
- Time Tracking
- Throughput
- Improvement over time
- Performance Reality
- Stability of workflow
- Predictable Process
If the product owner can show the stakeholders that this new rule could lead to faster development, and lower lead times, stakeholders will be happy to accept their decisions. Alternatively, if lead times do NOT decrease, the experiment could be perceived as a hindrance rather than a boon. Remember, these metrics are only useful if they translate into a perceived faster development turnaround.
Better Backlog Management
A perfect example of an ever-growing product backlog issue can be found in: Agile Product Ownership in a Nutshell
A very easy fix for a feeling of being overloaded and facing increasing pressure to multitask and cut corners, is to visualize where the work is piling up. Adding a pre-backlog “Feature Requests” column will expose that more feature requests are coming in than can be handled by the team. This is a problem that can be addressed at the Product Owner level - saying “no” to additional work to meet the constraints of the new column. Adjusting the WIP limit up or down based on experience will help to find the optimal limit that leads to the lowest average lead time per story. A “Rejected” column is optional if it helps communicate to stakeholders better when it’s visualized.
This is also known as “Level 2 Scrumban”
Once you’ve broken up the timebox, you can start to get leaner about the construction of the backlog. Agility implies an ability to respond to demand. The backlog should reflect the current understanding of business circumstances as often as possible. In other words, the backlog should be event-driven. Timeboxed backlog planning is just that, where the event is a timer, and once we see it that way, we can imagine other sorts of events that allow us to respond more quickly to emerging priorities. Since our system already demonstrates pull and flow, that increased responsiveness should come at no cost to our current efficiency.
Common Misconceptions About Scrumban
Scrumban is simply a tool to organize work and make it more efficient
Scrum is focused on project management and product delivery; Kanban is focused on process improvement
If Scrumban is adopted because a team is overloaded, it is likely to succeed in changing the way [the team] works, but unlikely to fix the problems that caused the overload.
After the evolution stops, [the team] is no longer following Kanban or any other method for improvement.
Scrumban is essentially “Iteration-less” Scrum
Scrum teams are attracted to the idea of Scrumban because it provides a convenient excuse to remove the “hard” part. Iteration is not just a way to break projects up into phases; it is a tool for accountability, and that accountability can be uncomfortable. This is one of the most important features of Scrum because it helps teams make decisions based on experience and actual, known facts from their projects.
Things that need to happen with or without iterations:
- Team demonstrates working software
- Stakeholders refine requirements
- Team reviews process obstacles
- Team agrees on process improvements
- Team agrees on what work to prioritize
How Scrumban teams can move beyond their misconceptions
How to replace iterations
An effective Scrumban implementation must include practices that provide the empirical process control benefits of iterations.
INCLUDE PRACTICES THAT PROVIDE THE EMPIRICAL PROCESS CONTROL BENEFITS OF ITERATIONS
- Planning
- Predictability
- Accountability
- Ceremonies for Reflection
“Cadences” are triggered by milestones or external events rather than a time-boxed iteration. Each work item can be considered part of the reflection process, and no work item is considered complete until it’s been included in a retrospective.
How to implement process improvement
- Step 1
- Start with what you do now
- Agree to pursue incremental, evolutionary change
- Initially, respect current roles, responsibilities, and job titles
- Step 2
- Visualize the Workflow
- Limit WIP
- Manage Flow
- Make Process Policies Explicit
- Implement Feedback Loops
- Improve collaboratively, evolve experimentally
The tools we use to get it done
At Compositional Enterprises, we value our time as much as you do. That's why we only use the best Free, Libre, and Open Source tools to produce our quality content and products.
Take action and start using the same secure and convenient tools that we use by signing up for your OurCompose instance today! Invest in your community by donating directly to the podcast! Every bit (and byte) goes back into growing and spreading the show. Otherwise, to stay updated with the show and all future developments, find us on reddit or sign up for our mailing list using the form below!