My first Agile experience: Part 1

At my current job, we are using an Agile methodology called Scrum.
It's my first time, and I wanted to share my experiencies.

Cooperation

The first thing I noticed here is the cooperative spirit of the team. Here are some attitudes you will find:

• I have a problem. Who can help me?
• Joe has a problem. Who can help him?
• I will work with Joe.

• Who knows something about technology X?
• I do. I'll do a presentation for everyone.

• We need to implement user story 157. Joe, Can you do it?
• Sure. And maybe Tim could pair with me so he gets a grasp on the YZQ internals.
  

And you won't find any of these:

• Who wrote this crap?
• This isn't my responsibility.
• This has to be done yesterday.
• I don't have time to tell you how to do your job.

We are a Team, with capital T. The success of our team is the success of its people, and vice-versa.

Consensus

Most of us had to work at some point with an arbitrary deadline set by someone that didn't know about the domain, nor the implementation of a requirement. And changing the estimates after beginning the work was out of the question.

Here, instead, the estimates are set by the people who will actually be involved in developing/testing/deploying the solution (the "pigs").
We use a simple yet very effective technique called Planning Poker. You can read about the details, but the things it accomplishes are:

• Order of magnitude estimation that can be refined later, as opposed to an arbitrary number of hours.
• Real consensus based on discussion, as opposed to both imposed times and false democracy (voting).
• Everyone ends feeling comfortable about the allocated time.

Also, nobody will ever force you to work in an area that you hate or have no experience with. Volunteering is the usual way the tasks get assigned.
And you know what? This actually leds people to request to work in those areas!

Of course sometimes it'll be suggested that you work on those items, but not being forced to do that, in addition to knowing that you can always get help, is a big motivator to improve your weak areas.

Communication

The biggest Agile value, as I see it, is focus on communication.
At one of my previous jobs, team meetings were weekly. That mean they would take more than an hour and implied listening to lots of things that were not relevant at the time mixed with all the announcements for the week.

Now, we have several types of meetings. They are done over the phone, sometimes using netmeeting for desktop sharing. This is not ideal, but we are a distributed team.
Our usual meetings are:

• Scrum. This is done daily, is timeboxed to 10 minutes, and everybody says what they are working on (since the last scrum - until the next scrum), and if they have any blockers they need help resolving.
• Iteration planning. This is done biweekly, at the start of an iteration. Not really timeboxed, but it usually lasts 2 hours at most. We decide what user stories will be included in this iteration, and whether we need to do something differently.
• Iteration retrospective. This is done biweekly, at the end of an iteration. It takes 1 hour, and we discuss the learned lessons from the iteration (things to keep, to stop, to try), our current velocity, etc. It serves as an input to the Iteration planning.
• Planning Poker sessions. These don't have a regular cycle, but are done constantly to keep estimates up to date. They run from 30 minutes to 1 hour.
• Tech Talk. This is done weekly and lasts approximately 1 hour. It's used to share knowledge about technology related topics.

Of course, these regular meetings are not the only ones we have. We try to take advantage of all the channels we have available: phone, IM, email, wiki, netmeeting, face-to-face.
Whenever there's something to discuss or clarify, the relevant people are gathered so the unknowns don't pile up.

Conclusion

What's the end result of all this?
Developing some standard enterprise software becomes both efficient and enjoyable.
Who says you can't have both?

Of course, life is not a bed of roses. In Part 2, I'll write about the things that don't seem to work as they should.

How to "sell" Linux to our families and friends

We've all tried telling grandma not to open that attachment, even if the mail "comes from a friend".
We've all fought with Dell drivers.
We've all cried on the inside when dad complains about not being able to find a button in the new version... that was just moved 20 pixels to the right.

When we got tired of that, we tried to get them to install Linux, which we obviously use at home.
Unfortunately, we tend to use the wrong arguments:

• They don't care if "the source code is public and anybody can change it". Even if they know what source code is, they can't do anything with it.
• They don't care about the four freedoms.
• They don't read, nor are they worried about the EULA.
• They don't care about the license prices as long as it comes with the PC (or a friend/relative -usually yourself) can install it for free or a small fee.
  

Instead, try to focus on the things they DO care about.
And don't just talk about it: show them!

• It comes with everything you need (browser, office programs, etc)
• It usually detects your hardware without the need for external drivers (as long as it's supported)
• The media player just works. No need to worry about codecs.
  
• It's easier to find and install new programs. Just open Adept or Synaptic and search for what you need. Image editor? DVD recorder? Poker game? Expense tracker? you've got it.
  
• Also, installing and uninstalling programs doesn't break the computer. Feel free to play.
  
• Pentium II, 256MB RAM? Sure, more than enough for some distros.
• No viruses. No spyware. No calling the tech guy every few months to clean up the mess.
• Yes, you can try it, no strings attached. Here's the Live CD.
• You can run both. You don't need to erase your hard disk, or anything. And you will still have access to your documents. Still not convinced?

You are welcome to comment on additions to these lists.