Fixing the Agile Engineering Problem

A lot of people are talking, recently, about the fact that organizations that adopt Agile practices don’t always achieve the results they desire.  See Martin Fowler’s Flaccid Scrum, Ron Jeffries’ Context, My Foot!, and Jim Shore’s The Decline and Fall of Agile for examples.

In my experience, most organizations have much room to improve both their project management and their technical engineering practice.  Those that start with Scrum seem to improve their project management practice enough that the deficiencies in their technical engineering practice become more painfully obvious.

The answer is simple and obvious–improve the technical engineering practice.  The way to do that is not so easy, however. Read More

8 Comments

Categories: Individuals and Interactions

Tags:

Agility and Predictability

I was reading the latest post on Johanna Rothman’s Managing Product Development blog.  In it she says,

Serial lifecycles provide a (false) prediction. And, boy oh boy, is that prediction comforting to your senior managers. “When will the project be done?” might be their most-asked question. Of course, a serial lifecycle provides a prediction that’s almost guaranteed to be wrong, especially if you use a project scheduling tool. The tool provides you a single-point estimate, which is the first date you can’t guarantee the project won’t be done by”“the first possible, optimistic date.

I like that characterization of the predicted date.  Another characterization, usually true of serial lifeycles, is that the predicted delivery date is the first day of schedule slip.  I’ve seen many serial projects get almost to that date before they first admit that they’re in trouble. Read More

1 Comment

Categories: Customer Collaboration Tools and Techniques Working Software

Tags:

Should it really take that long?

In my previous post, Working Hard, or Hardly Working?, I mentioned how it was possible to tell the wheat from the chaff by observing.  Alistair Cockburn rightly suggested that the manner of observing that I suggested was more appropriate for a team leader than for upper management.  Yes, he’s quite right about that.  He had in mind a Vice President who, when told that the development team had estimated something would take two weeks, asked him,

How can I tell if it really should take that long, or they’re just padding to make their life easier?

How would you answer that question? Read More

2 Comments

Categories: Individuals and Interactions

Tags:

Working Hard, or Hardly Working?

I first heard this joke way back when, at my first real job–I was a TV repairman when I was 14.  It may generate a polite chuckle when asked between peers, but it’s serious business when the boss asks the worker.  It’s also been a topic of conversation over on the Scrumdevelopment yahoogroup, where Graeme Matthew described the difficulty of determining this using velocity.

The unknown in all of this is that if a team have a velocity of 6 how do you tell if they should have a velocity of 8 i.e. they are underperforming. It gets complex. If they have a velocity of 16 are they doing well or have they estimated at the higher scale of story points.

I agree with Graeme that this is one of the difficulties with using velocity to measure performance.  I agree with Alistair Cockburn when he says

There is NO good measure of “programmer productivity”.

earlier in the same thread.  Yet when you work with people, you generally know who’s working hard and who isn’t.  It’s an interesting conundrum, isn’t it? Read More

12 Comments

Categories: Individuals and Interactions

Tags:

More on Agile Usability

I recently wrote about Agile Usability.  Now I find an article on StickyMinds, “Getting Agile With User-Centered Design,” by Jon Dickinson and Darius Kumana.  They talk about a number of issues that can come up.  My favorite bit is this:

We must actively challenge the mindset of divided responsibility–” You spec and design it; we’ll build what you spec.” Everyone should work toward the shared vision of a successful experience.

That says so elegantly what I tried to say in my article.

No Comments

Categories: Responding to Change Tools and Techniques Working Software

Tags: ,

AYE 2008 – The Magic Chemistry of Teams

Wednesday afternoon, at the AYE Conference, I greatly enjoyed Esther Derby’s session, Magic Team Chemistry: Starting and Sustaining Teams. We divided up into small groups, and each person drew a timeline of their career, marking high points and low points. We then mined these timelines looking for the characteristics of the good times and the low points.

Each group built a list, but there were lots of similarities.

Cherrypicking from some of these lists: Read More

6 Comments

Categories: Individuals and Interactions

Tags: ,

AYE 2008 – Moving Projects Forward: The Clinic Method

As I slowly work through my notebook from the Amplifying Your Effectiveness Conference (having blogged about sessions on Unearthing the Data You Need, Remembering Your Resources When Stressed, and Congruent Coaching), I come to Jerry Weinberg’s session of Tuesday afternoon, Moving Projects Forward: The Clinic Method.

As long as projects are staffed and led by people, we can be sure that they will sometimes get stuck, or headed in the wrong direction, or something.  This is true no matter what sort of methodology you follow.  Even if the methodology is perfect, the people following it are not.  They will make mistakes.  They will have blind spots, and not see what it is that they’re not seeing.  Projects will still get in trouble.  (Yes, even Agile projects.)

So, what do you do about this certainty? Read More

1 Comment

Categories: Individuals and Interactions Responding to Change Tools and Techniques

Tags: ,

Agile Usability

If I had time, I would re-read Tom DeMarco’s book Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency, because I have precious little slack in my own life, these days.  So it is that I just now got around to reading Jakob Nielsen’s article, Agile Development Projects and Usability, which William Pietri noted on the Agile Usability list on November 17.

The statement

“For a project to take interaction design and usability seriously, it must assign them ‘story points’ (i.e., resources) on an equal footing with the coding”

jumped out at me.  Alistair Cockburn wrote a thoughtful reply where he noted the same statement.  I agree with Alistair’s comments, but I’d like to comment on this statement from a slightly different perspective. Read More

5 Comments

Categories: Responding to Change Tools and Techniques Working Software

Tags: ,

AYE 2008 – Congruent Coaching

Continuing with my recap of the AYE Conference sessions I attended, I come to Johanna Rothman‘s session, Choosing the Right Coaching Approach: Congruent Coaching. This was a time-slot where I wanted to attend every single session. I chose this session because coaching is a big part of what I do, and Johanna is one of the best people I know to learn to coach more effectively. Read More

1 Comment

Categories: Individuals and Interactions Tools and Techniques

Tags: ,