I have a week to prepare for this month’s APLN-NY which now goes by the zazzy name “Agile New York City”.

Last month, I was the last minute replacement for the planned speaker until the planned venue fell through. So this month, I am the scheduled speaker. This lends an air of improvisation to the event.

Right now, I am a year and a half into my current job and locked in the kind of agile adoption I’ve only presented with hindsight. Right now, I am about the day to day: acknowledging incremental progress, working through setbacks and full of my own limitations. I don’t know the ending. What I feel is an urgency to do better and be better.

So, I worked out the topic over some e-mail exchanges with Jochen Krebs. In the absence of a story to tell, it’s time to do a little a personal retrospection.

Instilling Agile Values for Creativity, Self-Improvement and Organizational Change – A Manager’s Perspective

The scale and speed of an agile adoption are external measures that don’t speak to the founding values of the practice. Collective ownership, continuous improvement and high trust are hard won, take time and discipline but lead to craftsmanship and joy. They are enabling conditions for innovation and beneficial change.

I will retrospect on my contributions both positive and negative towards cultivating these values in two teams. The first was a practice that matured over four years, led to a new mission for the team and direct collaboration with the founder and CEO. The second, is a new team finding its way at the end of its first year.

What will I do more off? What will I do less of? What impediments got in the way?

Short link: http://jkat.me/gkPzbw

Tag(s): Agile software development, Jochen Krebs, New York City, scheduled speaker, Software project management

Comments: 1

Here is a draft handout from my presentation at “Agile NYC”, Instilling Agile Values for Creativity, Self-Improvement and Organizational Change – A Manager’s Perspective.

http://idisk.mac.com/kenjudy-Public/papers/agile-values-outline.pdf

Short link: http://jkat.me/eI0H6w

Tag(s): agile, Agile software development, AgileNYC, ethics, handout, management, principle, values

Comments: none

As advocates of agile software development we focus on practices.

The hype on those practices is they produce software, “faster, cheaper, better.” And we sell our efforts with the promise of, “delivering value.”

We speak of value as if the definition is shared, self-evident, contained within our backlogs and measured by our burn ups.

At the same time we minimize the hard and long the struggle to achieve mastery, identify and address a material need, and sustain creativity and quality.

So, we win the opportunity to labor with our teams to incrementally deliver potentially shippable units of code to stated business priorities.

When those priorities are pointless, so is the software.

When those priorities are tactical and subjective, the values behind agile practice — sustainable effort, maintainable code, self-directed teams, collaboration and trust — become irrelevant.

The truth is there are definitions of “value” that sell us out whether or not material success accrues to someone as a result of the software development effort.

And so, an agile adoption that is true to its participants is an ongoing, perhaps excruciatingly gradual, but substantive conversation with the larger organization on the definition of value.

A set of practices is only companion to the human values that give our work meaning.

Short link: http://jkat.me/hQz7fX

Tag(s): agile, Agile software development, Business, management, Social Issues, software development, software ethics, Software project management, technology

Comments: 1

I’ve written about agile software development as an ongoing, perhaps excruciatingly gradual, conversation on the definition of value.

We need a place at the conference table. But we also need a forum and language to discuss the human values behind the way we aspire to work.

“… I’ve got to have more experience with junior [children] than a lot of the people who are telling me what I should be doing with them… I think I could help bring a lot to it and nobody ever asks…They just go ahead and proclaim and we have to follow.” -– Anonymous Teacher

This quote is from a study on the failure of education reform movements, called What’s Worth Fighting for in Your School?, by Andy Hargreaves & Michael Fullan.

Reform often fails because reformers don’t engage individual contributors in the goals. Rather, they impose practices upon them. The attempt to improve the classroom actually makes the teacher less effective and sets them against reform.

Sound familiar?

The landscape of broken agile adoptions is composed of attempts to make software development “faster, cheaper, better” without embracing the experience and creativity of our core asset, the software developer.

We need to focus a little less on specific practices and a little more on building consensus among our peers over a shared set of values which despite human fallibility and economic necessity inspire us to do good work.

The Manifesto for Agile Software Development is an attempt by thought leaders to capture these principles. As with all documents, it is an artifact of a moment created to address that moment’s opportunities and constraints.

If we take the “Manifesto” as terms and conditions, something to read and sign before we advance to practice then we glide over the surface of things. It’s not what was written but why people felt the need to write it.

If we take the “Manifesto” as a complete expression, then as happens with codes of ethics, we will use its silence on certain concerns and nuance in the interpretation words themselves to excuse actions by others and even justify the harm we do ourselves.

The “Manifesto”, as with any other artifact in agile, is simply a reminder to have a conversation.

Martin Fowler discussing gender disparities in the industry:

How about a community where women are valued for their ability to program and not by the thickness of their skin? How about a community that edgily pushes new boundaries without reinforcing long running evils?

Bob Martin lobbying to add a fifth principle to the Manifesto itself:

“We value craftsmanship over execution” (or “craftsmanship over crap”)

But the discussion isn’t between thought leaders. It involves every practitioner.

We are here to create long-term value. To build businesses, careers and an industry. This is a labor of years not the current iteration.

If your concerns are entirely short term, then there are less disingenuous ways to extract wealth from people’s effort than to claim you are “agile”.

If you are agile, then you are accountable to the creativity and well-being of the teams with whom you collaborate. You are accountable for the security of end users and the benefit they derive from the software you create.

We are not tools. We are knowledge workers. What we create carries with it the way it was created. What we create is in some profound way us.

Short link: http://jkat.me/eClTeM

Tag(s): agile, Agile Manifesto, Agile software development, Bob Martin, Martin Fowler

Comments: none

As I’ve said before, we use Thoughtworks Studio Mingle to track our backlogs.

One thing Mingle has not provided for us in the time we’ve worked with it is a daily burn up. Kind of shocking.

Last month, we migrated our instance to the EC2 cloud. I took advantage of that migration to un-cruft our Mingle instance, apply the XP template and simplify card types and states.

Now time to stop dumping data out of mingle to report status. Yes. Kind of shocking.

The first step was to track the data points we need for a burn up.

That involved creating a series of date fields to track the day on which a story moves from in analysis to ready for dev, in dev, in qa, ready for customer (QA done) and customer accepted.

We also need a way to have those dates recorded automatically as part of moving cards from one state to another.

So we set up Mingle card transitions.

This replaces the drag and drop behavior of a card from one swim lane to another with a button link on the card. This a bummer for our product team but it allows us to script transitions to both change the status and set the appropriate date field.

Now to setup a burn up chart using Mingle charts and mql.

Observations:

• I had to hard code date start and date end in x-labels-start and x-labels-end but otherwise, I was able to use the project variable ‘Iteration – Scheduled’ = (Current Iteration) that’s part of the XP Template.
• Burn up is accomplished by setting cumulative:true. Unfortunately, I can’t get trend lines to work as a result.

Here’s what the result looks like:

This chart along with selected summary counts and tables allows us a real time dashboard of the health of our sprints.

As you can tell from the burn up, we have work to do improving flow in our iterations.

Anyway, reporting is a work in progress. As is everything.

Short link: http://jkat.me/i4M0Kw

Tag(s): Agile software development, project management, reporting, scrum, Thoughtworks Mingle, xp

Comments: 1