Category: communication

Half-dead project saved! Thank you - Direct Communication

May 21, 2009 by Przemysław Bielicki

Picture (c) Przemyslaw Bielicki

In my previous post I shortly described the half-dead project in an over-waterfall company me and my team had to save three months before production. In this part I will show you how direct (instead of discrete) communication with customer or good Product Owner in general can help saving almost dead projects.

As I described earlier me and my team had a lot of problems with the systems we had to integrate - technical issues were present but they were not dominant, even taking into account the fact that the team was not experienced in .NET and T-SQL stuff.

The value of Big Design up Front

April 28, 2009 by Mendelt Siebenga

Lets start my first article on AgileSoftwareDevelopment.com with a controversial title. Just to get your attention. You're still reading? See! It works!

I often see teams, even teams that claim to be doing agile spend several weeks or even months at the start of a project doing requirements, analysis, design and planning. BDUF is a habit many people find hard to give up. Team members instinctively feel there's something of value in that first stage of a project they'll lose when they just dive in and start creating software. That value is not in the documentation they deliver, but it's something they do during those activities that they forget to do later on. Lets look at a typical project to see what people do during that first phase that makes it valuable.

The case for collocation

May 19, 2008 by cspag

I've been thinking a lot about the collocation of agile development teams (or any development team for that matter). Some people argue that collocated team members are essential to successful software development while others argue that it doesn't make any difference. The more I think about it, and the more we operate with geographically dispersed teams, the more I'm starting to believe that collocation matters.

Currently, our team is spread out between Ft. Collins, CO, and Orlando and Jacksonville, FL. While things have not gone terribly wrong having dispersed team members, I have noticed a difference in communications. The difference is that in the Ft. Collins office (and I'm sure in Orlando and Jacksonville), there is a lot of informal communication that occurs amongst collocated team members. You know, the kind of discussions that happen spontaneously. When these happen, a lot of project information gets passed between team members that doesn't get transmitted to other remote team members. There is no malicious intent to not communicate. It's just that the impromptu discussions don't usually inspire anyone to dial in to a teleconference number and all that...precisely because they are impromptu.

XP Values: Honesty

December 17, 2007 by Jeremy Weiskotten

"Honesty is the best policy — when there is money in it."
- Mark Twain

XP requires constant communication between team members. More specifically, XP and Agile teams depend on honest communication between stakeholders, including developers, testers, managers, and customers.

We expect manufacturers and vendors to be honest to us about the products and services they offer and market to us. Our customers expect the same. Honesty is especially crucial during iterative development where a minor course correction early in the schedule can save significant time down the road.

Distributed Agile Development - 2: Managing daily Scrums.

October 5, 2007 by Vaibhav

This is part 2 of an indefinite series of posts centered on using agile techniques in distributed development scenarios. (See also Part 1 on Reinterpreting th Manifesto)

At work, most of our projects have daily Scrums. For some of our projects this simple activity becomes much more laborious because part of the team is in a different time zone. In this post I will write about some key guidelines that we follow to make sure that Scrums remain productive and interesting. Without further ado, here we go:

Distributed Development: How important is face-to-face interaction?

October 4, 2007 by Vaibhav

I work for a software company which has their development center in India. A large portion of the work that we take on has to do with product co-development. These clients are typically ISVs who have active product development teams. They usually partner with us to augment their team sizes to take advantage of the extended daily development cycle. So, for a client who is in the US, for example, our team here takes over from the US team when they come into the office and then hand over to the US team when they leave; this allows almost round-the-clock development.

In such a scenario, where two separate teams are working in close coordination with each other, the right kind interpersonal relationship within team members can really boost productivity and efficiency. So, how do you get a proper relationship going?

Distributed Agile Development - 1: Reinterpreting the manifesto.

September 28, 2007 by Vaibhav

This is Part 1 of an indefinite series of posts centered on the topic of distributed development and using agile methodologies in distributed teams.

Problem
One of the principles of the Agile Manifesto is: “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.” The manifesto was put together in 2001; a long time ago by software industry standard. At that time, offshore development (the primary scenario for distributed development) was beginning to gather momentum, but most such development occurred using the traditional heavy-weight development methodologies.

XP Values: Communication

September 17, 2007 by Artem Marchenko

Extreme Programming values are the primary guidelines to be used whenever it is not clear how to resolve the particular situation. Value of communication is to explicitly state that XP teams consider sharing the status of pretty much everything being important. Even though the useless meetings are not too welcome in any methodology, in general XP teams prefer the risk of over-communicating to under-communicating.