Langr Software Solutions » collaboration

Langr Software Solutions » collaboration — Main Menu — Home Consulting / Coaching Training - Information About Training - Student Quotes - Technical Training - Process Training Resources - Agile in a Flash blog - Articles - Jeff’s Wiselike Page (Q&A!) - Books Jeff’s Blog About Home Consulting / Coaching Training Information About Training Student Quotes Technical Training Process Training Resources Agile in a Flash blog Articles Jeff’s Wiselike Page (Q&A!) Books Jeff’s Blog About Contrarians October 13, 2008 by Jeff Langr 0 Comment Should we ever “give up” on someone? Agile or not, development or normal life, people are always the biggest challenge. Difficult people are obvious targets, since by definition they do things that most people don’t want to deal with on a day-to-day basis. But can we help them become less difficult? Just what is a difficult person? I actually welcome a healthy level of skepticism. If you’re not skeptical about things, you’re probably not pushing boundaries as often as you should. I can help a skeptical but open-minded person by answering their questions and guiding them through necessary self-discovery and acceptance of a new idea. With some people, however, skepticism instead grows into a potentially unhealthy attitude, whereby they resist differing ideas at all costs. Stated from their point of view, “I’m right and you’re wrong.” Sure, if you’re absolutely right in your reasons to avoid something, it’s an appropriate response. But that’s almost never the case, particularly when we’re talking about something like TDD or automated testing. People have achieved good levels of success with diametrically opposed ideas, strategies, and tactics. What that means is that someone who wants to argue every last point against their presumed opposition is being close-minded. Sometimes they cross over the boundary into pure contrarian–even if you agree with them on a point, they still find a way to argue against it! I felt regret most of this weekend about a post I made to one of the agile lists last week. After an exchange of a few nit-picky posts, I stated that I wasn’t going to waste my time any more. It was soon apparent that the other poster was going to shred virtually every line I wrote, never mind trying to find any common ground. Now I don’t feel bad at all–blowing hard at brick walls is a huge waste of time. Comments: What do you do in order to deal with this people? Do you have any advices? posted by roman : 10/13/2008 11:19:00 AM === Once you’ve (really, really) established that they will not budge, then the best thing is to find somewhere else for them to be. I think at that point you just have to be direct. If they’re in the midst of your team, ask them: “Do you plan on trying to work like the rest of this team has chosen or would you prefer to work differently?” Sometimes they can educate you on valuable changes you can make to improve the transition. But most of the time, they just need to find a more compatible team. posted by Jeff L. : 10/14/2008 08:17:00 AM Stories and Code Quality January 30, 2008 by Jeff Langr quality 0 Comment (See also Stories and the Tedium of Iteration Planning Meetings .) Doling stories out to individual developers not only makes for more boring iteration planning meetings, but it also impacts the system’s overall quality. One of the most overlooked practices in software development today is review. If you don’t pair, then you really must find a way to consistently review work product. Unfortunately, most companies pay the cost of not doing this: code that is increasingly more difficult to maintain, and solutions that are questionable at best. Insisting that a team finish a story every couple of days or fewer will often mean that two or more developers must collaborate on a story. In order to collaborate, they must agree on some part of the design and a plan to implement it. The developers will need to continue talking as the implementation progresses. That’s a good thing. Much of the resulting design won’t be one developer’s wonderfully clever or woefully inadequate brainchild. Such collaboration brings a bunch of siloed developers one step closer to being a true team. Initially, velocity will decrease a bit: developers will have to learn how to talk to each other and coordinate things. Developers will learn more about other parts of the system, increasing their value to the project as well as their personal worth. It’s not quite as good as pairing, but it does go to the heart of agile. A Case for Pairing: Open Workspaces and Distractions November 15, 2007 by Jeff Langr 0 Comment I currently work as part of an agile mentoring team in a large organization. Up until recently, we shared a project room. At any given point in time, there might have been one of four to six or seven team members (including a manager), plus one to three people that we were working with. On average there were four people in the room at any given time. Up until this experienc