Posts Tagged ‘Communication’

At daily standup meetings, they eye each other from opposite sides of the room. Sitting on the same side of the cubicle wall is unthinkable. They’re united only by their desire to produce quality software products and their appreciation for coffee and energy drinks. What’s good to one side can be anathema to the other when it comes to code. I’m talking, of course, about testing and development teams. In the interests of generating more comments improving dialogue between two very important functions in a software organization, our marketing director asked me to interview our

People who do not get hired after an interview second guess themselves; they look for concrete reasons as to why they were not hired for that particular job. They might justify it by saying the company sucked, the interviewer was an HR douchebag, the hiring manager did not know their stuff. Of course, they may be correct in passing these judgments, however, chances are there simply was a mismatch between the person interviewing and the company. When this happens, count your blessings that the people doing the interviewing for the company knew that. Being brought

As readers know, we’ve been talking about code reviews pretty regularly here and elsewhere over the past few months. To continue that discussion, here’s a question we run into often: are in-person code reviews as the primary way to communicate, by definition a bad thing? Here’s some more data from the Forrester Consulting study commissioned by Klocwork that shows the majority of respondents still conduct in-person reviews… elsewhere in the survey only 36% of respondents indicated that they worked on a centralized team with everyone in one location. So that means, if 60% still conduct

So a while back, I explored where developers get their information. Surprisingly, it is hard to find hard data on the subject. As a bonus from a Forrester study commissioned by Klocwork into the habits of code review, part of the data revealed developers’ use of social media tools. When asked directly about their use of these tools to communicate with other developers, the majority polled would not choose a social media channel. It just goes to show that yet again, software developers are a breed apart. As an aside, as I was researching this topic, I found

There has been a start to bring the concepts of lean manufacturing into agile development. Recently, Mike Cottmeyer in How to Build a Large Agile Organization proposes that Agile on its own is not enough for a large organization. In his view, Agile falls short and needs to be supplemented by additional methodologies like Lean or Kanban when coordinating outside the development team. If adoption of Agile is impeded by its very nature in large organizations and Kanban is the proposed answer, then the Agile solution is insufficient. Agile needs to expand its scope to be relevant and useful

I just couldn’t resist using the classic spaghetti Western as the title for this installment of my Going Agile series because it a) it was an awesome movie, and b) it truly sums up that 1st iteration of ours. My last post was all about the 1st iteration planning meeting, and how it was such an exciting and productive time for our team. We came out of that meeting a little weary, but extremely motivated to get to work. We were also just a tad naive. The next 2 weeks were a roller coaster as

Now that the New Year is upon us, I thought it would be a good time to add another chapter to my Going Agile series. My last entry left off at the point where we had prepared our backlog, created team rules and defined “Done”. Now we were ready for our first Iteration Planning meeting. In our “team room” we had all the essentials in place for this meeting: stacks of color-coded cards (for capturing the various to do’s, or tasks), pens and highlighters, our Scrum board (with pins) to stick our tasks onto, and

Our new documentation wiki is up and running! For awhile it seemed like we’d never do it. We have a team white board that records our panic level, and for several weeks, the level was up around “hysterical” and “wanting to open my own daycare”. We also have a white board in front of the doc area, in a hallway where everyone walks by to get to the kitchen. At one point when we were particularly frustrated with MediaWiki, the topic was “names for the new doc wiki”. A few good suggestions: Duh-Wiki Kwiki Wooki

Agile technical writing is a popular topic in the blogosphere (see Edwin Dawson’s recent three-part blog series). The user communication team at Klocwork is becoming more agile in fits and starts. In the last release, we joined our development team in using Xplanner, and found that it both reduced that horrible did-we-miss-something feeling and increased the visibility of our status. In this release, we’ve resisted the urge to create a matching help story for every dev story. Instead, we create stories that allow us to focus on the highest-priority types of information: what’s new in

“Now what?” is that uncharted territory between “Getting Started” product guides and the challenge of incorporating a new tool into day-to-day activities. In fact, I’m convinced that “Now what?” is one of many creatures inferred by the “Here be monsters” legend inscribed on uncharted regions of old nautical maps. I think of it like this: You buy an exciting adventure package to Costa Rica. You put your money down. The tour operator hands you a map. And then you end up…in Holland. Time to call your emergency number: You: “Can you help me out?