Events of an Effective Development Cycle

Events of an Effective Development Cycle

A frequent inhibitor to effective development process is misunderstanding of the intended structure and outcome of the recurring events in a batch development cycle/sprint/iteration. I am frequently asked to provide a clear, comprehensive example of how an effective development cycle should be structured.

In service of that need, I have published my preferred approach to structuring the events of a development cycle to the Compendium. The example uses the common 2-week cycle length, and the event sizes should hold for a 3-week cycle. Those using 1-week cycles should be able to scale down the event sizes, but each event should still exist as fundamental parts of the system.

The diagram models the event duration scale relative to days to illustrate just how little time in the cycle is required to have an effective process.

This new content should serve as a compliment to the Batch Cycle Planning and Tracking Guide, Development Log, and Development Process Metrics content.

Prescription for Process Metrics: Apply Sparingly, Consume with Context

Example throughput chart for a team

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

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…

The Myth of Commoditized Excellence

If you give it a name, people will expect you to hand it to them in a box. - Attributed to W. Edwards Deming, but unverified

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.

Read more…

Roles in an Effective Development Team

Whiteboard drawing of the Roles in an Effective Team

Roles Common to All Teams

Team composition and roles can vary widely across development teams. The type of product being developed, team charter, organizational culture, and industry norms all impact whom we place into teams.

When taking an agile approach to product development, what commonalities should there be across teams as far as roles and responsibilities?

Over the years, I have settled upon three essential roles for healthy and effective product development teams: Cross-Functional Team Members, the Team Steward, and the Product Steward.

Read more…

The Iterative Cycle: Commit, Execute, Evaluate

The Iterative Cycle: Commit, Execute, Evaluate

What does it mean for a team to develop software in an iterative fashion? In the wash of various processes within the agile ecosystem, iteration has come to be an overloaded term used with little thought to its purpose or the context for those systems.

The focus for this article is not iteration upon the products in the team’s portfolio, but rather the team iteratively delivering the work in their backlog.

In my experience, a healthy iterative cycle for a team involves three phases: Commit, Execute, and Evaluate.

Read more…

The API for Teams

The API for Teams in an IDE

A Common Contract for Teams

In evolving toward greater agility, we must strike a balance between uniformity across teams and allowing flexibility for process tailored to unique team contexts.

As your organization grows from 2 to 10 to 50 teams, you have to be able to coalesce their delivery queues into an overall picture of what is being developed. However, if you push for too much uniformity, the process is no longer effective for all the types of work that go into developing your product, often to the detriment of quality and timely delivery.

Seeking that balance, I asked myself years ago what is the minimal commonality needed across teams. Coming from a (mostly back-end Java) programming background, I was inclined to express this in terms of an API. I call it The API for Teams.

Read more…

Four Outcomes of Effective Development Process

What should your development process provide?

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.

Read more…

The Story of Why I Left Riot Games

Image courtesy of Vladimir Gitlevich

“So this is it. This is going to be the thing.”

That’s what I remember thinking as I left the room where I had just finished a conversation with two female mentees.

I had wondered for some time when there would be an incident serious enough that I had to talk to leadership about unacceptable behavior in the workplace, and here it was.

Read more…