David Alfaro: Scrum Costa Rica

Finally I am back!! I apologize for my temporal aloofness!!
I was reading interesting postings at ScrumDevelopment group about Taskboard and how the progress is visualized so I want to share some ideas from our particular experience.

A very engaging aspect of Scrum (and Agile in general) is to find innovative ways for solving problems found in the Retrospective meetings. By the way, the Retrospectives are are rich well of requests and improvement opportunities. By pandering to those requests (and inspecting at the solutions) you will get a tailored improvement to the process.

How do we at Artinsoft do for keeping track of our Sprint progress using the Task Board? Let me explaining it to you by telling you the story.

We have acknowledged that the following phases are needed in order to set a done criteria for the User Stories we committed:

• Design: Meetings to discusses architectural issues,
• Development: Coding
• Application Quality Improvement: Pair Programming and/or Code Review. We prefer Pair Programming.
• Testing: Quality Assurance in the way of Developer or Integration Tests
• Usability Tests

Additionally, a sixth kind of tasks emerged: Environment, as a mean to say that it is a task that encompasses all the environment setup (technology setup) to accomplish the User Story.

Well, in one Retrospective long time ago we pointed out that some User Stories were lacking of enough quality. Why? …. Got it! one or more aforementioned phases were being skipped when planning and implementing features. Why? We EASILY forget to get sure we get them while planning and even implementing. At the second level of “Why?” we realized we needed something catchy to remember those phases and to avoid the constant tendency of realizing them when the deadline is looming, or even worse: never!

We devised a solution: Use a specific color for each kind of task when doing the Sprint Planning and do a Color Distribution Assessment constantly: Do we have enough of all colors for all User Stories? If not, is there a unanimous and intentional awareness of it?

Our Taskboard looks like this:

We always have a good supply of sticky notes next to the TaskBoard, one color stack per phase or kind.

Along the Sticky notes we also have a supply of red round labels. Why so?

In the diagram, I pictured an hypothetical second day of the Sprint, in the Stand Up. The team member David (hence the “D” in the sticky note) delayed more than the recommended (and estimated) one day for that pink task (Usability) he committed to finished. He sticks a red round label to the task and in that way the Task Board is irradiating to the whole team that we are behind of the Sprint schedule.

Again, this has worked for us and fits to our specific circumstances. What do you think about it? Feel free to give me your opinions, all your comments are needed and welcomed!!

“Inertia is a non-quantifiable property of matter by which it remains at rest or in uniform motion in the same straight line unless acted upon by some external force.”

“Sprints are short running races in athletics. They are roughly classified as events in which top runners will not have to “pace themselves”, but can run as fast as possible for the entire distance.”

Let’s mix Physics, Athletics and Software Development: Scrum’s Sprints are meant to have an increment in the team’s metabolism so we can run as fast as possible in a motion near to uniform. Once we start to “run as fast as possible” , we feel the inertia that help us to complete the race. A race against time.

So, let me point out two specific features related to a Sprint:

• In athletics, I normally see that the longer the sprint’s distance is, the lower the racer’s velocity is.
• In physics, gravity acts as the external force that finally stops the uniform motion.

Sprint Duration and Gravity
For a good use of your team’s inertia, you will find out that a two week sprint is the best, look a this post of Tobias Mayer about it. In a three week sprint (or longer), you will see your team not running as fast as possible through all the sprint stretches. Why so? Because external forces start creeping around you. Examples of those forces are: errands and meetings that are not related to your project. The false sensation of “we still have plenty of time to finish this task” is like that gravity that slows you down.

Uncertainty is something to expect. However, in longer sprints, uncertainty become a strong hindering force. In shorter Sprints, uncertainty becomes tamable and even beneficial to get “the agile edge“.

The Sprint Review is as rewarding as winning a race could be. Why do you have those rewards not so often?

Two Weeks Sprints are highly recommended. One week sprints are specially great in those cases when product definition is in its very early stages. In that way, the Product Owner can shape better what he wants by seeing highly frequent increments of the product.

If iterations are so often, you need to keep Planning, Preview and Retrospective meetings in a proportional timeboxing. You can’t have a eight hour Planning Meeting for a One Week sprint.  These meetings are vital and also have to be effective.

Doing Scrum is not running like a mad. It is running effectively little and smart races that are part of a big circuit or championship. That championship is explaining by the Roadmap, which I will post my comments about it very soon.

Keep on tuned!