Silent But Deadly Guy

I get testy when the software community measures developers.

Many software projects use Sprint Burn-Down charts (SBD charts) thinking they are measuring Velocity.

My beef with SBD is that Velocity is misunderstood. I care most about the experience of a software product (e.g., general quality and usability). SBD is, at best, misused, if not useless.

Speed and Direction Define Velocity

We think we’re measuring velocity when we’re tracking the illusion of speed, and all the while, direction is AWOL.

Maybe speed isn’t all it’s cracked up to be. Here’s the thing:

We have already wrung most – if not all – the speed & efficiency we’re going to get from the  development team.

No more speed. No more getting faster. No more SBD.

If we want better software products, it’s time to critique the Teflon Players in the software equation — The Business. We’d be way ahead if we figured out how stakeholders can be accountable to the product team and to provide meaningful direction as a software product takes shape.

If you don’t know where you are going, it’s easy to iteratively not get there. ~David Hussman, 5:40 PM Nov 3rd, 2009 from TweetDeck


Silent But Deadly

The moniker Silent But Deadly Guy evolved during a software project that recently went up in flames. Silent But Deadly Guy was a gratuitous Project Manager the developers started calling Sprint Burn-Down Guy in recognition of his sole contribution to the effort — the daily Burn-Down chart.

Soon Sprint Burn-Down Guy was shortened to the acronym SBD Guy.  Then by a simple twist of acronym morphed into Silent But Deadly Guy.

The Silent But Deadly story encapsulates how I feel about ceremonial metrics like Sprint Burn-Down that have little to do with making kick-ass software.

Scrum’s Achilles Heel & Where Scratch Meets Itch

Anders Storm, Head of Development and IT at Tekis AB, posted a cogent reminder of all that’s good about Scrum (see Anders’ post Why I Like Scrum! on his blog Product Development).

Scrumbaya (like Kumbaya)

Anders and I share many of the same likes about Scrum. Scrum was my first step into Agile (thanks Markus). I started a jaded curmudgeon (my apologies Markus), but my Scrum-mates revolutionized my thinking. I am grateful to the pioneers of Scrum.

I like Scrum for its humanity, accountability, explicit trust in programmers, and inherent fairness.

Needs Improvement

I have one criticism of Scrum, but it’s a big one…

The Achilles Heel of Scrum is the Product Owner. The Product Owner is a serious flaw in the approach. In my experience, Product Owners operate on notions about what’s most valuable (what’s a high priority), rather than on verifiable data.

The Scrum community applauds itself for its transparent burn-down charts and their inherent “velocity” when what they’re actually transparent about is speed (e.g., because the direction component is sorely missing).

It bears repeating that

It doesn’t matter how fast we deliver, if we deliver junk.

Verifiable Value

Scrum must evolve beyond the concept of a limited user proxy, like Product Owner, then figure out ways to better understand, measure, and verify the user experience.

In almost all cases I can think of,

the people actually using our software is where the scratch meets the itch. 

Our goal, as always, is to produce incremental value. But in this case, it comes via verifiable value (direction) and not just speed.

I am looking for ways to get to Verifiable Value and to limit Seat-of-the-Pants Guesses.

More

Curling Software

Over the past few months, I have the pleasure-filled dumb luck of working with a very smart and very funny person to review and edit a book about producing software written by a very smart and very funny mutual friend and mentor.

In anticipation of reviewing the final chapters, the very smart and very funny co-reviewer of the book, who coincidently is learning the sport of curling, tweeted to me from the Bemidji Curling Club about our upcoming collaborative editing session. I paraphrase the tweet:

Hopefully we’ll get a good rock, take it to the house, and land it on the button.

All I know about curling is what I’ve learned from Wikipedia, but I’m a sucker for metaphors that help me understand what is we software developers do.

I haven’t made a resolution for the new year, but I hope the upcoming decade is one where I can distill the navel-gazing goo that oozes like a Jell-O drip in our community, see things clearly and do some practical things with a healthy dose of humility that makes incremental progress.

Curling software is the anti-movement software movement. Curling software needs no manifesto.  And

We don’t need no damn certifications

Curling developers out there know who you are. We’re the people in black wool top coats and hats waving our brooms… unlike all the folks traveling to conferences in the neighborhood of make believe to talk about waving brooms.

Our call to action is simple, since all we do is

move the rock

Our goals are straight-forward, since we team up to

take it to the house

Our ultimate quest is somewhat elusive – like the meaning of life – nonetheless that doesn’t stop us from trying to

land it on the button

Sidebar

  • The book, written by a very smart and very funny friend and mentor is coming soon to the Pragmatic Bookshelf.
  • The curling competition of the Vancouver 2010 Olympics will be held at the Vancouver Olympic/Paralympic Centre in Vancouver, BC.
  • Curling is on my bucket list.

Scrum Lingua Sustainability

As a marathon finisher (Twin Cities 1998, 2000) and Scrum proponent, I don’t know if Sprint or Jog is a more misleading description of what it is that we do week after week and month after month.

One is unsustainable; the other implies sandbagging. Most of us strive for the sweet spot of pacing and productivity; somewhere between extremes.

The Scrum community needs a term for the zone one slips into during a long run, say more than 10 kilometers, where you’re not conscious of your respiration, you’re not suffering chaffing, yet you are vaguely aware that your body is transporting you over the pavement like a well-oiled machine.

Scrum is a superior way to think about and organize projects. But the Sprint nomenclature is misappropriated. The universal appeal of Scrum is pace and productivity — both humane and sustainable.

Many teams eschew using Sprint to describe what we do in favor of the steadfast Agile term Iteration.

I prefer iteration. It implies convergence toward mutually agreed upon goals.

Those of us who recall using iterative algorithms in Numerical Analysis will remember that convergence isn’t a given, it’s the goal. Convergence requires the right seed values, like the care and feeding of a Scrum team.

Scrum Project Naming

In the Scrum Practitioners Group on LinkedIn, project manager David Koba asked members:

Do you use code names for your projects?

Well, yes. All of us love laugh-out-loud monikers. I still use the cloaking pseudonym Cleatus Spitznoggle when I peruse high school classmates on Classmates.com.

But for Scrum projects, I prefer meaningful names.

One of 10 critical unity factors in cross-functional teams is TEAM IDENTITY. (see my blog post 10 Critical Factors in Cross-Functional Teams).

A well-oiled Scrum team has:

  • Common purpose;
  • Pride in what the team stands for; and
  • Pride in the incremental accomplishments of delivering a superior product.

Since Scrum teams are often comprised of members who initially identify with their functional organization (e.g., Information Technology, Operations, Quality Control, or Marketing), it’s important that the Scrum TEAM IDENTITY evolve over a series of Sprints so that it becomes centered about the product.

I favor project names that promote TEAM IDENTITY centered on the product.

Let the product lead.

I am fortunate to be engaged with a smart group of people building a networking and collaboration product for law professors. We’re the Law School Exchange project.

Our project name is not as memorable as using Star Wars characters like Chewbacca or Biggs Darklighter. And, it is not as intoxicating as a mixed drink project name like The Wet Hen or The Nose Cooler.

On the contrary, our project name suggests a product-focused identity to rally around. It’s a name that doesn’t seem geeky to non-programmers. And, perhaps more importantly, our project name is self-explanatory to the organization footing the bill.

Some folks in the Scrum Practitioners group mentioned the naming of individual Sprints (e.g., after the month they happen to correspond to). Be careful not to lock the team into naming conventions that don’t fit when the team decides that 2-week Sprints are preferable to month-long Sprints.

Take-Away Tips:

  • Give your Scrum Project a self-explanatory, product-focused name that the team can rally around and is easily recognized by the organization.
  • Give your Sprints incremental numbers. Nothing conveys progress to the Stakeholders more succinctly than a trusty old integer.

What’s the SWOT on Scrum?

I was asked for my SWOT analysis of Scrum.

First, I recalled a mark my thesis advisor Otto Strack made on a paper I’d written. He wrote DUA. When asked about the mark Dr. Strack said, “Don’t Use Abbreviations”.

Next, I searched Wikipedia to find that SWOT analysis is a planning method to evaluate Strengths, Weaknesses, Opportunities, and Threats.

I don’t claim to be the Sultan of Swat, but here is my SWOT analysis of Scrum:

Strengths

  • Scrum is product-centric;
  • Incremental progress is easily measurable and clearly visible to business stakeholders;
  • Developers set the pace, are not overworked, and enjoy an increased role;
  • Workload is infinitely adjustable, based on team-set capacity and business-set priorities;
  • Issues are usually uncovered before they become endemic;
  • Team is given authority to make decisions;
  • Team is encouraged to “consult” with business;
  • Tasks tend to be granular, and therefore, more readily testable;
  • Team develops a get-it-done attitude;
  • Team is implicitly encouraged to behave like a start-up; and
  • The approach challenges organizational standards.

Weaknesses

  • Scrum projects without an active Product Owner and without engaged business stakeholders will likely flop;
  • If the Product Owner doesn’t appreciate Scrum, or doesn’t understand the role of Product Owner, success is harder;
  • If the Product Owner doesn’t work with stakeholders to keep backlog full with challenging functionality, developers get complacent and disengaged so productivity goes down;
  • If the Product Owner doesn’t attend to or appreciate technical debt articulated by the team, technical issues can fester;
  • If developers not co-located or within earshot of the Product Owner and business stakeholders, productivity will suffer ;
  • Silo-ing of knowledge can grow if ScrumMaster not attentive and team does not self-correct;
  • Sprint retrospectives are wasteful if team is not forthright and constructively self-critical; and
  • The approach challenges organizational standards.

Opportunities

  • For product-driven organizations, Scrum is a way to revolutionize how you do business. That is, to increase productivity and to inspire commitment;
  • Scrum features demonstrable progress realized through frequent, incremental production releases (Sprints). As such, it is ideal for start-ups trying to attract and maintain investors;

Threats

  • Threats are most likely to emerge from outside the team;
  • Compliance and legal issues in large organizations are always looming (e.g., legal team needs to review content);
  • Security issues in large organizations are big because work product requires a security review;
  • Jealously from non-scrum teams can be a threat;
  • If an organization is not fully “Agile”, or not all using Scrum, there’s a perception that the Scrum team gets to do the best projects.
  • Compensation issues can occur because internal team-members, or contracted team-members, typically do not work for the person giving their salary review or impacting their hourly rate;
  • Revolutionary change does not suit all people in the organization; and
  • Some organizations are not patient enough to realize the advantages of Scrum.

10 Critical Unity Factors in Cross-Functional Teams

At the core of successful Agile software projects are cross-functional and self-organizing teams. How is the “health” of your team?


Executive coaches Emilio De Lia and Ellen Fredericks identify 10 critical unity factors in cross-functional teams in their publication From Cross Purposes to Cooperation.

Below are their 10 critical unity factors along with associated questions posed by the authors (cf. italics). Each unity factor is annotated with observations and commentary from the in-the-trenches perspective of a Agile development teams.

(1) The Customer Factor
What is the team’s relationship to its customers?

In Scrum, the Product Owner is the customer proxy. In most organizations, the “customer” is a large group with diverse interests and agendas. In successful Agile teams, team-members know and understand the customer. The iterative process of planning, prioritizing, and evaluating (e.g., retrospectives) is a rallying force and structure. Ideally, communication between customer and team is not filtered by the interpretation of a middle man (e.g., a business analyst’s interpretation of requirements).

(2) The Engagement Factor
Does the team engage its members to the level necessary for the team to succeed?

Disengagement characterizes a dysfunctional team. All members must be satisfied their talents and strengths are used. Agile teams benefit from drafting a “development manifesto” at the outset of the project that outlines what is expected of the team. Architectural choices, coding practices, and standards are decisions made by team consensus. Team-members must share ownership and accountability.

(3) The Identity Factor
How strong is the team’s identity?

A well-oiled Agile team has a common purpose, is proud of what the team stands for, and is proud of the team’s incremental accomplishments delivering a product. Agile teams are often comprised of members who initially identify with their functional organization in the larger corporate hierarchy. Over time, this identity must evolve so that it is centered about and focused on the product (e.g., The Virtual Widget Team is an identity based on a product called the Virtual Widget). Building team identity around common purpose inevitably generates engagement and passion.

(4) The Behavior Factor
Does the team exhibit constructive norms and behaviors?

In a well-oiled Agile team, team members respect and abide by agreed upon behaviors detailed in the developer manifesto. Some teams explicitly try to root out the silo-ing of knowledge by distributing tasks accordingly. The team strives for this behavior and praises themselves for demonstrating it. High-performing Agile teams will self-correct destructive behavior. For example, one team member might suggest a paired-programming session to shine a light on something going badly, rather than continuing on a solo path “off into the weeds”. Sprint retrospectives are often the best forum for evaluating, and self-correcting, destructive behaviors (e.g., gossip, technical cliques, blaming, withdrawing, or complaining).

(5) The Plan Factor
Does the team have a clearly defined plan of action that its members believe in?

Iteration planning (or Sprint planning in Scrum) typically has well-defined steps of indentifying stories, prioritizing stories, tasking stories, and generating estimates around the tasks. Many teams go the extra distance of “talking in tests”. That is, each story (or task) has a list of tests that constitute “completion” of that story (or task). When successful, good planning yields a clear plan of action.

(6) The Process Factor
How effectively does the team communicate and make decisions?

Agile teams must establish trust amongst members. Trust enables members to discuss sensitive subjects and to make controversial decisions in a way that is satisfying to the group. Team-members must be able to subjugate ego and ask for help when needed. Team-members must understand each other’s strengths and weaknesses. They must act in each other’s best interest. The decision-making process should be simple and actionable (e.g., who, what, when, and how). Consensus vote is the preferred approach to decision-making because it generates the greatest participation.

(7) The Function Factor
How are the team’s efforts integrated into the functional organization?

Some of the biggest challenges are the demands and constraints of the hierarchical organizations outside of an Agile team. Ideally, Agile teams behave like startup companies. That is, it is a flat organization where team-members wear multiple hats and responsibilities are equitably distributed. Institutional inertia and institutional controls outside of the team can often hamper team velocity. How does the team deal with these impediments and road-blocks? A ScrumMaster is often the person called upon to buffer the members from the counter-productive bureaucracy threatening the team.

(8) The Feedback Factor
How is performance evaluated and rewarded?

Agile teams have an end-of-iteration show-and-tell followed by a retrospective. This is a time where stock is taken of accomplishments, feedback is provided by the Product Owner, and the team looks back retrospectively to determine “what worked”, “what didn’t work”, and “what action items” are needed to improve.

(9) The Responsibility Factor
What level of responsibility and commitment do members of the team demonstrate?

The daily Scrum makes responsibility and commitment difficult to shirk. Scrum or stand-ups require each member publically and succinctly state what he accomplished yesterday, followed by a declaration of what he’ll accomplish today. Many teams assign story “ownership” to developers. While they might not work any tasks attached to the story, the “Story Owners” are responsible for shepherding the story to sign-off by the Product Owner.

(10) The Self-Interest Factor
Do team members see personal advantages to working on the team?

In high-performing Agile teams, individuals value the personal payoff (e.g., “I’m learning new things” or “I’m getting kudos from my teammates”). Furthermore, each member is proud of his contribution. The artifacts of personal payoff and pride in craftsmanship are easy to smoke out in the end-of-iteration show-and-tell or in the retrospective.

De Lia and Fredericks also provide a cross-functional team scorecard called TRUID. TRUID is an evaluation checklist that establishes a relative measure of how well your team is functioning as a team.

These 10 critical unity factors will help evaluate the “health” an Agile team and perhaps provide a basis for self-correction.