Barry Hawkins (Posts about culture)

Prescription for Process Metrics: Apply Sparingly, Consume with Context

Barry Hawkins — Fri, 22 Mar 2019 17:00:00 GMT

This week, I continue to build out the Development Process section of the Compendium with the addition of Development Process Metrics.

When readers find that I only recommend two metrics to be common across all teams, they will either be excited or disappointed, both for reasons covered in the material.

Healthy uses of team-level process metrics are called out in the Goals section of the entry:

Help teams cultivate an understanding of their capacity for delivery.

Serve as one point of information for leadership to see which teams need help; the type of help will be determined through conversation with a team to understand the context of their challenges.

For now, I have only documented the two core metrics common across all teams. As I begin to flesh out the Continuous Process category, I'll add in the additional metrics that apply to those systems like Lead Time, Cycle Time, etc.

I'll leave you with one last excerpt from the final section titled "A Cautionary Note on Metrics":

The key mistake I see in development process metrics is treating the available data as being far more meaningful than it actually is. Because the measurement, analysis, and visualization of data is such an established practice in business, creating metrics on that data takes very little effort. It seems logical that we would create all manner of graphs and interpretations of data.

However, the accuracy of story points and task hours is deliberately constrained, because it models the degree of accuracy in software development estimation, which is directional at best. Applying overly-granular statistical analyses to this type of data leads to false conclusions and interpretations, not only failing to add value, but actually subtracting value by creating overhead and providing misinformation.

Never lose sight of the intentionally minimalist nature of effective development process. The goal is to create just enough structure to enable teams to be effective, and to not go further than that. The rest of the emotional and intellectual bandwidth of teams should be kept free to focus on creating the best possible outcomes for the products we deliver.

Launching The Hawkins Compendium with the Batch Cycle (Sprint/Iteration) Planning and Tracking Guide

Barry Hawkins — Thu, 21 Feb 2019 22:30:00 GMT

For well over a decade, clients and colleagues have asked that I publish some of my guidance and training on all things Product Development so they could make use of it.

I am happy to announce the launch of The Hawkins Compendium, a curation of material I have developed over the years while leading development teams and organizations to greater levels of productivity and collaboration.

Read more… (1 min remaining to read)

The Myth of Commoditized Excellence

Barry Hawkins — Wed, 06 Feb 2019 18:00:00 GMT

A New Idea

When we learn new things from grappling with problems, it is natural for us to want to share those learnings with others, in hopes that they will face similar challenges with less of a struggle.

How do those well-intended new ideas so often evolve into movements that seem to lose their way, and at times do more harm than good?

In the course of observing and at times being involved in this phenomenon, I sought to understand what I saw happening time and again. Almost a decade ago, I arrived at an explanation that I named The Myth of Commoditized Excellence. What follows are the steps that can lead down this unfortunate path.

Four Outcomes of Effective Development Process

Barry Hawkins — Tue, 08 Jan 2019 17:30:00 GMT

Why Are We Doing This?

Have you ever wondered why your team is using its current development process?

If you’re the person facilitating the process, have you ever been asked “Why are we doing things this way?” and found yourself unable to articulate anything beyond process mechanics?

For me, an effective development process is meant to provide four key outcomes beyond merely delivering work. I expect these outcomes irrespective of the methodology, framework, or tools being used. My focus here is team-level development process, but the outcomes certainly scale to the organizational level.

IBM developerWorks Podcast: Barry Hawkins on agile software development

Barry Hawkins — Fri, 20 Apr 2012 19:20:05 GMT

Earlier this year, my friend Andrew Glover interviewed me for season 4 of his IBM developerWorks Java Technical Podcast series (iTunes) on the topic of Agile software development. The episode is titled "Barry Hawkins on agile software development" and runs 41:03 in length.

This was an enjoyable interview; I've known Andy for years, and his style as an interviewer is quite comfortable and flows conversationally. What I really enjoyed about the venue is that it afforded me the chance to talk about software development, the Agile ecosystem, and the primacy of a healthy company culture in ways that I typically do in one-on-one or small group discussions, or talks at conferences that don't get recorded.

Read more… (1 min remaining to read)

Empirical Process Control: Why Scrum Works

Barry Hawkins — Fri, 13 Apr 2012 20:05:25 GMT

Being in my ninth year of applying the processes and technical practices of Agile and Lean software development, people are sometimes surprised to hear me say that Scrum is still my preferred process. Let me explain.

The Discipline Deficit

Barry Hawkins — Wed, 22 Feb 2012 20:02:28 GMT

I consult with all sorts of companies looking to adopt elements of process and practice from the Agile/Lean offerings. Whether it's Scrum, Test-Driven Development, User Stories, Test Automation, Continuous Integration, Agile Estimation and Planning, Sprint Planning, or Sprint Retrospective facilitation, one challenge pervades across most scenarios. I have come to call it The Discipline Deficit.

Read more… (1 min remaining to read)

Is it just my company that has a hard time with Agile?

Barry Hawkins — Fri, 14 Oct 2011 18:59:15 GMT

After an Agile adoption is underway and the feedback mechanisms of most Agile processes begin to function, one or more team members usually ask me something like the following:

Is it just my company that has a hard time with Agile?

No, it's not just your company. However, don't take comfort in that.

I shared something on Twitter that I think sums up why companies have a hard time with Agile:

Agile practices and processes serve motivated, self-directed teams who work hard. It does not create them. @barryhawkins

Ask an Agile Coach: What is an Agile Coach?

Barry Hawkins — Sat, 08 Oct 2011 00:15:41 GMT

This installment of the Ask an Agile Coach series is a question normally asked by persons outside my field, but lately I have been asking it myself:

What is an Agile Coach?

Good question. I am not sure anymore.

Still a place for blogging

Barry Hawkins — Thu, 19 May 2011 22:08:38 GMT

A few years ago, my blogging fell off sharply. There were multiple reasons for that. I began to spend my discretionary time elsewhere, including with my young child and playing World of Warcraft with my wife after the little one was asleep. Additionally, I began to lose interest in some of the main topics I had been writing about, in particular my involvement in the Debian project.

At that time, I began to wonder if perhaps blogging had become passé. Jokes about the ubiquity of banal blogs seemed to show up everywhere. I had adopted Twitter and Facebook fairly early, and I thought for some time that perhaps these social networking outlets were the successors to blogging.

They are not.

Read more… (1 min remaining to read)