La globalización de las comunicaciones y la mejora sustancial en los medios de transporte han logrado que el mundo parezca mas pequeño de lo que era. Esto provoca que los cambios que hace un siglo tomaban una década, hoy en día tomen apenas dos años. La generación de nuestros padres observa con vértigo la velocidad a la que nos adaptamos a los cambios y cuán flexibles nos volvemos. Los métodos de organización del trabajo tradicionales mostraron ser ineficientes para adaptarse al a velocidad requerida por un mercado cada vez mas ávido de productos innovadores.

Un mercado vertiginoso

A nivel de mercado, tradicionalmente un producto que llevaba innovacion tomaba cuando menos dos años en desarrollarse, y su vida útil de mercado promediaba los 10. Hoy en día, con empresas como Microsoft, Google y Apple, observamos que el tiempo de mercado de los productos se ha reducido a niveles temibles. Tomando como ejemplo el iPhone de Apple, cuando salió al mercado en abril de 2007 causó una revolución. Hoy, tres años mas tarde, está a punto de quedar obsoleto por su sucesor, aparato destinado a reemplazarlo completamente ya que apunta al mismo segmento.

Si se habla de software, esta obsolescencia es muy similar, o quizás mayor. Tomando por ejemplo la suite de ofimática Office, encontramos que existieron 5 versiones en 10 años (office 2000, office xp, office 2003, office 2007, office 2010, todas en la primera década del siglo XXI).

Productos como éstos no pueden tener un tiempo de desarrollo largo, porque quedarían obsoletos antes de salir al mercado, y además se desarrollan específicamente pensando en generar la necesidad de reemplazarlos en el corto plazo.

Respuesta metodológica al cambio constante

Ante la constante necesidad del mercado de nuevos e innovadores productos, comienza a desarrollarse a principios de 2000 una nueva manera de organizar el trabajo. Esta se basa en 4 principios básicos que luego serían las bases de técnicas, herramientas y métodos que llevan a la práctica el espíritu de estos principios:

1- Personas e interacciones antes que herramientas y procesos

2- Un producto que funciona antes que una documentación exahustiva

3- La colaboración con el cliente es mas importante que la negociación del contrato

4- Responder al cambio en vez de seguir un plan rígido.

El futuro del desarrollo ágil

La adopción de metodologías ágiles ha trascendido rápidamente el ámbito del software.Está comenzando a ingresar en otras ingenierías mas tradicionales, y en cualquier proceso que necesite una respuesta rápida al cambio. Se logra a través de la agilidad que la industria pueda responder a una necesidad del mercado en un período de tiempo que sería impensado hace 20 años. A medida que se encuentren maneras de articular estos principios a la industria, veremos mas y mas productos innovadores, de alta calidad y que se ajusten mejor a las necesidades del mercado en este momento.

Fuentes:

• Artículo principal: http://knol.google.com/k/desarrollo-ágil-de-software#

• Artículos de apoyo:

  • http://www.monografias.com/trabajos28/agilidad-desarrollo-software-libre/agilidad-desarrollo-software-libre.shtml

  • http://gizmodo.com/5520164/this-is-apples-next-iphone

  • http://en.wikipedia.org/wiki/Agile_management

  • http://en.wikipedia.org/wiki/Scrum_(development)

  • http://en.wikipedia.org/wiki/Microsoft_Office

Carlos Jose is a Scrum implementor, and is available to help you reach the next level of agility in your company.
Carlos Jose's IT Blog

This is the Scrum Manager certification for people that approves the course with the corresponding score.

Tomorrow I’ll continue this post, with more details on the journey that Juan Palacio proposes to “get” scrum.

EDIT: Here we are, Juan and I:

Scrum manager course. Juan Palacio and Carlos Barroso

Carlos Jose is a Scrum implementor, and is available to help you reach the next level of agility in your company.
Carlos Jose's IT Blog

The Scrum Manager course is an approach to scrum that is different of everything I readed before. He focus in the management part, in how to manage your company / department and the relationships of them. All the books I readed in the subject focus in the scrum process himself or, at most, in the project management aspect of the task. Juan gives us a new point of view in management: applying the agile principles to the company as a whole.

While I was listening his speech, it occurs to me that I was doing something of this intuitively, as most of the scrum practices we do before even know what’s agility. This makes me think about a subject that was not investigated yet, the interaction between scrum packs and other groups organized with “traditional” approaches.

As I see, this is the next step of agility, in a path that is yet unknown but promisses much much more.

I’ll continue tomorrow, after the end of the course, and I hope I can publish some pics too.

Carlos Jose is a Scrum implementor, and is available to help you reach the next level of agility in your company.
Carlos Jose's IT Blog

If you have made mistakes in the estimations, you correct them, hopefully early thanks to the burndown chart.  If you are slowed down because you lost a team member, the solution is the same: reestimating and reasigning tasks. But there is some situations when this is not enough.

One monday evening, the working site burned up. Yes. Totally. Computers. All the paper, the scrum board, all the information in paper, everything. The fire is a very good evidence eraser!

Where I live, is not common the offices have a fire extinguishing system, or even a smoke detector or fire alarm. This is a really valuable lesson that we learnt, at a horribly cost. The feeling is something unexplainable, terrible, as I take out some computers with a shovel, from the floor. A stain in the floor and some carbonized wood is all that remains of my workstation, the place was totally black, walls, windows, everything black and with a obnoxious smell.

Now, two weeks ago, I can sit down and write this recap of the work done in order to reengage the work, the team morality and the “flow”.

As always, the customer is first

After extinguishing the fire and see that nobody gets hurt, the first thing I do is tell the customer of this. This only action have two effects: one, the customer was grateful for being informed, and predispose him to help in anything we need. On the other hand, give us some time to recover the software process (and the hardware). The hardware costs weren’t so high, and we can cover it without problems. Fortunately, we have a backup account on dreamhost that allows up to 50Gb, more than enough to save the company software assets. We have on-site backups also, but they burned up to ashes too, along with all the hardware. We can assure to the client that his project will not be delayed so long, and with the organization that scrum gives us, we are convinced enough that we were not lying.

The right people for the job

An important lesson that I learnt a long ago. Don’t try to repair the things yourself, don’t put your people on repairing, scratching walls, painting, or even installing the operating system (except that the want to). Convert this weakness in a strenght, giving your people a couple of days off. This will, again, give you two important benefits: one, you avoid that the people see all the reconstruction  work, believe me, is exhausting just seeing it. And, you get the morale increase because of the unexpected days off.  As soon as possible, hire some contractors to do the job quickly, and use some parts of scrum to manage their work:  came to the site, ask them what they are planning to do today, watch what they had done, and ask them if you can help in any way. Scrum if shmantastic!

The importance of the off-site backups

You don’t appreciate the value of the off-site backups until you have a contingency like this. If we haven’t got this automated backup, we probably lost some valuable information. It seems that the more recent information generated in a project is the most valuable (is this the time for a barroso’s law ?). As we have an automated script to make the rsync backup with the backup server, we havent lost a bit! In addition, you need to have a recovery system that is easy to operate. In my case, I haven’t seen this obstacle until I need the recovery. Anyway, it was just a rsync script et voilà, all the information in place again, but if you can, have this part of the backup automated too.

Team (re)building

Now is an excellent chance to redecorate and refunction the place. You always wanted pouffes ? Small, japanese-style tables ? Pink in the walls ? This is the time of your inner-decorator (not @decorator, though). But this is the moment where the good managers separate from the outstanding managers. Call your team, all of them, and give them the power to decide in the rebuild. Remember all the bibliography about lowering the people turnover ? This will give your team members the opportunity of create roots with the place, and for transitivity, with the company. Remember that your biggest asset is your people, and investing in them will always give you the best return.

Prepairing the return to work

Now that all the furniture and hardware is in place again, let’s talk about the software. Reclaim your backups in your servers, and give your team a day to customize their work environment.  This is not a lost workday, they will spent more time customizing their desktop environment in between the job, distracting them, etc. so allow a day for this.

Call your customer(s) and organize a meeting.

Go!

It’s 08:00 am. You and your team are ready to start the work, but has been so long (a couple of days can be a long time) that nobody remembers what to do. Your new, shiny scrum board is there, but empty. What now ?

I don’t know what’s the right answer, I’ll tell you what I done. Having the customer representative in place again, we started to renegotiate the iterations, the release plan, and anything else affected. We have lost 10 work days,  if you have like me a two-week iteration lenght, this means a full sprint. Considering that the event happens in exactly the middle of the sprint number 3, and we are making a sprint plan in day 6, so we have 4 days of work left. We decide to make a small sprint instead of time shifting. I have commented in another post that we use 2 week sprints, with the sprint planning the first monday and the demonstration in the last friday, giving us the saturday (yes, we work on saturdays, but very lightly) in between to make the sprint post-mortem.

That’s all you need to back on track again. Hopefully, the next planning meeting will be a success, and start the exact day you planned it in the project begining. If you have a good product backlog (and if you are reading to this, you have one), the planning meeting wont have any problems, and everybody will forget the incident in one, at most two sprints.

Conclusion

I hope that this text could help you if you have a situation like this. Even if you don’t following, the recommendations here may save you a lot of money and / or give you some good ideas with your team. I learned a lot with this, but the cost is terribly high, even with the added gain on team strenght and diminished turnover.

Carlos Jose is a Scrum implementor, and is available to help you reach the next level of agility in your company.
Carlos Jose's IT Blog

1- Can be used from the CLI
2- The graphic can be written / modified by the most quantity of tools possible.
3- Use a text-only format. Well, this wasn’t a requirement at first, but becames one when I find this tool

This excellent tool, found here was written by James S. Plank, at the University of Tennessee. In his own words, “Jgraph is a program that takes the description of a graph or graphs as input, and produces a postscript file on the standard output.”. This is an oversimplified description, and soon you will discover why.
Let’s get to work. In order to make a simple guide burndown chart to attach to the wall, for example, we will write a simple text file called burndown.jgr:


newgraph
newcurve 0 26 25 0 linetype solid


That’s it. This is a burndown chart that I can attach to my wall and complement with some color markers while the current sprint runs:

Burndown Chart 1

Well, that isn’t very impressive, right ? First, I will explain the parameters

Let’s add a caption for the graphic and the axes, and ajust a little the scale, so it becames really useful:


newgraph
title : Burndown Chart for project "My Project"
newcurve pts 0 26 25 0 linetype solid
xaxis size 9 label : Days
yaxis size 5 label : Story Points

This give us:

Well, it’s getting better. Now let’s add a real burndown line, and the line that represents the mean of work that have to be accomplished in the current iteration. The code is as follows:

newgraph
title : Burndown Chart for project "My Project"
newcurve pts 0 26 1 25 2 23 9 23 50 0 linetype solid
newcurve pts 0 26 50 0 linetype dotted
xaxis size 9 label : Days
yaxis size 5 label : Story Points

As you can see, we have a dotted line representing the mean work and the line that represent th actual work done in each day. Now, this is all that I need to print and attach to the wall.

Making the source file useful

We are missing the one characteritic that wil make this post useful: the ability to edit the source file with automated tools easily. For doing this, we must make some changes to our last graph file, splitting the newcurve lines like this:

newgraph
title : Burndown Chart for project "My Project"
xaxis size 9 label : Days
yaxis size 5 label : Story Points
newcurve
linetype dotted
pts 0 26
pts 50 0
newcurve
linetype solid
pts 0 26
pts 1 25
pts 2 23
pts 9 23

Note that we have splitted the lines representing the dots in the curve, and rearranged the file a little for automated edition purposes. This is a good time to explain the lines of the graph file:

• newgraph: Start a new graphic
• title: The title of the graphic, located below it
• xaxis: This keyword has two attributes now, the size in inches and the label of the axis.
• yaxis: Same as xaxis but for the vertical one
• newcurve: Start to plot a new curve in this graphic
• linetype: The type of line to plot, in this case a solid line
• pts: Each of this line represents a dot in the graphic. The dots are automatically connected with a line.

You’ll see that I’ve used two linetype keywords, one for each newcurve keyword. This means that I’ll represent the mean burndown time with a dotted line, and the real progress with a solid one. Having one dot per line allows me to edit this file using standard CLI tools. Attached to this post I’ve written a script to manipulate this file, it’s really more a proof of concept than anything else, but it can give you useful ideas.

In my case, I use Trac along with the agiletrac extension to control my process. I can write and attach a script triggered by the actual change in Trac, so the source .jgr file gets modified automatically, and the next day I just print the last version of the document again. I use two burndown charts in my wall: First, the Release burdown chart, with the sum of the agreed stories as the total and the estimated time. The second with *this* iteration burndown, showing tha ammount of work commited to do and the iteration length in the X axis.

Using the tool

If you have already intalled jgraph, go ahead. If not, download and build the source yourself or obtain a precompiled package for your OS. In my case (using Debian GNU/Linux 5.0) I just type:

root@casa:~#  aptitude install jgraph

You will also need ghostscript, a printing command that understand it or the ps2pdf tool. Use your imagination, my way to do the charts is as follow:

charlie@casa:~$ jgraph -P -L burndown.jgr | ps2pdf - burndown.pdf

I will have then the burndown.pdf file containing the plotted graphic with it’s two curves. The -L parameter makes the grapic landscape, and the -P option outputs postscript code instead of encapsulated postscript.

Conclusion

If you are like my and love the CLI, then this is the tool for your scrum burndowns. It’s a little help for your process and one trouble less for the post-standup meeting hour.

If you want more information on the use of the tool, don’t hesitate to write me. Best regards!

The details of this free ebook can be consulted in Safe  Creative under the number 0710030001587.

The book is well organized, recommended to any person who wants to get started with scrum in a guided manner, with proven recipes and the right level of theory, just enough to understant why are we doing what are we doing. Full of cites and references to additional information, provides an excellent starting point to professionals who want to begin with scrum, or are tired and disappointed with the Traditional Project Management methods.

Divided in three parts, begins with the project management dimension, comparing the traditional or predictive project management with the new agile, iteration-oriented project management. The second part is devoted to managers and bosses, mostly trying to use the preexisting knowledge in system theory and process improvement in order to introduce the minimum number of changes to make them agile.

The third and last part is devoted enterily to scrum, showing in order and with detail the model, elements, tools and people’s responsabilities in the process. Like scrum, the books is focused heavily in the people, with a lot of advices and recomendations.

Being a free book, I should recommend it to teach scrum in any level, specially in the enterprise level. And with the fact that is written in spanish, the one book I gave to any spanish-only speaking friend out there.

EDIT: Download the book from here.

Carlos Jose is a Scrum implementor, and is available to help you reach the next level of agility in your company.
Carlos Jose's IT Blog

This will be my diary, where I’ll write all my experiences in this journey, and I hope several things more.

To begin, lets speak abot the negotiation: in order to change some of the corporative manners, your boss / managers must have a lot of confidence in you, because this looks like a big step (and indeed, it is!). In my case, the only point where the managers get a little nervous was when I say that we will not use gantt charts to track this project. The bosses then ask me some method to know what’s the project level of success, then I show them the  burndown charts and explained it’s use, then they remained calmed (for now).

I’ve promised the first demo in exactly 7 days from now. Wow. I’ve been working in this since monday, so a first iteration of 9 workable days, 2 weeks seems reasonable to me.
I’ll be using plain paper to carry out the whole system, I’ve designer myself a scrum board, the history cards and the tasks post-it (not really post-it in my case, but small square pieces of paper). On monday I’ll start using the burndown chart updated to thay day, so the managers can remain happy until the demo presentation.

That’s enough for one day, I’ll continue soon…

Carlos Jose is a Scrum implementor, and is available to help you reach the next level of agility in your company.
Carlos Jose's IT Blog