I posted how Anpanman by Takashi (嵩) Yanase (柳瀬) is my role model. Turns out John Maeda has similar sentiments.

What a noble aspiration to act under the belief, “That if you had more you could always get by with less.” One I find very hard to live up to.

In the workplace, I hate to assume responsibility for decisions I did not make. I’m not talking about anything illegal. I’m talking about the daily harms people inflict on others — particularly those over whom they hold power.

There is an industry around how to confront such situations but let’s admit there are people and events we cannot change.

Having no participation or influence over the decision, I want to stay out of it.

But as a human being of good will I have to acknowledge harm and live with my action or inaction in the face of it.

So what can you do when you have no means within your role or recourse to outside authority?

Consider the person and respond as an individual. Give of your personal time and resources.

I aspire to this and very often fall short. But I am challenged and inspired by an absurd and beautiful Japanese children’s character.

I am also inspired by the actions of others including my wife, Kathie, my former employer, Peter, and my friend and co-worker, Luke. Small, extraordinary acts of good will by good people.

Posted: November 23rd, 2007 under Uncategorized.
Comments: none

NBC Universal has completed its acquisition of Oxygen Media, my employer for the last eight years.

in·te·gra·tion: “incorporation as equals into society or an organization of individuals of different groups” - Websters Dictionary

During the past month, we participated in an integration process. A good faith effort by NBCU staff to assess where value lies in Oxygen’s practices and people.

Our team is composed of talented individuals. Marketable individuals may integrate or “dis-integrate” for other opportunities.

What is potentially more enduring yet difficult to discern are the values, practices, esprit and reputation that allow this team to attract and develop new talent even as individuals move on.

However, there is a relentless necessity to “incorporating as equals into an organization of individuals of different groups.” It focuses on individuals and organizations not groups. Citizens and cities - not neighborhoods.

In this process, from both the acquirer and the acquired, the team has suffered. We haven’t been rewarded or treated as one but as individuals in service of organizations. To bastardize Benjamin Franklin, as we hang separately we clearly do not hang together.

This fact, in and of itself, is a great loss.

And so as different constituencies gather at NBCU, we await change. Whatever that change is, for me it will involve building something new.

Posted: November 22nd, 2007 under Uncategorized.
Comments: 1

John Maeda has another post on leadership.

“In movies we often see two scenarios: 1) the leader is surrounded by her soldiers as a wall of protection; or 2) the leader is the one that is the first to rush into battle.”

I have trouble with war metaphors in a time of war but I get that success is built upon both protecting potential and creating it.

This sentiment reminds me of Garry Kasparov’s description of his chess play, attacking, aggressive, “where the player who makes the first mistake loses” versus a maneuvering, defensive style that “accumulates small advantages over time.”

I have played the latter, quiet game, advancing through various roles and towards an agile organization over years.

My game was winning over peers, demonstrating success, removing many obstacles and flowing past others, educating executives as they became receptive to it, and, above all, showing by doing — proving value on our terms by delivering value.

But as Mr. Kasparov points out, circumstances may require us to adopt alternative styles and I am clearly in that situation now.

My company may soon be integrated into a larger one. In that larger organization, I have met conscientious, competent people. If the acquisition goes through, they will work to realize as much benefit as possible while managing risks and minimizing harm.

However, drastic change will need to happen in a short time and there are three very different cultures at play: that of our team, our current employer and our prospective new one.

Time is a factor in another way as well. My team cannot endure setting the clock back on our product and software development practices. Agile development means little unless it is in partnership with an agile business. We don’t want to just build things well. We need to invent, serve users and win in the marketplace. We need it all.

If circumstances call for a more pressing style of play. So be it.

Posted: November 6th, 2007 under Uncategorized.
Comments: 2

I was recently asked the following question:

“I’ve been dropped into a situation best described as “story card hell.” How do I reduce complexity of the software project planning without losing features?”

The project was to replace an existing system. The behavior was largely known. As a result, the initial planning generated enough cards to feel like, “way too much detail up front.”

My answer:

Don’t lose the work you’ve done but don’t place more value in it than it has.

Step back to think of the application as a phased set of releases. Talk with the team and product owner about a way of delivering the system in meaningful pieces that customers could (and hopefully will) use. Get creative with defining those steps as long as they lead you down a path towards your ultimate goal.

Once you have that road map. Do an exercise with the team to group your existing stories into those releases. There will be a natural tendency to add and change stories. That’s fine but don’t get too distracted by it. The main point is to get a sense of the relative size of the releases and move the bulk of the stories out of your immediate planning concern.

Now focus on the first release. Spend more time on those stories but still not with the scrutiny of an iteration plan. Make/allow the team to live with ambiguity. Set up an agreed upon rule of thumb for how much bigger a “theme” is from a real “story” and let the team know it’s okay to discuss these things at the “theme” level.

Then prioritize your release backlog. Have the team chunk the remaining vague stories/themes into future iterations for that release. This is your release plan. Expect it to change. Again, you’re getting a rough sense of how many iterations in the first release and moving later stories out of your immediate concern.

Now you can focus in detail on the stories for the next one or two iterations without getting drowned in details. Don’t be surprised if future stories become irrelevant or drastically change as you get to the iteration within which they fall. It’s okay.

My answer was based on what we’ve tried to do at Oxygen with coaching on release planning from Hubert Smits.

Here’s the full thread off LinkedIn.

Posted: October 31st, 2007 under scrum.
Comments: none

At Oxygen, we have a team.

Building this team has been the collaborative work of years.

Our CTO, Steve, made IT a strategic asset and championed a seat at the table for software development. I introduced agile principles, carved out space for agile development practices and built a product team.

Our dev director, Luke, and coach, Kris, built a disciplined XP practice. Our product team, Ilio and Suzann, and our Scrum master, Salim, built our Scrum practice.

With Luke’s lead, the team built itself by adding exceptional talents and engaging human beings. Wendy, Oksana, Lee, Robert, Daniel and our first UX Designer, Bob. Each brings experiences, specialties, passions and humor that spurs creativity in our products and simplicity, quality, and expressiveness in their underlying implementation.

For the last year, our team has included our CEO, Gerry, an inspiring and audacious product owner.

Over almost eight years together, the core of us struggled through bad practices and mediocre projects. We taught ourselves better methods and brought in great talent providing the best fit. We grew, we availed ourselves of experienced coaches, we matured, we hit our stride. Now we contribute to our field through open code, writing, presentations and mentoring.

This team is a competitive advantage. We share values, practices, and history. We have complimentary strengths, camaraderie and spirit. We are inventive, versatile and fast on our feet. Our dedication to each other is our strongest retention and recruiting tool.

I care for these individuals and I love the team we’ve created.

Posted: October 22nd, 2007 under Uncategorized.
Comments: 1

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

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

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