aspose file tools*
The moose likes Agile and Other Processes and the fly likes advice on helping colleagues Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Spring in Action this week in the Spring forum!
JavaRanch » Java Forums » Engineering » Agile and Other Processes
Bookmark "advice on helping colleagues" Watch "advice on helping colleagues" New topic
Author

advice on helping colleagues

Jason Hocker
Ranch Hand

Joined: Jul 23, 2003
Posts: 132
Although my coworkers/management say we are agile, they still can't comprehend basics, let alone any specifics from a methology. What advice can you give to get the "experts" at my company to rethink their procedures/rules?
Jeff Langr
author
Ranch Hand

Joined: May 14, 2003
Posts: 762
I'm willing to bet that Amr's book would provide them with a better understanding of what being agile really means. But they probably wouldn't read a book...

From the stance of seeing how people botch agile, I know that a team is on the right track when they:

- deliver on the majority of their commitments each iteration, and at most a portion of one story is incomplete at the end of an iteration
- can tell you what their velocity is
- expose no surprises on the last day of an iteration
- can tell you relevant statistics about the code base, for example, how many unit tests are there and how long they take to run
- commit to improvement through use of a retrospective, without having to be told--they just do it
- don't fear open conflict

Jeff


Books: Agile Java, Modern C++ Programming with TDD, Essential Java Style, Agile in a Flash. Contributor, Clean Code.
Amr Elssamadisy
author
Ranch Hand

Joined: Sep 08, 2008
Posts: 37
I'd say get to a common understanding of your goals. You can use the first part of the book (which has a number of suggested exercises to run with your team) to talk about what needs to be done at your organization (regardless of process and methodology).

Once you agree, for example, that you want to increase quality, or reduce time to market, then you can suggest a few practices - one by one - instead of a whole methodology. Let them suggest others. The goal should never be to "be Agile", but to build software effectively. If they come up with reasonable alternatives to meet these goals, then you should be open to it as you want them to be open to your suggestions.

Often when you change the language from specific methods, to business values, or process smells and pains, you can get to common ground. Once you're there, the battle is half-won. Good luck!


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>
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
In my experience, another thing that helps is patience and a sense of wonder


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
Katrina Owen
Sheriff

Joined: Nov 03, 2006
Posts: 1364
    
  17
Ilja, that is a great post!

I have been wondering about stop-the-line... I'll throw it into the discussion next time we have it and see what comes out.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: advice on helping colleagues