--- On Mon, 8/25/08, Curt Sampson <cjs@...
> Regarding the Practice Adoption slides, it would be nice to
> see a
> short explanation of those formulas you picked, rather than
> having to
> reverse-engineer them and surmise why you picked them.
Good point. I thought I gave the formula in the notes on one of the slides but will go back and verify. I used the same formula throughout. Didn't give my reasoning though, which I should have. Will update in the next couple of weeks, I'm currently on the road.
> I'd be interested to know why you consider the project
> practices to be easier to adopt than the some of the coding
Hold a daily stand up meeting is a no brainer but TDD requires significant skill and discipline.
Also, my understanding is that it's still possible to become a certified master at several of the management techniques by only taking a two-day course which you need to go out of your way to fail. Clearly these practices, and the method around them, must be absolutely trivial for this to be true. ;-)
> such as TDD. Speaking as an XP coach of many years,
> who's introduced
> (or tried to introduce :-)) XP into several long-term
> projects, my
> current experience is the opposite. While TDD, for example,
> some time and effort to learn to do reasonably well, it has
> been a
> fairly uncontroversial practice, whereas the planning game
> has almost
> invariably been a harder sell, and tends to get dropped
> more easily if
> not pushed hard.
I've found the exact opposite, and the survey seems to show that. I suspect what's happening is that the practice is both easy to adopt and then to drop. ;-)
> This appears to me to be due mainly to social issues.
Exactly. Culture change is hard. The practice is not.
> That often agile coaching is sold as coaching to the
> technical team
> rather than to the management team is probably also part of
> the problem;
This might be the difference. My focus is on executive coaching, not on technical coaching. Without that level of coaching it's very difficult to have successful agile adoption across an organization. Technical coaching is ok at the project level, but many organizations are beyond the pilot phase now and their coaching needs have evolved.
> in these cases it may well come as a suprise to management
> that they're
> expected to make radical changes to what they're doing,
Exactly, hence the need for executive coaching. ;-)
> as well, and
> possibly even worse yet, face reality and start cutting
> features. A
> frequent response to this (though not always overtly
> articulated) is,
> "We never had to cut features before; what's wrong
> with your system?"
> Pointing out that they were virtually incapable of doing
> releases before
> is not likely to score you too many points, unless
Hence my favorite question to ask people "Really, and how well did that work for you in the past?". Yes, it's uncomfortable for people, but if you stick to your guns it works incredibly well. They need to understand that they've got a problem until they're willing to fix it.
> they've actually "hit
> bottom," as certain other fields put it.
> As well, even the technical side of, say, planning game
> can be extremely difficult. The classic example from my
> experience has
> been on legacy projects where one is trying to introduce
> agile practice:
> these are typically large, highly-coupled, unreliable
> systems entirely
> lacking in tests. It's impossible to make any
> significant progress on
> them (at least, not without breaking a lot of stuff), which
> is the
> reason that the development team and/or its managers is
> looking for new
> techniques in the first place: everybody's aware that
> the old techniques
> are what brought them to this state.
So you need to take a different approach with that stuff. Recognize that you need to dig your way out of the whole, that your velocity working with poor quality legacy stuff is lower than with higher quality stuff. The planning game is still the planning game.
> However, to get out of this usually requires replacing the
> technical infrastructure of the project (ideally over
> time), and, due to
> the coupling, it's very difficult to find small pieces
> to replace that
> let you add new functionality. And it's hard to sell
> the planning game
> when the business functionality that's being added in
> all these stories
> is a nebulous small increase in reliability and ability to
> create new
> features later. That often the best way (economically, as
> well as
> technically) to deal with a particularly sticky technical
> issue is to
> remove a feature doesn't help with this.
And how would traditional planning not be affected as well by this issue?
Sounds like you've needlessly let technical challenges get coupled to management practices and given people an excuse to continue fooling around.
Part of good coaching is to recognize when to make people uncomfortable and force them to do things that are good for them that they wouldn't normally do willingly. Sports coaches don't tell you to "drop and give me 20" for the sheer joy of watching people do push ups, they do it because they know that to be successful you need to do this sort of thing to build up your strength. Good agile coaches will tell people to "drop and estimate 20 points worth of stuff" at the beginning of the iteration even when the people doing it find the task uncomfortable.
Scott W. Ambler
Practice Leader Agile Development, IBM Rational
Agile at Scale: http://www.ibm.com/developerworks/blogs/page/ambler
Yahoo! Canada Toolbar: Search from anywhere on the web, and bookmark your favourite sites. Download it now at