My company begins planning its integration into a new parent organization.

As a participant in that process I have to obey:

1. Laws and policies.
2. My duty as an executive to create strategic value.
3. My duty as a manager to treat my team humanely and fairly.

I feel other ties:

1. Guiding my actions according to ethical values and agile principles.
2. Loyalty to my boss — he’s created opportunities for me. I owe him.
3. Loyalty to my departing CEO — she is a visionary and a mentor. I can’t wait to see what she does next.

These obligations may contend but should not fundamentally conflict as long as the integration plan we develop clearly communicates an achievable, rational outcome.

“Above all, to thine own self be true.” — Hamlet, I, iii

Inspiring and daunting advice but not to be taken at face value. For the character who delivers it has too high a regard for his own ingenuity, places himself at the center of events and meets a bad end. A creation as complex as life.

I will try to heed a fool’s words without becoming a fool. To be true to mine own self in this circumstance is not to delude myself that this situation is in any significant way about me. Options that don’t make business sense will not serve the long-term interest of anyone involved. My obligation is to work towards the best outcome for all parties given that reality.

Posted: October 16th, 2007 under Uncategorized.
Comments: none

John Maeda on leading and managing and the need to do both.

The manager sets up the win with perfection for her team; the leader executes the win with passion.

The word “perfection” conveys discipline but the agile practitioner in me bridles at it. As John Maeda says, “a manager never manages alone.” Community defies perfection.

I do resolve to do better. Do by committing myself to action employing the most appropriate knowledge and tools at hand. Better by using the hard lessons of success and failure to make my actions more effective the next time.

Posted: October 14th, 2007 under Uncategorized.
Comments: none

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.

Posted: September 30th, 2007 under Uncategorized.
Comments: 1

Embracing planning assumptions as more real than what people and products are actually delivering — from Jim Highsmith.

It’s like driving into a river because your GPS tells you to.

Note: Jim Highsmith’s challenge of the CHAOS study and defining success as on time, on budget, and as originally specified.

Posted: September 29th, 2007 under Uncategorized.
Comments: none

Sweet and simple. http://weblogs.media.mit.edu/SIMPLICITY/archives/000456.html

Posted: September 20th, 2007 under Uncategorized.
Comments: 1

These are candid shots from this week’s Sprint review (full size image).

One of our team, Wendy, often works from home. We use webcams, skype, community document formats and remote access. She even has her own build bunny.

As you can see, we’ve developed the habit of giving Wendy a view of the action however absurd or precarious it looks.

Remoting does limit beneficial cross-talk among the pairs (osmotic communication) but word within the team is that pairing goes well. After some practice, we’re also getting the hang of the structured group conversations such as standup, sprint review and planning.

We have a strong, established bond with Wendy and the team is really pulling to make it work. She also comes into the office at least once a week which keeps us close. All and all, it’s about the easiest remote worker scenario I can think of.

The biggest downside is simply that we miss her.

Posted: September 18th, 2007 under Uncategorized.
Comments: none

I laughed out loud when I saw Ken Schwaber titled a passage of his book, The Enterprise and Scrum, “Just Do It”.

Ken describes how a customer can sacrifice quality and sustainable pace in the short term but pay it back at a premium, “$4 to remediate every $1 drop in quality.”

Clearly there are pressing bugs, misses and serendipitous opportunities. There are times to inject work into a sprint backlog. There are even times to “stop the line” and reset a sprint.

But when you manage a self-directed team, “just do it” — and I’ve heard that very phrase — is bullshit.

Just characterizes another person’s work as easy. It is the people performing work that need to estimate it. They are on the hook to execute and are incented to think critically in detail about what they are taking on. The worker grasps the actual effort better than the executive.

Do characterizes the work as physical action. Software development is problem solving and abstract modeling, i.e. knowledge work. “I’m typing as fast as I can?!” Even industrial lean practice relies on workers engaging beyond the boundaries of the immediate task to improve the product and the process of manufacture.

It characterizes the work as a single, clearly defined task. Again, the person doing the work determines whether they clearly understand assignment. Otherwise, you’re not admitting to any ambiguity of language, hidden complexity, or potential misunderstandings.

Just do it is a one way directive that splits responsibility from authority, i.e. YOU just do it. It signals a leader is not willing to do their part to remove obstacles for their team.

Just do it hides inefficiency under a veneer of necessity. Is it a surprise that “just do it” finds companionship with “just the way things are done” and “just the nature of the business”?

All this to say “just do it” in knowledge work is bullshit. The value lies not in the truth or falsity of the statement but the effect it has on the hearer. It dismisses workers’ concerns and excuses management from accountability.

Moving from bulls to birds, if self-directed teams are the goose that lays golden eggs, “just do it” is a pellet blast in the ole’ egg layer.

Posted: September 16th, 2007 under scrum.
Comments: 4

It’s a privilege to be granted authority in another person’s company.

It’s easy to criticize. It’s hard to raise capital and make payroll.

I have never been an entrepreneur. My passion is to build teams. To be of service. To make things better.

I’m that second generation that feeds off founding vision and hopes to sustain an organization.

This has been a good week.

• We achieved our first business objective on our standard bearing product initiative, Ript™.
• My CEO is championing agile values in my division’s executive team – accountability to specific commitments within a time box.
• Managers in a peer group recognize the potential of self-directed, cross-functional teams and are interested in introducing the first scrum outside my department.

I am a cautious optimist. Success is far from inevitable. Actually, all this represents is an opportunity to start the really hard work.

Still some moments, especially ones years in the making, need to be savored.

Posted: September 14th, 2007 under scrum.
Comments: none

I’m half-Japanese but my wife introduced me to Anpanman by Takashi (嵩) Yanase (柳瀬).

I can’t give any better description than the Japanese Media Communication website:

“Anpanman will go anywhere to help anyone in trouble, to drive away villains, and to save people from starvation by allowing them to eat his face.”

“Anpanman is the hero of the new age, glowing with friendship, endeavor and justice.”

Posted: September 10th, 2007 under scrum.
Comments: 1

I’ve posted about why I need to encourage agile practices outside my department.

If Scrum is isolated within one team, its very success can be used to counter further adoption. “Agile works for you but what we do is different. You do X we do Y.”

This resistance is a direct result of what Andy Hargreaves calls balkanization — groups insulated from each other, with hard boundaries, loyalties and a political complexion.

Creating a culture where groups work together to improve the organization is core to lean and agile. So the best ways to counter balkanization are the very principles under challenge.

I’m tackling this top-down by lobbying senior executives to bring in an agile/lean coach, bottom-up by removing impediments for my team, and, perhaps most significantly, sideways by initiating a Scrum in another department.

I have tentative approval from another department’s senior managers. Now, I have to meet with line managers and identify a backlog of work. Then solicit volunteers for a team.

I’ve taken Ken Schwaber‘s words to heart and asked them to Scrum their hardest challenge or the work they think least suited to agile.

So many things can go wrong. Of course, nothing that isn’t already going wrong. That’s the point.

Scrum will highlight those problems and make solving them obvious and necessary if no easier.

More to come…

Posted: September 9th, 2007 under scrum.
Comments: none