Ivan Sanchez

The first agile principle is about “individuals and interactions over processes and tools”. How can it be managed when people are not all in the same place?

Dave Churchville wrote about it and classified distributed team as:

1. Type A: All developers are together, all customers are remote
2. Type B: Multiple development teams in different locations (but each team is together)
3. Type C: “Virtual” team where nearly everyone works remotely (e.g. from home, in various offices, etc.)

I’ve been working in the last years mostly with Type A and Type C teams, and I believe the main goal in these cases should be improving the communication channels between people to be as effective as if everyone was in the same room. Long story short, this isn’t possible, but we can still make it work.

For remote costumers, the first challenge is having they available to talk with the development team. It can be painful at the beginning because “build software” normally is not their priority, but as long as they realize how their contribution is important to get the best results, they will probably change. And in this case, cellphone, skype, IM or even e-mail will become very important for their collaboration, and both costumer and team should not underrate these communication tools.

Here’s some tips to work with remote costumer:

• Try to build commitment since the first day.
• Ask for their oppinion during the development and show how their collaboration affect the results.
• Define open communication channels. Give preference for phone calls and instant message over e-mail.

The “virtual” team is an extension of the previous scenario, and beside there’s less people together, it can be surpassed easier if the team already realize how communication is important in an agile project. That’s because in this case the communication channels are already open. They can use Skype/IM/e-mail to talk to each other, and even VNC to share their desktops during coding sessions.

This means that if there’s lack of communication among team members, the challenges will be similar to the faced with the costumer. And probably the approaches to fix it will be similar.

After read the 10 Eclipse Navigation Shortcuts Every Java Programmer Should Know, I tried to figure out my favorites shortcuts. I think I would go for:

1. Alt + Shift + X, T: Run Test Unit
2. Ctrl + F11: Run Last Launched
3. Ctrl + Shift + F : Code Format
4. Ctrl + 1: Quick Fix
5. Alt + Shift + R: Rename (refactoring)
6. Ctrl + Shift + T: Open Type
7. Ctrl + Shift + R: Open Resource
8. Ctrl + /: Block comment
9. Ctrl + Alt + Down: Duplicate lines
10. Ctrl + Shift + O: Organize Imports

You can see more shortcuts (or even print them) in the eclipse-tools site.

Software contracts that define all software requirements up-front make your project half-way to failure. The software company will try to do exactly what is in it, and the client will try to believe that none of those requirements will change. And at certain part of the project both will realize they were wrong.

Let’s face it. Software requirements always change. But it doesn’t mean that people got they wrong, it means that after seeing a piece of working software people learn more about it and they will always have a lot of new ideas to improve it.

Let’s see how could we change this situation:

Don’t define requirements in the contract. Well, this sounds obvious, but the problem is that people most of the time confuse software scope with project scope. The project must define clear vision of the goals to achieve, but should let the software change during this period to get to these goals faster.
Define an initial cost and time. Once you have no requirements in your contract, people can argue that you can’t define the project cost and time. That’s wrong too. Even with requirements in your contract, project cost and time are just estimates. So, to create those estimates you can think about requirements (the MoSCoW or the Joelonsoftware technique should help), and you can even keep these written items as initial ideas, but they really should not be written in the contract.
Build the software in short cycles where working software has to be produced. And define that requirements can be changed and the development velocity can be evaluated between those cycles. This way it’s possible to guarantee that changes will not scare the development team and the client will be able to check the team productivity. By the way, that’s other myth about scope-flexible contracts, that people will work less if they don’t have the requirements defined up-front. But this way of thinking ignores the fact that the software company should have interest in get the software done as fast as possible. After all, it’s a way to impress the client and get more contracts.
(Bonus) Create a much smaller contract first. If the contractor could not be convinced that this type of contract is better, propose a smaller one (one month, for example). If after this contract he’s still not convinced, everybody will be able to evaluate the risks and try to come up with another idea.

See, all those items are not too complicated. And if you ever experienced the stress that a traditional software contract can cause, you should really think about adopting a more flexible one.

Today a lot of people wants to become agile. Well, not agile in the sense of mentally or physically quick, but Agile (yes, with capital “A”) as written in the Agile Manifesto. Why? Because it seems like a better way of doing things. This way involves:

• Empower people
• Deliver business value
• Get the client involved
• Embrace changes

Is the word “agile” good enough to represent all this? I don’t know. And to be honest, I think we really shouldn’t care. As long as people get what it stands for, the word “agile” is getting the job done.

These are some good reasons to start a fresh new blog (or at least they are the reason I started this one):

1. Change the focus. In the last year I always came up with ideas for new posts and I didn’t write them because they were not related with my blog’s main topic (software development). Now I can write about other subjects. It’s a new blog after all.

2. Independent hosting. After using Blogger and Wordpress for a while I started to get upset about their limitation. I wanted to be able to edit my theme, use AdSense, try other plug-ins. And I wanted my own address. Free blog services are good for beginners, and they should really move to their own places when decide blogging seriously.

3. Start writing in another language. For those non-native speakers like me, writing in English represents two challenges: 1) Writing decently while improving the language skills; and 2) Interact with people from abroad. It’ll be harder, but I truly believe it will worth the effort.

This post starts a new phase in my blogging career. For the last year I wrote mostly about agile software development and programming techniques. If you’re curious about what I’ve been writing so far, take a look at my other blog (or should I call it “old blog”?) written in Portuguese. And if you want to start a new blog too, I’m using DreamHost and can give some feedback about it.