Scrumban: Different Genie, Different Bottle

Sometimes you just have to . . .

I was originally asked to help provide additional ideas to convince a Scrum Master that had recently joined a team due to a company rotation policy not to give up Scrum (full scenario). The change in team composition led to problems.  On the surface, the decision by the wayward Scrum Master to abandon Scrum in favor of Kanban is an emotional reaction and does not reflect many of the leadership problems the Scrum Master introduced. Assuming that the leadership problems have been sorted, it is time to contemplate how the team will work as they move forward.  The question was posed as use Scrum or use Kanban; however, there is a third (and possibly better) answer. Do both — Scrumban.

 

Kanban: Throwing Away The Bottle

Sometimes you just have to . . .

If you were not moved by the case for Scrum then the next step, just as suggested by our wayward Scrum Master is kanban. If re-committing to Scrum is equivalent to putting the genie back in the bottle, then adopting kanban is the equivalent to throwing the bottle away. Kanban is a flow-based framework based that originated from concepts in lean manufacturing that have been tuned for software related projects.  A team or organization using kanban pulls work from a workflow (across the board) at a pace equal to the work in process limits for each step in the process. Kanban requires team members to have the discipline to observe the policies set for the team such as only pulling new work when it can be started and swarming to bottlenecks when they are identified. Efficient and effective teams using kanban are very disciplined; whether this is because of the people or the framework is debatable.

 

Scrum: Putting a Genie Back Into a Bottle

Sometimes you just have to . . .

You can never put a genie back into a bottle.  In I Messed Up A Scrum Team Should I Do Kanban? We described a scenario where a well-performing Scrum team had their Scrum Master replaced and troubles ensued. The question that was posed was whether—since scrum was no longer working—perhaps kanban should be adopted. Given the tumult at the team level, putting the genie back in the bottle and pretending nothing has happened is not a good strategy.  Assuming the leadership issues have been addressed the question returns to whether to recommit to Scrum, shift to Kanban or combine the two.

 

I Messed Up A Scrum Team Should I Do Kanban?

Sometimes you just have to . . .

A friend and colleague recently presented me with a scenario and then as the punchline asked for more ammunition to alleviate the problem.  

The Scenario:

 

Story Points – A Behavioral Fix

Change Behavior To Change Value

Many teams find story points only a partially useful tool to facilitate the flow of work within a team. As noted, story points are not all unicorns and kittens story points can have issues. Can story points be fixed, or better yet can story points still be useful? On the whole, story points are inherently fine if they are used with discretion and structure, to meet a team’s needs.  The words discretion and structure are code for “change”. Reforming the use of story points to make them safe again doesn’t require changing how teams assess or determine story points, but rather how people in the value chain behave once they have a number (or two).  An upfront agreement for using story points makes story points “safe.” Four attributes are useful to guide any upfront agreement on the usage of story points. The RATS criteria are:

Range – Express story points and story point metrics as ranges.  Story points are often used to express the perception of the size or value of work. Using a range to communicate both inside and outside the team mitigates the risk of falling into precision bias.

Approximate – Agree that story points represent a team’s best guess using the knowledge available at a specific time.  Knowledge will evolve as the team develops specific experience, does research and/the environment changes. Story points are not precise.

Team – Gather a team.  Story points are a reflection of a collaboration between multiple points of view. As a collaboration of a group, they can not be used to assess or measure an individual.

Separate – Separate the use of story points from answering client and management questions related to when a function will be delivered and how much that functionality will cost from facilitating the flow of work with the team.

Regardless of what a team uses story points to assess or to approximate, the output of the process is a synthesis of thinking from a group of people.  Story points represent the thought process of the team that created them, influenced by the environment they operate within. Every individual on the team needs to understand the central thread of logic followed to generate story points; however, even on a mature team, individuals will have differences which further emphasize the need to establish a RATS-”based agreement on how story points will be used to ensure healthy behavior.

 

SPaMCAST 521 – User Stories and Legacy Code, Software Catechism, Essays and Discussions

http://www.spamcast.net

Listen Now
Subscribe: Apple Podcast
Check out the podcast on Google Play Music

SPaMCAST 521 features our essay on user stories and legacy code.  A common question is how user stories can be developed for legacy code or for problems that crop up in production.  The implication is that creating user stories is too hard when dealing with legacy code changes or too slow when dealing with production problems.  User stories are a core tenet for most agile approaches.

This week we also have a visit from the Software Sensei, Kim Pries!  Kim talks about training in a column titled, “Software Catechism.”

Can you help keep the podcast growing? Here are some ideas:

1. Tell a friend about the cast.
2. Tweet or post about the cast.  Every mention helps.
3. Review the podcast wherever you get the cast.
4. Pitch a column to me. You are cool enough to be listening; you deserve to be heard.
5. Sponsor an episode (text or call me to talk about the idea).
6. Listen.

Whether you do one or all six, being here is a big deal to everyone that helps get the podcast and blog together. Thank you!

Re-Read Saturday News
The Software Process and Measurement Cast and Blog crew is on the road this weekend so we are going to take a day off from our re-read of Bad Blood, Secrets and Lies in a Silicon Valley Startup by John Carreyrou (published by Alfred A. Knopf, 2018 – Buy a copy and read along!)   Today we re-visit an entry from 2013, In 2013 we ran a series titled “Motivational Sunday”. In this entry, we talked about the relationship between commitment and habits. I have tweaked the works a little but the sentiments are no different.

Habit and Commitment – https://bit.ly/2KbKq13

 

Story Points: Why Did We Get To This Point

How did we get to this point!

Story points were originally developed as a metaphor to give a rough answer to the question of how much functionality could be delivered in a specific period of time.  The problem is that all good metaphors are eventually abused or, worse, people forget that the metaphor is a simplification and approximation of real life. Metaphors become reality.   Three basic behaviors of leaders and stakeholders in software development (broad definition) have lead the metaphor of story points to evolve into story points as measures — something they FAIL miserably at.