This is what unrealistic planning does to execution.

Here’s the scenario:

Management adopts a project plan with unachievable goals given the time, features and resources.

The team begins in ignorance of “the plan”. Initial progress represents a sustainable pace.

Visible progress doesn’t match “the plan”. Management pressures the team. Short term, the red line gets steeper.

At this point, management revises the plan adjusting the start but retaining aggressive assumptions. “Now we know what we’re doing!”

Problem is, the productivity gain is not sustainable. The team is working extra hours and skipping necessary work to declare things done.

Problem is, the productivity gain is not real. Under stress the team works to increase the measure of value instead of value itself.

So productivity stalls. The team catches up on sleep, settles into the slog, and confronts thorny problems created by messy, incomplete and untested code.

Ultimately, the team produces less than had it maintained a sustainable pace.

Assuming the people and codebase aren’t hopeless, I added a period before the end where the team returns to sustainable pace. These are the tragic days when management gives up and before they cancel.

Another scenario – similar chart:

Management adopts a business plan with unachievable goals.

The product owner becomes risk averse or fool hearty, ignoring real opportunities that won’t hit impossible numbers.

The product drifts or lurches in bizarre directions and declines.

Short link: http://jkat.me/iiQltv

Tag(s): agile, management, product owner

Comments: 1

I have to admit to some confusion over the verb forms of affect and effect. The free dictionary has this helpful note:

Affect and effect have no senses in common. As a verb affect is most commonly used in the sense of “to influence” (how smoking affects health). Effect means “to bring about or execute”: layoffs designed to effect savings. Thus the sentence These measures may affect savings could imply that the measures may reduce savings that have already been realized, whereas These measures may effect savings implies that the measures will cause new savings to come about.

So an agilist should effect positive change not affect it and affect impediments not effect them.

Short link: http://jkat.me/iecJhG

Tag(s): agile

Comments: none

At the precipice of change, we are getting sentimental here at the Oh! Network.

As a developer joining Oxygen NY in 2001, I entered a code and fix culture under a facade of waterfall planning. I fought arbitrary dates, bloated specifications, and reality-challenged reporting. I acquired a survivalist’s skill for landing valuable projects and picking co-workers who helped carry them to completion.

As team lead, I made myself project manager. I used a risk-managed, iterative approach based on Steven McConnell’s Software Project Survival Guide and Earned Value Planning. We provided transparency, met dates and exceeding expectations.

Still, I had the awful, lonely feeling it was unsustainable. A tiny team, we were isolated from each other. We needed a collaborative practice. We needed to share knowledge, commit to a common way of working, and lift each other past our individual limitations.

I found the following e-mail thread capturing the moment we adopted Extreme Programming (XP). A bit of everyman’s history with a very small ‘h’…

From: Ken Judy
Sent: Tuesday, January 13, 2004 2:40 PM
To: Luke Melia; Kristofor Selden
Cc: Steve Morgan
Subject: Agile Methodologies

Here are sites for different agile methodologies. Of the five of them, XP is the most exacting. The others are generally light frameworks for ways of developing or managing projects that support the agile manifesto http://agilemanifesto.org/.

XP: http://www.extremeprogramming.org/
Scrum: http://www.controlchaos.com/
Crystal: http://alistair.cockburn.us/crystal/crystal.html
Adaptive Software Development: http://www.jimhighsmith.com/
Feature Driven Dev: http://www.featuredrivendevelopment.com/

– Ken

From: Luke Melia
Sent: Wednesday, January 14, 2004 5:09 PM
To: Ken Judy; Kristofor Selden
Cc: Keith Frank
Subject: RE: teamwork

Hi Ken,

Kris and I spent some time today reviewing the agile process frameworks you sent around and met this afternoon to discuss our planning. We’re going to follow the XP rules and practices for the most part.

http://www.extremeprogramming.org/rules.html

We will likely invest somewhat more effort in up-front detailed requirements in order to support your work-package tracking efforts. In addition, some practices are irrelevant for a team consisting of a single pair of developers. We’ll ignore those and pay close attention to the practice “Fix XP when it breaks” in order to arrive at a set of practices that is effective for us. I’ve read the criticisms of XP that argue it is “all or nothing” but I feel that this approach will work for us.

We’re going to be pair programming and plan to work together 11am – 1pm and 2:30 – 5pm. This will allow us time at the beginning, middle & end of the day to respond to email, etc.

This is all going to start this Friday. On Friday, we’ll do a code review, go over the task breakdown for the SES project and plan for our first milestone, as you suggested. I’m also going to rearrange my desk to make it work better for two people to sit at.

Luke

From: Ken Judy
Sent: Wednesday, January 14, 2004 5:31 PM
To: Luke Melia; Kristofor Selden
Cc: Steve Morgan
Subject: RE: teamwork

Sounds good. Our team is so small that a strong agile approach should work well as long as we manage risks. I’ll look into the “Tracker” role in the XP model to see how to adjust my tools to your approach.

– Ken

From: Ken Judy
Sent: Thursday, January 15, 2004 10:33 AM
To: Luke Melia; Kristofor Selden
Subject: RE: teamwork

Hi,

Please go ahead and block out 11:00am-1pm and 2:30-5pm in your calendars as “busy”. I’ll send out an e-mail to IS all so they know what’s up. Feel free to decline any meeting requests at your discretion and let me know of anything in your calendars you need me to cover for you on.

We will need to start the morning “standup” meetings so that we keep focus on the project and one of the things we’ll need to address is how to best use Michele as owner.

– Ken

Short link: http://jkat.me/eqQJ2V

Tag(s): agile, Keith Frank, Ken Judy, Kristofor Selden, Luke Melia, management, project manager, Steve Morgan, Steven McConnell, xp

Comments: none

My 2nd grade daughter earned a place on her school’s FIRST LEGO League (FLL) Robotics team.

“You were chosen based on your ability to work well with your team during tryouts and how well you cooperated with others.

We also looked at your ability to problem solve, on your own and within the group, your endurance with the task, your ability to follow directions, and your handle and care for the pieces, as well as your overall interest and enthusiasm for robotics and the task at hand.”

What a great description of collaborative development! I’m so freakin’ proud.

FIRST is Dean Kamen’s foundation “to create a world where science and technology are celebrated… where young people dream of becoming science and technology heroes”

Short link: http://jkat.me/hEGU4q

Tag(s): agile, Dean Kamen, FIRST LEGO League, technology heroes

Comments: 2

A chain of direct and “dotted line” reporting that makes a worker accountable to many managers with no clear boss.

A near total separation of authority and responsibility. The worker is always at fault but overworked and excused. The communication overhead justifies creating more managers.

Related Anti-Pattern: Value Stream Backwash where analysts specify more projects than workers have capacity to deliver. Again, often solved with more analysts.

Short link: http://jkat.me/ggBb7Q

Tag(s): agile, anti-pattern, Inverted Org A

Comments: 1