Granny's Programming Pearls
"inside of every large program is a small program struggling to get out"
JavaRanch.com/granny.jsp
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Liutauras Vilda
  • Tim Cooke
  • Jeanne Boyarsky
  • Bear Bibeault
Sheriffs:
  • Knute Snortum
  • paul wheaton
  • Devaka Cooray
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Ron McLeod
  • Piet Souris
  • Ganesh Patekar
Bartenders:
  • Tim Holloway
  • Carey Brown
  • salvin francis

advice on helping colleagues

 
Ranch Hand
Posts: 132
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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?
 
author
Posts: 799
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
author
Posts: 37
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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!
 
author
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
In my experience, another thing that helps is patience and a sense of wonder
 
Sheriff
Posts: 1367
18
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
when your children are suffering from your punishment, tell your them it will help them write good poetry when they are older. Like this tiny ad:
professionally read, modify and write PDF files from Java
https://products.aspose.com/pdf/java
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!