Re: [scrumdevelopment] " Right" of Team to Choose their Dev approaches vs evidence that XP works best
No, the coach need not wait.
Even long email descriptions lack 99% or more of the data for the
situation described, because it is email. The situation described
seemed to point to a coach and stakeholders who see mandating
practices as a high risk of rejection by the developers. There are a
great number of possible reasons it would be better to mandate
specific engineering practices, slowly or even all at once, depending
on the situation.
My one answer in this situation, based on my understanding of
incomplete knowledge transfer, should not be taken to imply that it is
the correct answer for this or any other situations. It is simply the
best I could answer based on the little I currently think I know.
On Sat, Nov 13, 2010 at 7:04 PM, Adam Sroka <adam.sroka@...> wrote:
> What happens when the team reaches a plateau where successive changes
> don't lead to successive improvements? Is it okay, at that point, to
> recommend practices that you know are better than the ones they
> currently use? Is it necessary to wait that long?
> I think self organization is great, but it can lead to local
> optimization. The concept of self organization comes from observing
> natural phenomena and you don't have to look far in nature to find
> systems that have self organized in sub-optimal ways.
> The trick is to know when to inject good ideas and how to do so so
> that the ideas take and don't break the system. The rest of the time
> you let the system self organize. Similarly, 99% of the time I want my
> body to take care of itself, but every once in a while I need a
> On Sat, Nov 13, 2010 at 5:32 PM, Alan Dayley <alandd@...> wrote:
>> Do not demand or impose practices. Ask for and measure results. If you are the ScrumMaster, have the person writing the checks ask for results.
>> - Measure code quality. Ask for improvements.
>> - Measure meeting delivery, Done, commitments. Ask for improvements.
>> - Ask for cross-training. Ask for improvements.
>> Let the team figure out how to improve. They may choose TDD, pair programming, continuous integration, etc. They may choose other things that work or not. And the self-organize and learn and improve. Without being imposed upon.
>> Just a thought.
>> On Sat, Nov 13, 2010 at 8:42 AM, Doug <dshelton94501@...> wrote:
>>> I'm wondering how - when the goal is to "improve SW Dev processes" - followers of this group resolve the seeming contradiction of the Scrum principle that "The Team" chooses how they will address the requirements, with the oft-stated evidence that those Scrum teams that adopt / adhere to XP practices such as TDD, Pair programming, continuous refactoring, and (of course) use of User Stories - are found to be "more often" successful then those that do not. I.e., I'd love to "allow" our teams that basic Scrum "right" and to discover on their own that these practices work best, Buuut: (1) The teams I'm now working with don't really like TDD - and management is leery of pressing the case (even though we are in constant waterfall-based "QA run test case and Developer "bug-fix" mode") - and they don't follow hardly any other XP practices either; and (2) I don't want to lessen the chance of our Scrum adoption succeeding. In the last company I worked at, in my role as a eb Dev Mgr I "imposed" XP practices on the team (long before we ever went to Scrum) - and although they grumbled at first, they came to use those practices religiously.
>>> Any thoughts on "the dangers of" imposing such "restrictions" on the Scrum Team? Besides Mike Cohn's tomes on Scrum which discuss XP practices as well, I'd be curious to know who out there has other anecodotal evidence (or can point me to it) that XP with Scrum is the "most likely to suceed" combination of processes re improvving SW Dev productivity (that said in the "Wholistic sense - Better "quality' SW being thought to increase business value as well)
> To Post a message, send it to: scrumdevelopment@...
> To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...! Groups Links