The Yes List

I like to give give credit to folks who lend me ideas. Blogs I read, videos I watch, radio I listen to — they all fertilize the garden of my mind. Sometimes however, I don’t remember where I read / saw / head something. I’m sure this post draws heavily on an article I read somewhere, video I watched, etc but I simply can’t recall were. If you recognize the source, drop me a comment so I can thank the author :).

Difficult to Master

The Scrum Guide says that, although Scrum is “simple to understand” it is also “difficult to master.” In an organization lacking agility, building a strategy for improvement using the Scrum framework can be an overwhelming prospect. Even finding a starting point bring a defeated feeling.

Sowing, Growing, and Hoeing

To start, simply ignore (for now) the ones who are saying “no” to you. Instead take note of those who are saying “yes.” I mean this literally: write down their names and keep a “Yes List.” Think of them when you make your strategies to bring agility where there is none. Make a special effort to amplify the exposure of their good practices. Nurture agility where it is taking root. Toil selflessly to weed out the dangerous mindsets and fearful attitudes that threaten to choke out and obstruct.

An agile pioneer may be only one person, so they must sow agile principles and values in the fertile ground of their like-minded colleagues. Work the good ground of the “yes list.”

In due season, diligent leaders will reap a harvest of organizational change.

 

jknight

Jason is a developer, Scrum Master, writer, teacher, coach, husband, father, and community leader out of Tulsa Oklahoma. He's been delivering software since 2007 and absolutely loves the values and principles of agility especially as given form by the Scrum framework.

  • Saumya

    Thanks Jason 🙂

  • Dad

    I am curious……how “scum” compares to “lean manufacturing?”

    • jknight

      You certainly know more about lean manufacturing than I do. Honestly, I don’t know enough to even compare the two. What I can say is that Scrum is a framework that software development teams use to solve complex, adaptive problems. It is defined by the Scrum Guide (www.scrumguides.org) and consists of events, roles and artifacts. Scrum is designed to guide teams who implement their own Scrum “instance” and serves to teach them agility.

      In software terminology, agility is defined many ways. I find http://agilemanifesto.org/ to be extremely helpful in understanding the term in a software development context. Don’t forget to read the http://agilemanifesto.org/principles.html section.

      I’m not sure how that compares to the principles and practices of lean manufacturing. If there are such things as “best practices” in lean manufacturing, then I’d wager that Scrum is an organge to LM’s apple. Scrum is best suited for complex, adaptive problems and environments where a best practices is rarely a legitimate term. I use the term complex as described in this video describing another framework called the Cynefin framework: https://www.youtube.com/watch?v=N7oz366X0-8. It’s a great video and has aided me many times. Enjoy!

  • Dad

    Good hard data is a bottom line indicator. What types of numbers can you put together as to show progress?

    • jknight

      There are certainly metrics that can aid a team in inspecting its activities in order to spot negative trends and identify areas to exploit for improvement. I’ve seen teams gather the number of defects (read: bugs) found in code and correlate that to the presence or absence valuable tests performed against the code. They’ve noticed that untested code contains more bugs (gasp) and well tested code produces significantly fewer bugs (double gasp). They’ve determined that, while writing untested code doesn’t cause bugs, there is a strong correlation between the two factors.

      I’ve also seen teams track the velocity of their work output. They use some sort of scale to measure the amount of valuable work they’ve been able to accomplish in a given time frame and qualify that with measurement of team capacity. They can use these data points to create accurate forecasts for the amount of valuable work they can expect to achieve in a given time in the near future given their expected capacity. Within any given period of time, I’ve also seen teams get value from tracking their WIP through the various stages of “done”ness. By examining the flow of work, they can pick out bottlenecks and areas where effort is being wasted. I’ll give a quick plug to “The Phoenix Project” by Gene Kim, Kevin Behr, and George Spafford as an excellent resource that has formed much of my current thinking on the subject: http://itrevolution.com/books/phoenix-project-devops-book/.

      Often however, these and a multitude of other metrics used to abuse teams. A saying I’ve heard goes like this, “Game theory works. Be very careful which games you design.” When measures of velocity are reported up the management food chain (especially if they happen to be numeric figures), bad things can happen. Developers are given bonuses on the number of bugs they fix (not on preventing bugs), teams become fearful of taking valuable risks that might result in a lower velocity (in the short term), and I’ve even heard some reports on the radio of wearable technology e.g. fitbit, apple watch that companies are considering using to track their employees actions! I think these and other such metric abuse are colossal mistakes, yet the prospect of applying scientific management to software is too enticing to ignore for the pointy haired boss.

  • Pingback: Stealth Organize | Jason Knight()

  • Pingback: When the disciple is ready... - Jason Knight()

  • Pingback: Semper Agilis | The Well()