As a point of departure let’s use Lane Wagner’s observations on four problems faced by current common process:
Leave Scrum To Rugby - 4 Major Issues With Using Scrum | Hacker Noon
*Bitcoinist, libertarian, atheist, cryptography fan, and founder of http://qvault.io Scrum is a buzzword, the virtue…*hackernoon.com
Problem #1 — Scrum Is Vague
Here’s how Uclusion’s built in workflow and rules make the state of development crystal clear:
At a glance, Dene Jille’s story in Proposed is not approved yet (red text), her story In Progress is on track, her story in Review has unresolved comments (red text), she is Blocked on “Map software” story and Requires Input on “Naming and domain” story.
This is all backed by Uclusion enforcing only one story In Progress at a time and opening a blocking type comment automatically moving the story to Blocked. Also, Opening a Dialog on a story automatically moves it to Requires Input, and if a story is past its estimated completion date then Dene has to enter a progress report or the whole card shows yellow.
Problem #2 — The “Sprint”
Sprints don’t enable agile software delivery — they crush agile altogether unless you live in some dinosaur world where collaboration can wait to happen once every two weeks.
Uclusion Workspace with a new edit showing a highlighted diff
Uclusion works a different way.
Don’t maintain a backlog of fully flushed out stories that may or may not be ever implemented. Instead keep your requirements in a wiki like area in the Workspace. When the requirements are changed everyone will be notified and see a diff.
A developer or team lead will write up a story from the list of requirements and assign it.
The story will be in Proposed and one or more members of the team can approve it
If you really want every single team member to estimate and approve the story then there is a Workspace setting for the number of approvals required — change it to the size of your team. The important thing is that the approval, implement and review cycle in Uclusion is truly continuous — not on arbitrary Sprint boundaries.
Problem #3 — The Scrum Master
Effectively Uclusion has automated some of what was perceived as a Scrum master’s job.
Uclusion notifies everyone so a Scrum master does not have to
However fully agile software delivery has a lot better things for a process person to do. With the team at full speed and potentially changing direction more often the work shifts to helping get everyone on the same page. Here is where Uclusion’s structured communication shines:
Opening a TODO on a story prevents it from changing stage until the TODO is resolved.
Options for doing a story get their approval right inside the story. Now when the team lead or process czar wants to keep things moving he can see exactly what the issues are and, if necessary, call meetings that have an agenda that makes sense.
Problem #4 — Estimates
In Scrum you don’t even write down people’s individual opinions.
Much of the Scrum ceremonies are data for the sake of data instead of being actionable. If your burn down chart looks bad or Sprint estimates are wrong what are you going to do about it? Most likely have a retrospective meeting where nothing is resolved either. Instead of a traditional retrospective Uclusion recommends opening a Dialog and doing something with about it now — not 2 weeks later.
Its just easier
If you are a team lead insist on a process and supporting collaboration tool that matches the way software is built in 2020. We think Uclusion is that tool and would love to talk about it — https://calendly.com/uclusion/30min.
Top comments (0)