For my second post I’d like to write a little about Scrum. Since it’s such a common topic I’ll only give the basics of the method and some impressions I have of this method compared with previous work experiences.

The Scrum Method

Scrum is a “simple set of practices and rules that encompasses the transparency, inspection and adaptation requirements inherent in empirical process control” [What Is Scrum?, Ken Shwaber].

• Transparency: means that those who control the process must have visibility of the aspects that affect the outcome of the process.
• Inspection: means that unacceptable variances in the process must be detected by inspecting it with enough frequency.
• Adaptation: if the inspector determines that one or more aspects of the process are outside limits and that the result will be unacceptable, he must adjust the process as quickly as possible to minimize further deviation.

Scrums employs an iterative, incremental process where each iteration, called Sprint, is planned at a meeting of the Team with the Product Owner; during the Sprint (which usually has a 1 month length), smaller daily-based iterations occur, where the Teams work to develop the requirements into the product that will be delivered at the end of the Sprint. At the start of every day the Team has a short meeting where three questions must be answered by all of the Team’s members:

- What have you done on this project since the last Daily Scrum meeting?

- What do you plan on doing on this project between now and the next Daily Scrum meeting?

- What impediments are in the way of you meeting your commitments toward this Sprint and this project?

These questions are done to synchronize the work of all team members daily and to schedule any meetings that the Team needs to forward its progress. The team members are inspecting each other work and making adaptations to optimize their chance of meeting their commitments.

At the end of the Sprint, a version with the features developed during the iteration is released; this must be a version with value for the customer, who should be able to put in production the application if he chose to.

First Impressions

Having always work in the past with traditional development processes (or no processes at all), the Scrum method seems an interesting approach that I’m anxious to try.

The first thing that caught my attention is the commitment it’s expected by the Team Members and the freedom it gives to plan how you will accomplish these commitments. Even as other methods and processes dictate that commitment has to be given by Team Members on kick-off meetings, estimation of work, etc. With Scrum you are “exposed” to other team members and the client in a way that you don’t have any other option than do what you said you would do or raise an alarm so everybody is aware of the problems you have to accomplish those commitments.

Another thing that I really want to try is how changes on requirements are handled. This has always been a problem on previous project I’d worked in, the changes on the requirements made by customers have always been badly managed (or not managed at all) and for a developer that many times means a “tied with wire” solution (specially on the projects where time is a critical resource and you have only a few hours to come up with a solution to a big problem). But with such a dynamic approach I think changes on requirements can be handled in a proper way and are no longer a developer suffering issue.

Finally I hope that such a collaborative process will allow me to learn a lot from other team members, and will give me a professional growth as I’d never experienced before.

On my fourth day at the company I decided to write my first entry so here I am… I suppose this post will be very similar to the ones written by other Southies on their first days but I'll try to give my own first impressions .

The first thing that caught my attention this first days is how much importance the company gives to communicate its philosophy of work. In all my previous jobs I always had a day or two for reading a couple of documents about the company and the project I would be working on, and immediately after that I'd start coding. Here it's the opposite thing, first you have to focus on understanding the philosophy the company has and how they expect you to behave (like being proactive, collaborative with teammates, and so on), and for this it's particularly important to read and understand the book “The Seven Habits of Highly Effective People” by Stephen Covey, which I'm currently reading and will be posting an entry on it soon. Then you move your attention to a more “implementative” view of the work, by researching the Scrum method and Test-Driven Development (TDD) and how they are used in the company, specially in my case since I haven't work with either in the past. And only after you have aquired all that knowledge, you start focusing on technology matters, but since I haven't reached that milestone I'll leave the details for a future post [:)].

I hope that either if you are a new Southie as I am, or if you are looking to get a picture on how this company works and how it feels to work in it, this post helps you understand that.