My response to the question:

Why some Agile projects succeed while others fail? Is the reason of that in the company itself or is there something wrong with Agile methods?

What is success and what is failure in this question?

Agile is a set of human values embodied in a wide array of practices. To call it a tool is to dismiss the tenacity, honesty, courage, empathy, trust, generosity, pride, discipline, respect and loyalty that inspire the practices and that explain why those practices can change people and organizations.

But being Agile is also fundamentally about specifics. What is the best adaptation of a set of disciplined practices for a specific team in a specific context to achieve a specific goal? How to evolve those practices day by day, acknowledging our shortcomings and our immediate obstacles, working to our specific strengths as individuals and as a team.

The definition of success is critical. If it is undefined, unachievable, subject to forces outside of the efforts of the team, or subjective in the eyes of people who don’t participate in the project then success or failure is arbitrary. Outside the scope of the participants.

In many cases, failing fast, failing decisively is a kind of success in that no amount of additional expense ensures meeting subjective, arbitrary or external measures and, at the end of the day, even meeting those measures doesn’t necessarily benefit customers and end users.

Completely understandable though why human beings who value material means, family and interests outside of the workplace would opt for the long, slow ambiguity over short, concise defeat. Besides there’s always the hope that time will allow for the change that makes success possible. This is the constant tension in inspecting and adapting – in any given situation is it better to shove, nudge or work around an impediment.

That said, even a smart project with a great team and a perceptive product owner can fail in the marketplace, or fail to impress funders, or fail to fit in the corporate culture, etc. etc.

So, Agile projects can fail as all human endeavors can fail. They fail because the participants call whatever crap they happen to be doing “Agile”. They fail because a team doesn’t adapt fast enough or because they try to force change too fast. They fail because a great team is working for a bad product owner. They fail because a great team and product owner are building the wrong product or the right product for the wrong company or at the wrong time or in the wrong place.

Provide a specific example and you can get specific answers. Provide a generic question and the answer is, “Yes, all of the above.”

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

Tag(s): agile, Agile software development, Organizational culture

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

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