Author Archives: Ken Judy

About Ken Judy

I am an executive leader, software developer, father and husband trying to do more good than harm. I am an agile practitioner. I say this fully aware I say nothing. Sold as a tool to solve problems, agile is more a set of principles that encourage us to confront problems. Broad adoption of the jargon has not resulted in wide embrace of these principles. I strive to create material and human good by respecting co-workers, telling truth to employers, improving my skills, and caring for the people affected by the software I help build.

More Remoting At Oxygen

Posted on by

Remoting At Oxygen made with Ript

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.

Just do it!

Posted on by

Just Do It by kjudy

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.