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.

The Opposite of Agile

Posted on by

NYC settle a lawsuit to compensate poor families for food stamps they were denied by mistake beginning in 1999…

…as many as 34,000 families could have been affected, with the settlement ranging from $8 million to $71 million depending on how many people were involved. The city has said that it corrected the computer problem several years ago — NY Times

  • Make mistake effecting food for poor families.
  • Correct mistake approx. 5 years later.
  • Acknowledge mistake 8 years later.
  • Blame others but retain liability.

WNYC story

Focus and Variety

Posted on by

BlurCoaster by Kjudy

We have seven developers growing to eight. The team is funded from two P&L’s so from the outside we’re considered two teams. We work on two projects at a time, one from each P&L.

We used to run one backlog with developers pulling stories from either project. In the sweet spot where both projects ran smoothly this was great. But that proved short-lived. Churn in one project slowed the other and context switching took a toll on the team.

So we split the work into two backlogs. Everyone sits in the same room but developers are “assigned” to one project. As a side note, I actually planned on having two rooms but the team said “no”.

This change has created more focus. Developers know what they’re working on, churn in one project has less effect on the other. The Scrum is easier to run, plan and track and progress appears more regular.

The change is a qualified success. Four may be too small for sustainable pairing. If anyone goes on vacation or is sick, the pairing practice starts to break altogether.

So to retain the focus of two small teams but gain the benefits one slightly larger one, we’ve loosened the assignments. Developers are asked to work on a specific project but they can switch if they feel the hate. The leads can switch people as well.

Management is often about embracing contradiction. We need to find our way to both variety and focus. It’s all a work in progress.

Complex Interactions

Posted on by

Blackberry 8830

Last night, my phone drained.

This morning, I recharged it. The phone came back. The SD Micro card did not.

Unrecoverable. Impossible to reformat. Dead.

Why didn’t the card power down safely?

What was my phone up to at 4AM?

Scrum without XP?

Posted on by

My team built an XP practice before introducing Scrum. The desire for change arose within the developers and was about sharing, becoming better at our craft and making our productivity and quality more consistent.

Scrum became necessary when our biggest problems were no longer within the team but in how we took on work from the business.

I started thinking about that at the last XTC-NYC when Mike Roberts wondered aloud if Scrum software development can work when a team doesn’t practice at least some aspects of XP. In a similar vein, Scott Bellware has a post about XP deserving more credit for Scrum’s success.

At XP-Spin, Jeff Sutherland said the success you build on is delivering working code at the end of each iteration. To even begin you need work described in achievable stories with acceptance criteria and daily builds.

Oxygen Standup

Mike and Scott are definitely right when I look at my team.

Our present challenge is aligning our development with a clear and achievable business objective. Scrum is the tool for that. One of the things about Scrum is that you can use it for almost any kind of work requiring cross-functional teams.

But that challenge only exists because we were highly productive at creating quality software. The team’s XP practice with its low formality and high discipline gets the credit for that.