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.

Trust, the Product Owner, and the Team

Posted on by

KnotWe are currently working on a consumer software product named Ript. I feel extremely lucky to be a part of this project as does every member of my team.

If there is a single reason for this sentiment it is the deep collaboration between our product owner and the development team.

The Manifesto for Agile Software Development asks us to value:

Customer collaboration over contract negotiation

Contract negotiation within a single organization arises in conditions of low trust. One or both parties feel they need to explicitly document expectations to protect themselves.

A low trust environment is Hobbes state of nature as practiced by the software industry. Promises are prized more than outcomes. Authority and responsibility don’t reside in the same person. Incentives are not linked to outcomes. Blame brings more consequences than failure. Success is virtually impossible. Agile practices if they can be adopted at all are simply a mechanism for failing fast which has the virtue of saving the company money and sending talented people off to hopefully more rewarding jobs at other organizations.

Rising above this coding purgatory is an organization with some mutuality of sentiment and interest. A capable development team exists and business owners are both empowered and accountable. Here the organization can aspire to partnership.

But not all collaboration is equal.

In What’s Worth Fighting for Out There?, Andy Hargreaves and Michael Fullan describe the concept of bounded collaboration:

Bounded collaboration rarely reaches deep down to the grounds, the principles or the ethics of practice. It can get stuck with the more comfortable business of advice giving, trick trading and material sharing of a more immediate, specific and technical nature. Such collaboration does not extend beyond particular units of work or subjects of study to the wider purpose and value of what is taught and how. It is collaboration, which focuses on the immediate, the short-term and the practical to the exclusion of longer term planning concern.

This concept is applicable to the software setting which, like learning, is fundamentally about knowledge creation and sharing.

Bounded collaboration exists in software when the developers do not invest themselves in the business outcome of a project. This can occur through no fault of their own if the plan is vague, not shared with them, or if their input is not invited or listened to. Some managers simply don’t consider it important that technical staff buy into the vision or features of the software they’re building.

In such situations, developers shut off part of their brains. (for those of us who love our craft, a more apt description is cauterize part of our brains)

“I’m not personally invested in the business plan or priorities but I will execute on them as you (product owner) define it. Since I have no authority or meaningful influence on the plan or priorities, as long as I produce reasonably error-free code I refuse to be judged by how the product fairs in the marketplace.”

Scrum allows for success on these terms by assigning responsibility for the business outcome to the product owner and technical execution to the team. If the product owner has a thoughtful strategy and deep insight into their customers a well-executed piece of software stands a chance.

But what price does an organization pay for bounded collaboration?

Knowledge Creating CompanyInnovation – A company that does not engage fully with its workers diminishes its ability to think deeply about a problem and to surprise itself with unexpected solutions. It therefore fails to be what Ikujiro Nonaka and Hirotaka Takeuchi describe as a Knowledge Creating Company that can sustain success through its own invention.

A television company building consumer software – that’s audacious!

Our product owner is our CEO, Gerry Laybourne. This initiative is her idea but she partnered with the development team to craft the concept and feature set for our first consumer product, Ript.

Gerry has allowed us to fall in love with the project by leading us while listening to us. She’s given us the gift of high expectations demanding that the product be original, useful, and fun. She’s treated us as peers despite the fact she holds much more authority than we do. She’s shared her excitement for the product while sharing credit for it. She’s championed her priorities while allowing us to question any and all aspects of the product. We’ve both had the pleasant experience of disagreeing and realizing the other was right.

Yes, the product owner is the single wringable neck – she’s championing an entirely new line of business at her company – but I’ve never seen a team fight so hard to get in the noose with her. That’s trust.

To quote Jeff Sutherland, “Great scrums require great product owners.”

Building a Reputation

Posted on by

DonXml has a review of NYC Code Camp presentations by three of our team: Oksana Udovitska, Wendy Friedlander, and Luke Melia.

But besides being a media outlet for women, Oxygen has been building up a reputation in the Agile community, especially in NYC. So, I was very pleased to hear that they were presenting 3 sessions at the NYC Code Camp …

Meet the Parents

Posted on by

The Yellow KidI met my wife, Kathie, eleven years ago. I was stage managing The Yellow Kid by Brian Faker and Bliss Kolb at Annex Theatre. Kathie was in the cast.

The Yellow Kid had 27 actors, 200 slide projections, film, rolling scenery, a cat, two dogs, and a goat named Julia. The second act was so tightly choreographed that I couldn’t call cues from the script but had to mark them off elapsed time in the music. Twenty second light fades timed to images, sound, scene changes and stage action. Moments as beautiful as any I’ve ever seen. All this on a production budget of $1100 for a non-profit fringe theater with a $100K annual budget. Big cheap theater.

Sometime later, Kathie’s sister was visiting. We decided to drive the twelve hours and three mountain passes to their parent’s home in Montana.

HandsetMy wife’s career evokes the phrase “odd jobs”: deck hand, national park employee, clown in a Japanese, Dutch theme park, congressional staffer and temp. Two days before we left, Kathie had a telemarketing injury. I don’t know if she was gesturing with the handset or so bored she was trying to escape through the mic holes. In any case, the receiver slipped and hit her eye so hard it bruised.

I was about to meet my future wife’s parents for the first time and it looked like I’d punched her in the face.

Snoqualmie Pass

© 2004. Mountains to Sound Greenway Trust.

We headed off towards Snoqualmie Pass. Kathie’s car was a ten year old hatchback that had made the trip from Seattle to Montana many times. At the top of the pass (3022 ft) the car just stopped. I don’t know what an electronic control module is but when it fails a car turns into statue.

It was a spring afternoon and the weather was mild. I had a cell phone (a bit of a luxury in 1996 for a fringe theater dude with a day job) and a AAA membership. I called for help. I hear at this point my future sister-in-law decided I was a keeper. AAA warned me that the tow truck was only allowed to carry two passengers. I was polite, rule obeying, and conflict avoiding so I called my dad for a pickup.

The tow truck arrived. Of course the driver said he could squeeze me in but I’d already called my father. Seattle is 52 miles from the summit. Assuming I’d see my own ride within the hour, I sent my future wife, my future sister in-law, the dead car and my potential rescuer on their way.

I didn’t know it but I had interrupted my father while he was painting his porch. Afraid that stopping would wreck the paint job, he had decided to finish and clean up before heading up for me. As the tow truck pulled away, he was probably still on a ladder doing edge work.

So there I was. I waited. I waited some more. After a while I began to feel a little vulnerable. Sure, some crazy could pull over and use me for fixin’s. What really began to grind me was that I looked so stupid standing there that people would start pulling over out of pity. I looked like one of those people who just wander off. Like I’d gotten so fed up with my desk job that I’d just stood up and started walking East to – I don’t know – Walla Walla.

Embarrassment became the better part of valor. I noticed that if I crouched down at the side of the road I could see the cars with less chance that they’d see me. A great way for a thirty year old man to pass the time — hiding from traffic in a ditch at 3000 feet above sea level.

I waited there for over two hours before finally seeing my father’s car.

I rode back to Seattle relieved. Relieved Kathie and her sister were safe, relieved my father had finally picked me up and most of all relieved that the trip was canceled and I didn’t have to explain to my future in-laws why their daughter had a black eye.

Context Switching

Posted on by

My team is currently working on two very different programs by pulling work off both backlogs into a single sprint. We did this for pragmatic reasons having to do with our size and the wishes of both the product owners and the team. This was working well when the two programs were clearly defined projects. However, we’re going through a rough patch with one program driving maintenance work and the other rallying towards release. We’re paying a price for context switching with lower point commitments overall per sprint.

Inspect and adapt.

The Washington Post published an article by Lori Aratani, Teens Can Multitask, But What Are Costs?

When subjects were focused on sorting, the hippocampus — the part of the brain responsible for storing and recalling information — was engaged. But when they were multitasking, that part of the brain was quiet and the part of the brain used to master repetitive skills — the striatum — was active.

The Journal of Experimental Psychology published a paper by Joshua S. Rubinstein, David E. Meyer, and Jeffrey E. Evans on Executive Control of Cognitive Processes in Task Switching. As an APA release summarizes:

…subjects lost time when they had to switch from one task to another, and time costs increased with the complexity of the tasks, so it took significantly longer to switch between more complex tasks. Time costs also were greater when subjects switched to tasks that were relatively unfamiliar.

Neither the article or paper distinguish results by gender. The First Sex says that according to gender specific studies women are better multi-taskers than men.

I bring up the gender differences because I work at a women-owned company. One of the benefits is seeing the world from my CEO’s point of view. Sometimes not identifying differences between men and women denies women opportunities, or worse, perpetuates harmful stereotypes. As a society, we are late to acknowledge that women present with heart disease differently than men. This has perpetuated a myth that heart disease is a male illness.

“(A)ccording to the American Heart Association (AHA), more women than men die from heart disease in the U.S., and 1 in 3 women is living with it today” – TIME Magazine

If women are truly better multitaskers, maybe they have some inherent advantages in certain kinds of jobs (like mine 🙂 ).

Both the men and women developers in my team have acknowledged that the context switching penalty has gotten worse recently. So whatever the difference in this case, some kind of scrum master response is required.

Learning Culture

Posted on by

Miya in the Park
Three of our team are participating in this year’s NYC CodeCamp. Luke Melia is presenting Supercharging the WPF Command Pattern with Dependency Injection. Wendy Friedlander and Oksana Udovitska are presenting The Gentle Art of Pair Programming and Testing in C# with RhinoMocks.

I’ve always wanted to build a learning culture. Before embracing agile principles, we had a hard time fulfilling this aspiration. In retrospect, our definition of the developer role and what constituted success in that role was too narrow. Intensive classes on specific topics don’t suit many learning styles and there was no direct connection between a broader scope of learning and project outcomes.

Scrum and XP require continual improvement. They encourage reflection, engage a broad range of social and intellectual intelligences and tie those abilities to project success. They place you in a larger ecology of peers and mentors.

People striving to make a contribution love learning.