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

I am ambivalent about the Scrum community’s focus on process and tools.

Yes, it is this effort that has driven adoption and created an economy for us practitioners. But adoption is yesterday’s challenge. We’re kind of winning that one.

We need to place less emphasis on getting new organizations to try Scrum to more on getting existing teams practice Scrum better.

How many of us many, many Scrum adopters strive towards the potential of the practice?

• Where reliable software delivers monetary return to sponsors because it is truly valuable to end users.
• Where individual contributors are allowed to bring their most creative effort to the workplace to the benefit of both employers and end users.
• Where workers are allowed to live rewarding lives outside the workplace to the betterment of their families and communities.

Not just exceptional productivity – ambitious enough as that is — but exceptional productivity to a genuinely productive end.

Life is full of compromise but if that is not the aspiration — to fill our careers with as much of these achievements as possible — then why bother?

Why spend money on training and tools to deliver more waste on short, iterative cycles?

Why extract more lines of code that no one will test or use but only spend money to maintain?

Why use the Scrum process to perpetuate the alienation of the knowledge worker from their work?

Mastery means taking responsibility for ourselves and our peers. Grasping our practice is the sum of our intentions and actions in the service of something.

So here’s my plea to shift the conversation back to it’s roots.

“Agile” is about the material and human good we create when we respect our co-workers tell truth to our employers, strive to improve, and care for the people affected by the software we help build.

We use a tool or process to the degree it furthers that end and no farther.

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

Tag(s): agile, knowledge worker, principle, scrum

Comments: 1

Here are agile software development mistakes that kick my ass whenever I let them:

• Know the assumptions in plans. Recognize when they change.
• Don’t abuse time boxing. It is a toe hold for over-committing. When the time box ends, the work ends.
• Doing Scrum means DOING SCRUM. Sloppy backlog. No Scrum. No Product Owner. No Scrum.
• No iteration boundaries and no commitment doesn’t make me “lean”.

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

Tag(s): agile, management, product owner, product ownership, scrum, software development mistakes

Comments: none

Trying to gather what I can from Bob Woodward’s column in the NYTimes, 10 Take Aways From the Bush Years. Basic management advice extracted the hard way from the record of our first MBA president. Among the lessons:

• insist that everyone speak out loud in front of the others, even — or especially — when there are vehement disagreements
• foster a culture of skepticism and doubt
• insist on strategic thinking
• embrace transparency

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

Tag(s): Bob Woodward, first MBA president, management

Comments: none

This week, I’m presenting a paper at the Hawaii International Conference on System Sciences. My goal is to engage academic ethicists in a conversation about agile software development.

Given the year in employment I’ve had in the last year and what’s going on at my current employer this week, it is a gift that I was able to attend and I’m grateful for it.

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

Tag(s): agile, ethics, software development

Comments: 1