Personal Development

Programmers are not Developers

4

I often find myself in situations where people mistakes “programmer” with “developer” or even “developer” with “programmer.”

Before proceeding, I should clarify that my position is to define the programmer as someone who does not specialize in something else other than coding new features based on designs received. Does not help to write or understand the specifications. Does not even occur to write automated tests. Doesn´t work to keep the build up to date. Not to mention the tests. He doesn’t help the client understand their needs or solve their problems. He’s dedicated only to write code.

The current trend in software development and agile methodologies are increasingly realizing the need for multidisciplinary teams, or in other words, people who contribute in various ways to the aim pursued, rather than people who only specialize in one part of the process and do not have a complete view of the project.

Thus, all are equally responsible for achieving the successes and learn from the failures  (if any exists.) The most reasonable solution that some organizations are finding in order to meet the changing business context is to increase their flexibility. It is even logical to deduce that the engagement of specialists in certain areas alone will create many economic losts and even higher costs of communication within the team, which can impair the successful product development.

What is expected of a developer then? The developer is basically who does EVERYTHING but not at the same time (that would be an absurdity), he knows the process from beginning to end and therefore is able to detect “on time” any “misadventure” that might arise. In other words, it would be like those new digital cameras that obtain a panoramic image providing a comprehensive view of the scene photographed.

The tasks of a developer are:

  • Understand the business and the objectives that are being pursued
  • Collaborate with the Product Owner to identify the user stories and acceptance criteria
  • Being part player at the time of assembly and maintenance of the working environment
  • Ensure agile practices for software development as continuous integration, TDD, ATDD
  • Participate in the design of the solution, both logical and architectural

For a better world, the responsibilities of product development must be shared among all those involved in the project, with the exception that the Product Owner does not, in most cases, have the necessary expertise about thechnical topics. Yes, I see the next question is: what about the Scrum Master? My answer is another question: How could the Scrum Master to remove impediments and ensure an adequate team work environment if he doesn’t have the technical expertise required? Quote:

“A detailed and intimate knowledge of how something works posibilidade increases that help the team leader to discover more subtle technical issues that must be addressed” (LaFasto & Larson, When teams work best, 2001, p. 133).

At bottom, though the team is the primary caretaker of product development and of course is best known its development, the Scrum Master should not ignore the aspects of development and in some cases, who should be better known if it is want to avoid communication problems, interpretation and estimation, but above all, if we are to achieve a successful goal.

Returning to the beginning: what we need are real developers who have the tools and practices needed to achieve a successful development process and a high quality product. This does not mean that there is also need for programmers, but do not confuse a developer or “developer” with a simple timer. Even a good programmer could be a bad developer and Scrum Master who has not acquired these tools during their training could possibly be perceived by the development team as lacking the necessary skills to perform their duties.

If only we can understand these fundamental differences, we will have taken another step towards a better working world.

Agile DBAs

0

This article is a Spanish direct translation of the “Programmers” section from the InfoQ Article named “Book Excerpt: Succeeding with Agile: Software Development Using Scrum“, which is about Mike Cohn’s book “Succeeding with Agile: Software Development Using Scrum“.

You can access the Spanish version of this article following this link.

Since the original article is written in English, I see no need to translate it. Please visit the original article here: http://www.infoq.com/articles/cohn-chapter8

Pomodoros

The Pomodoro Technique

14

Pomodoros

Some time ago I wrote an article about the defragment your day technique. From that moment on, I tried implementing it in my day to day without much success, honestly. The issues i found during that time would probably be due to a particularity of the context: I work in a global team, with people from Spain and Chicago, what gave me a hard time grouping the meetings. This definitely ruined the technique.

Then I decided trying another technique which I had on the shelves for a while, that seems very interesting and not too hard to be implemented: The Pomodoro Technique by Francesco Cirillo. Something that really caught my attention on it was the similarities it has with some basis agile practices: incremental planning, ROI prioritization, time-boxing, retrospectives, etc.

In this post I’m not intended to do a detailed analysis of The Pomodoro Technique, I’m just explaining in a very short way how it works so that someone not knowing about that can eventually try it. If anyone would like to go deeper in details and reasons, there’s an excellent PDF on the oficial site and a book called The Pomodoto Technique Illustrated, which I recommend 100% .

Introduction

The Pomodoro Technique has it’s basis on the assumption that time is considered an enemy by many people and the anxiety generated leads the persons towards an inefficient behaviour both in studying or working. The immediate result is: postponing things in time.

The Pomodoro Technique identifies two different aspects that are closely related between each other regarding time:

  • Becoming: An abstract and dimensional aspect of time, which leads into the habit of measuring time (seconds, minutes, hours); the idea of representing time using an axis, the concept of “duration”, the idea of “late”.
  • Event succession: A concret aspect about time. I.e.: We wake-up, we take a shower, we have breakfast, we study, we have lunch, we take a nap, we play, we have dinner and finally we go to bed.

The purpose of The Pomodoro Technique is to provide a simple tool/process to improve the productivity (our own and the team’s one) with the following abilities (between others):

  • Alleviate anxiety linked to Becoming
  • Enhance focus and concentration by cutting down on interruptions
  • Boost motivation and keep it constant
  • Bolster the determination to achieve your goals
    (for the complete list, see the oficial paper)

The Artifacts

There are three different artifacts in the Pomodoro Technique:

  • Activity Inventory: A list where all tasks that needs to be done are recorded while they appear. At the end of the day the ones that were finalized are checked.
  • To-Do Today Sheet: A list of tasks to be done during the day, ordered by priority. And a section called “unplanned and Urgent Tasks” where any unplanned and urgent task is recorder while they appear. These kind of activities can alter the entire day plan.
  • Registry sheet: A place where to record all completed tasks at the end of the day and the amount of Pomodoros (we’ll see what a Pomodoro is shortly) invested on it until completion.

The Pomodoro

The heart of the Tecnique is a kitchen chronometer (from where it takes the Italian name “Pomodoro”, because of its tomato-like shape). This chronometer is used to measure the time-boxes which gives rhythm/iterations used to work on the different tasks during the day.

The Iterations

Called “Pomodoros”, are fixed time periods (30 minutes) from which 25 minutes are dedicated to a task and the 5 minutes remaining used to rest, recreate. Once these 5 minutes are passed a new 25 minutes iteration is started. The tool to measure each of these 25 minutes set is a chronometer with alarm.

Each Pomodoro is indivisable and can’t be interrupted. If for any reason I must interrupt a Pomodoro, then that iteration is considered as voided and a new one must be started from scratch.

Every 4 valid Pomodoros the break is longer: from 15 to 30 minutes.

Note: Each break and it’s lengths have an actual reason; for more details read the oficial paper.

The Tasks and The Process

The tasks that appear, if they are not urgent, need to be registered in the “Task Inventory”. At the beginning of each day all the tasks in which the work will be split between are selected an placed in the “Todo Today” sheet. This plan can be done as part of the first Pomodoro of each day.

For the next Pomodoro I take the first tasks in the “To-do Today” and I focus 100% on it. I can’t take-out the attention during those 25 minutes. This means: not reading e-mails, not chatting, not wasting time. There are several minuted dedicated for that at the end of each iteration.

if the Pomodoro finished before i get to finish the task, then I still have to take the 5 minutes break, no choice. After that I start a new Pomodoro focused on that same task I’ve been working on which is still not finalized.

While I spend the iteration, I need to mark an “X” for each one next to the task I’ve been working on. It’s really important to focus on a single task during each iteration. It the task is too short to dedicate an entire Pomodoro on it, then it should be grouped with other tasks, if the task is still finished before the pomodoro ending, then i should keep working on that task, improving quality until the Pomodoro ends.

If I finish a task during te initial 5 minutes of a Pomodoro, then that iteration should be considered as voided. I don’t record an “X” there and I start a new Pomodoro, moving into the next task.

Simple Example of the Process

Let’s suppose for a while that these are my pending tasks:

Activity Inventory
Write Article about the Pomodoro Technique
Review article grammar
Go to the supermarket
Send e-mails about the event organization
Pay TV clable and car insurance
Build Karaoke list for next Saturday
Translate pomodoro Article into Spanish

At the beginning of the day I choose which are the tasks I’ll be working on and then I record them in the “To-Do Today” sheet. I can dedicate 25 minutes for this plan, using a Pomodoro iteration for it:

To-Do Today – June 7th, 2009
Write Article about the Pomodoro Technique
Review article grammar
Translate pomodoro Article into Spanish

Right after taking the first 5 minutes break, I set my chronometer for 25 minutes and lunch it, that way I’m starting my second Pomodoro, dedicating it to the firat task in the list. After those 25 minutes the alarm of the chronometer will sound, that means the Pomodoro ending; I record an “X” next to the task i’ve been working on (in red below):

To-Do Today – June 7th, 2009
Write Article about the Pomodoro Technique X
Review article grammar
Translate pomodoro Article into Spanish

After another 5 minutes break, I lunch the 25 minutes Pomodoro again, following with the task until completion.
After the first set of 4 Pomodoros, it’s time for a longer break (between 15 and 30 minutes):

To-Do Today – June 7th, 2009
Write Article about the Pomodoro Technique XXXX
Review article grammar
Translate pomodoro Article into Spanish

After that longer breack, I lunch a new Pomodoro. I should continue that way, one 25 minutes Pomodoro after the other, taking a 5 minutes break in between pomodoros and a 15 to 30 minutes break every 4 Pomodoros… until i get to finish the first task, moment in which I cross-over it:

To-Do Today – June 7th, 2009
Write Article about the Pomodoro Technique XXXXXXX
Review article grammar
Translate pomodoro Article into Spanish

And that way, I continue, Pomodoro after Pomodoro until the day finishes:

To-Do Today – June 7th, 2009
Write Article about the Pomodoro Technique XXXXXXX
Review article grammar XX
Translate pomodoro Article into Spanish XXX

Dealing with Interruptions

The interruptions are the most sensible aspect at the time of implementing the Pomodoro technique.

The length of a Pomodoro, 25 minutes, seems short enough to make it possible to resist being distracted by various kinds of interruptions. But experience shows that once you’ve started using the Pomodoro technique, interruptions can become a real problem.
Source: The Pomodoro Technique, by
Francesco Cirillo

The Pomodoro Technique proposes an effective strategy to minimize the amount of interruptions, and to do that, it divides those interruptions in two different categories: Internal and External interruptions, concept that will be addressed in a later post. :)

Important

As said before, this post is just a partial summary of the Pomodoro Technique. To get more knowledge and details I recommend each reader to visit the official site: The Pomodoro Technique by Francesco Cirillo.

Fragmentos

Defragging My Day

1

Fragmentos

A few days ago while I was surfing the Internet, I suddenly reach up to an article called “Defragment your Day” which caught my attention.

Reading it carefully, the base idea is to group the different activities of the day into slots of the same type rather than spreading them randomly –in a chaotic way- all through the day calendar.

It seems to be a very good idea to implement, but I still have some concerns on it, ‘cause it tends to assume the people work at least 3 hs at night after 10PM… what¡¡?? C’mon, I don’t want to spend the rest of my life working from 10pm to 1am every day (plus my normal office hours). Do you?

Ok, but let’s give it credit and assume this is a schema for a very high workload period, like a cutover, an implementation or an annual financial close, etc. which may demand an extra effort from you. So, I’ll try avoiding that 3hours period whenever I can, leaving it to emergency/critical situations. Make sense? I hope so.

Assuming that, it seems to be pretty good. You know what? I’ll try putting it in practice in my day-to-day basis and figure out how it works, which problems I face. Additionally I’ll post here my experience on this.
By the way, the original article was written by Kevin Milden for New Leaders. You can find it following this link: http://newleaders.com/discussions/369-defragment-your-day

Cheers!

Go to Top