The Tipping Point by Malcolm Gladwell, Re-read Week 2 – Chapter 1: The Three Rules of Epidemics

Tipping Point

This week we continue our re-read of The Tipping Point by Malcolm Gladwell (Buy a copy and read along). In Chapter one, Gladwell suggests that there are three factors that impact whether an idea or product crosses a tipping point; they are the law of the few, the stickiness factor, and the power of context. Chapter one introduces these concepts and presents real-life examples to illustrate the factors.  

 

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 520 – Velocity and Escape Velocity, An Interview with Doc Norton

http://www.spamcast.net

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

SPaMCAST 520 features our interview with Doc Norton. We talked about his new book Escape Velocity, measurement, and why velocity isn’t generally a good measure for teams. By the time teams get to a point where story point velocity is consistent and predictable, they will have better tools that have fewer negative side effects.

Doc’s Bio

Doc Norton is passionate about working with teams to improve delivery and building great organizations. Once a dedicated code slinger, Doc has turned his energy toward helping teams, departments, and companies work better together in the pursuit of better software. Working with a wide range of companies such as Groupon, Nationwide Insurance, Belly, and JaTango, Doc has applied tenants of agile, lean, systems thinking, and servant leadership to develop highly effective cultures and drastically improve their ability to deliver valuable software and products.

A Pluralsight Author, Clean Coders contributor, frequent blogger, international keynote speaker and coach, in his spare time, Doc has been working on his latest book, Escape Velocity: Better Metrics for Agile Teams. You can find his book on LeanPub at www.leanpub.com/EscapeVelocity

Twitter: @DocOnDev

Web: http://docondev.com/

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 me. Thank you!

Re-Read Saturday News
This week we continue on our journey through 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 tackle a single chapter.  Chapter 6, titled Sunny, introduces Ramesh “Sunny” Balwani to the story. Sunny, Holmes’ live-in boyfriend (the stress on the live-in part is to shine a light on just how close Holmes was to Sunny), adds another layer of toxicity to the Theranos story. The toxicity feels extraordinary but is not that uncommon when teams break down.  

Current Entry:

Week 5 — Sunny – https://bit.ly/2AZ5tRq

 

SPaMCAST 506 – Distributed Agile Teams, an Interview With Mark Kilby

http://www.spamcast.net

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

SPaMCAST 506 – Distributed Agile Teams, an Interview With Mark KilbySPaMCAST 506 features our interview with Mark Kilby.  Mark and I explored distributed agile teams. Agile in distributed environments is doable, but it isn’t easy. Mark provides guidance and advice. Mark recently co-authored From Chaos to Successful Distributed Agile Teams with Johanna Rothman (LeanPub).

Mark’s bio and contact information:

MARK KILBY has cultivated more distributed, dispersed, and virtual teams than colocated teams for more than two decades. Currently, Mark serves as an agile coach with Sonatype, a “remote first” software development company focusing on automation of software supply chains. Previously, Mark led agile transformations, from startups to Fortune 500 companies. Mark also cultivates dispersed communities, such as Agile Orlando, Agile Florida, VirtualTeamTalk.com, and the Agile Alliance Community Group Support initiative.  Mark’s book, From Chaos to Successful Distributed Agile Teams, is co-authored with Johanna Rothman and is available now via http://markkilby.com  and https://leanpub.com/geographicallydistributedagileteams

Twitter: @mkilby

Linked In: linkedin.com/in/mkilby

Re-Read Saturday News

Week 2 of our re-read of The Checklist Manifesto by Atul Gawande (use the link and buy a copy so you can read along). Chapter 1 builds the case that the world we live in and the work that we do is very complex. Complexity creates the possibility for errors. Checklists are a tool to help avoid errors in complicated and complex environments.  

Current Installment:

Week 2 – The Problem With Extreme Complexity – https://bit.ly/2AGZQZX 

 

Consensus Decision Making Forever – Sometimes

Consensus Decision Making Forever – Sometimes

Consensus decision making is a useful decision making framework, however, it is not the best way to make a decision in every scenario. The factors of decision making that impact use of the consensus approach making include: the requirement for speed, how frequently the decision is made, the potential impact of a decision, and information availability for a decision. Each of these factors can be used to determine when consensus decision making is most effective.

 

Don’t Shortcut Shu Ha Ri

Shu Ha Ri

 

I spend several hours every week running – on purpose. I don’t run very fast, which means when I have the occasional fall because my mind wanders, I inflict very little damage to the ground. This is a preamble to letting you know that I have lots of time to think when I run (which is the reason the ground occasionally gets in my way). Recently I have been thinking about just how rigorously practitioners need to follow processes, methods, and frameworks and when it makes sense to tweak processes to fit the culture.

 

Agile Where Agile Fears to Tread: Large Mainframe Projects

 

You Are NOT Alone!

 

Change is never easy when there is fear, the end state is unclear or the change threatens what made you successful in the first place.  Change is hard even now, when we are well into the agile age, with any number of second and third generation transformations going on.  However, many people are still being left behind because of the mistaken assumption that each agile framework is all or nothing.  In the first article in this theme, we postulated that five major categories are held up as no-go zones for agile.  Mainframe projects are one of the areas that have that have been held up as problem areas.