SPaMCAST 542 – Kittens, Exploding Kittens, and Risk-Based Planning: An Interview With Kevin Rush

http://www.spamcast.net

Direct Playback
Subscribe: Apple Podcast
Check out the podcast on Google Play Music
Listen on Spotify!

SPaMCAST 542 features our interview with Kevin Rush. Mr. Rush has developed an innovative approach to facilitate sprint/iteration planning.  Kittens, exploding kittens, and fat cats are used to help teams probe whether the team understands the story and if the story is broken down well enough for the team to reduce the risk of failure.  All change agents talk about making changes at the team level but many fail to change how they work, Kevin suggests that experimenting with different approaches is eating our dog food. Way too many pet metaphors, but a great discussion.

Kevin’s Bio

Kevin is a certified Scrum Master and Agility Enablement leader at Hyland Software. Before coming to Hyland he worked as an innovation consultant and coach with for-profit and nonprofit organizations throughout Northeast Ohio. A graduate from DeVry University he spent time as Technology Coordinator for several local school districts before transitioning to ministry then back to tech! When he’s not working with teams and organizations he spends his time with his beautiful wife, Sondra, and their three beautiful daughters.

 

SPaMCAST 536 – An Executives View of Agile Transformations, An Interview with David Sohmer

http://www.spamcast.net

Direct Playback
Subscribe: Apple Podcast
Check out the podcast on Google Play Music
Listen on Spotify!

SPaMCAST 536 features our interview with Dave Sohmer. Dave is an executive that has led two separate major agile transformations.  Mr. Sohmer provides an executive’s perspective on the impact of adopting agile in two major financial institutions. The two very different companies took to two very different approaches to agile.

Bio:

Dave Sohmer is a technology and operations executive with over 25 years of experience.  He has spent many years in the code but has come to enjoy the people and process side of software almost as much.  Dave has built and led many development teams at scale at Northern Trust and Bank of America Merrill Lynch over the last 20 years. Over that time he has come to believe in the power of the team as the fundamental unit that unlocks business agility.  He has championed two large scale Lean Scrum transformations within the financial services sector and has come to appreciate that a healthy mix of Lean principles, Agile values, Scrum by the book, XP practices and common sense will radically change your business’s view of technology from misunderstood adversary to trusted partner.

LinkedIn: linkedin.com/in/davidasohmer

Email: david@sohmer.net

Re-Read Saturday News
We continue our re-read of The Tipping Point by Malcolm Gladwell. Chapter Six of Malcolm Gladwell’s The Tipping Point continues the discussion of the role of context in approaching a tipping point.  Stop borrowing your best friends copy and buy a copy of the book for yourself!  

Check out the current entry of Re-Read Saturday at www.tcagley.wordpress.com

Next SPaMCAST
SPaMCAST 537 will feature an essay on the use of assessments for agile efforts.  Assessments come under a wide variety of names: appraisals, health checks, audit or even assessments. These terms are commonly conflated.  Assessments are a tool to prove a point. The essay in the cast explores the myriad types and reasons for assessments.

We will also have a new column from the Software Sensei, Kim Pries.

 

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.