Scrum, XP, Management and the Ethics of Agile Software Development

Learning Culture

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.

Building a Reputation

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

The Day Oxygen Became Extreme

Extreme What? by Justin DonnellyAt 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

The Scrum Master’s Dilemma

My daughter Miya and dog friend Sophie 2002 by kjudy

A metaphor for the Scrum Master is a vigilant sheepdog protecting their flock.

At the Fall Scrum Gathering, I met practitioners facing different challenges in their agile practice.

Some faced profound impediments that their organizations were unable or unwilling to address. The effect on the project and team was dire and the Scrum Master had exhausted all avenues to raise alarm.

It’s human nature, unfortunately, to associate an unpleasant message with the messenger. A vocal Scrum Master can be seen as the problem.

In those fraught circumstances a Scrum Master has to balance the interests of the team, the company and themselves. Can the project deliver in spite of the obstacles? Should the Scrum Master accept the dysfunction or not? At what cost?

As Ken Schwaber says in Agile Project Management with Scrum, “A dead sheepdog is a useless sheepdog.” Still, a useless sheepdog is also a useless sheepdog.

As JP Boodhoo says, “develop with passion.” As my friend Luke Melia says, “live with passion.”

The Functional Manager in Agile

Home Farm by Hellsgeriatric, on flickrTeam managers should till the soil with their teams.

Anything else is waste and waste must be rooted out.

Still it is hard.

Luke Melia wrote about how he performed as functional manager and dedicated 75% of his time pairing.

There are two tremendous challenges with this.

The first is limiting distractions in order to remain a reliable contributor.

Luke has tremendous reserves of focus and enthusiasm. As his manager, I did everything I could with our scrum master, Salim Divakaran, to support him, remove distractions and share workload.

The second challenge is being both the boss and a peer.

Luke recruited most of the team, he held weekly one on ones with each person, he insisted on unvarnished feedback, and is worthy of respect as both a peer and a manager.

So, here is the pattern: An experienced coach with people skills and authority over development practices pairing in with the developers. An experienced scrum master. Functional management residing in one or the other or divided up in some sensible and easily described way among the two of them.

This enables direct participation in the work, management attention to the team, and strategic contribution to the rest of the company.

ken h. judyI am an executive manager, software developer, father and husband trying to do more good than harm.
Working to spend each day doing a little less crap and a little more not crap than the day before. Without delegating my crap to others.
Aspiring to pride in my accom- plishments and pride in who I become as I attain them.
IEEE CSDP
CSP
I'm speaking at Agile 2012

Papers

Presentations

 

Site menu:


Meta

Creative Commons License

Post text is licensed under a Creative Commons Attribution - Noncommercial - Share Alike 3.0 United States License.

Unless otherwise indicated, Images in posts are not cleared for redistribution under creative commons.

Copyright © 2006-2012
Ken H. Judy.

This is a personal weblog. Views expressed are my own and not those of my employer.