This week's book giveaway is in the Mac OS forum. We're giving away four copies of a choice of "Take Control of Upgrading to Yosemite" or "Take Control of Automating Your Mac" and have Joe Kissell on-line! See this thread for details.
would you discuss your thoughts on cross team dynamics where one team (or one person in a team) adopts agile practices yet the remainder of the team continues with their traditional (college-based) development practices. How could the agile developer impress on the other developers the need for these best practices when their existing methods are working so far?
Originally posted by Fred Muhlenberg: How could the agile developer impress on the other developers the need for these best practices when their existing methods are working so far?
Some elements of agile will not work if not everyone is on board--for example, if one person produces tests but other developers willfully check in code that breaks the tests.
Perhaps start to quantify what "working" really means. Start tracking defects, code quality, etc. Talk about it.
It may not really matter much, still, because many people who don't want to change won't change, even if facts and research clearly show the benefits.
Everyone has their own motivators. For some people, it's a good personal experience with having tried something; for others, it's observing the success of others, or seeing research, statistics, case studies, evidence that it's taking over; for others, it's fear of losing their job. There are some people who will never change.
How could the agile developer impress on the other developers the need for these best practices when their existing methods are working so far?
Hmmm.... I'm not sure that you could, if everything is working well, I'd ask you why do you want to change?
Now, if there is room for improvement - and there usually is - then what usually works well is to take your discussion one level up in abstraction. Discuss the goals of your team/department/organization. Do you want to improve quality? Get a more user-friendly application? Reduce development costs? Be able to respond to change quickly? Etc...
Once you and your team can decide on what you want to do next to improve, then it becomes easier to talk about practices that help you do that. Download and read chapter 5 which will give you a preview into business values and process smells that are addressed by different practices.
Amr Elssamadisy<br /><a href="http://www.amazon.com/Agile-Adoption-Patterns-Roadmap-Organizational/dp/0321514521/ref=pd_bbs_sr_1?ie=UTF8&s=books&qid=1220909336&sr=8-1" target="_blank" rel="nofollow">Agile Adoption Patterns</a>
I guess I agree with Amr - when things are working so far, it's hard to argue that there really is a *need* to change something.
Anyway, one important thing to remember is that you can't change people - you can only help them find out where *they* *want* to change, and then support them changing themselves.
I find that Iteration Retrospectives are one good tool for that.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus