Category: Individuals and Interactions

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

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

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

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

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

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

On Retrospectives

Retrospectives seem to mean many different things to different people. At least, that’s the way it happens in practice. People approach retrospectives in different ways, with different motivations, and that naturally leads to very different experiences and outcomes.

Venkatesh Krishnamurthy wrote about Retrospective Smells in which he quoted some cautions I’d posted on the Lean Software Development yahoogroup. This was in response to Allan Kelly’s mention of his blog post, The Trouble With Retrospectives, which was, in turn, mentioned in response to Robin Dymond’s announcement of his new Retrospectives Wiki. Read More

Learning from experience

It is good when we learn from our experiences–much better than when we don’t learn from them. I recently wrote about learning, or failing to learn, from observing others. A recent discussion on the scrumdevelopment yahoogroup got me thinking about another way to learn from experiences, and that’s learning from the experiences of others.

The discussion I mean started in the middle of another thread, when Clay Dreslough asked about Pair Programming.

But I have never had any success with actual Pair Programming.

So … am I missing a key component of XP? Or have other people found the same reticence with adopting Pair Programming?

Are there some valuable gains here that I’m missing? And if so, how would you recommend getting programmers to change their habits? Read More

Agile Compensation

The subject of determining compensation for developers on Agile teams comes up from time to time on the mailing lists. I’m no HR specialist, and I don’t have any easy answers to this question. It seems certainly true that some people will have provided more value than others and should therefore be given more reward. It is also certainly true that if the reward system is geared only toward individual achievement, then teamwork will suffer. Beware the law of unintended consequences.

There’s a whole class of arguments, however, that can be discarded rather easily. Read More