Quoting Chris Wheeler <christopher.wheeler@...>:

> On 10/24/07, Gary Brown <glbrown@...> wrote:
>>
>> Quoting Ron Jeffries <ronjeffries@...>:
>>
>> > I share the concern about management, not specifically yours but
>> > many managements might start thinking PDT should be taken away "just
>> > during this crunch" anyway.
>>
>> Our management has already done that and learned the lesson.
>> Productivity went down, defects went up. It probably won't happen
>> again.
>
>
>
> This is an interesting statement. By taking away PDT, your defects went up
> and your productivity went down. Would you mind explaining the correlation -
> why did taking away PDT cause defects to go up and productivity to go down?
> Was it upset developers? Was it something different?
>
> Also, I'd like to add a bit. PDT, or any 'free' developer time isn't an XP
> practice, as I understand it. Slack is a practice. But slack doesn't equal
> 'free developer time'. Any free time is given to the developer because the
> company sees value in investing a certain percentage of time/money in
> allowing developers to do as they please. This has paid of well for some
> companies such as Google (but I've read that even that is questionable -
> can't recall where I read it exactly).
>
> My point is, PDT is a company policy, not an XP practice. Companies need to
> see some ROI on PDT and if they don't, then it's apt to get taken away.
>
> So, my next question, how have you shown that not working on stories during
> PDT increases the ROI of PDT?
>
> Chris.

Not only was PDT taken away, but people were asked to work nights and
weekends as well as extra effort to work off a backlog of data
transformation projects. This extra effort work was in addition to
the normal project work. It was "voluntary", but the director made it
clear that bonus money was at risk for those who didn't participate.
I objected to this as long and as loudly as I dared. It happened
anyway.

The developers soon figured out what was important, and started
working on the backlog projects during the day, instead of their
regular projects. They were tired, morale was low, and things were
getting promoted to production without going through the normal QA
process.

We measure velocity and defects reported each iteration. The charts
show a dip in productivity, and a spike in defects. The other
statistical anomaly of note was that unplanned time off also spiked
(people calling in sick, basically).

In my original note, I said, "In my organization, we designate Friday
afternoons at Personal Development Time. We adopted this practice,
not as an XP practice, but as one of the Seven Habits of Highly
Effective People, Sharpen The Saw."

We were asking people to learn Java, Object-Oriented Design and
Programming, Oracle, and XP, all at once. In addition to several
weeks of training for each developer, we felt it was important to
demonstrate that we were serious about learning new skills. We
established PDT as a visible period of time when the developers would
be free to do that.

We have no measure for the ROI of Personal Development Time. We know
the results a mixed. We also have some tangible benefits. A new
product was conceived and developed that generates revenue and web
site traffic. Many tools have been investigated and implemented that
have improved productivity.

We are also aware of the non-productive use of PDT. I hear it all of
the time from our software development directors. We have never
required people to account for their PDT activities. We want to treat
them like adults, knowing that some will abuse the privaledge. We
have so far resisted the urge to punish everyone for the sins of the
few.

GB.