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.