[# ALM] 1. ALM in 2012, refactorizando our way of working.

Hi,

in these days when the thing is quite complicated, one of the tools we have to move ahead is to improve the way in which we work. Those who work in computer science we know that for quite some time the stereotype of repetitive work from 0900 to 1700, for 30 years on the same site, it is impossible. Jose Manuel Alarcon has written a very good post in this connection, called the "Artisans of knowledge", and one of the points that most highlights in this post is the constant need to improve that we have in our profession.

But beware, many people have misunderstood the message. They think that what we have to do is keep abreast of all new technologies that appear, know all the new products coming out and worship any new trend that promises a bright and peaceful future. When is this only 10% of our new responsibility. 90% Is a little more complicated, it requires that we apply that very often we use which is one meter above our ass (a metro approximately, though there are many cases that the ass is connected to the brain). In the remaining 90% is required to think, is required to learn from the experiences that we propose changes to improve the way in which we work and knowledge we possess.

For example, is very simple to be subscribed to the 10 most influential blogs in the the blogosphere, and follow the 10 cracks think more on different topics of computer science. With spend 60 minutes a day to read these blogs and give you a quick look at twitter every, we can be aware of the news. We changed the form of craftsmanship of our fathers, where you aprendías a profession for life; and we will implement a new premise which is that of constant training. We can have a more advanced social status, where our colleagues we will look at and you may wonder how things: "from where it takes time to keep abreast of everything?"; and we even have a fan club in the best style of Justin Bieber.

However if all this information we read not we process correctly, this way of working is useless. We not only have to read, we have to learn to learn. In the management of software projects is essential to explore new forms of work, new tools and new trends; but it is much more important to understand how we can apply them to a particular scenario to get good results. We need to know, that there are no magic formulas that solve all problems; and also a technique as old as the "refactoring" not only is applicable to developments but also to the way of work and management.

In many cases, there are people/organizations that care to define "a process" which would be useful both for 2-month development projects, to projects of 2 years. That also serves also for teams of 5 people and teams of 200 people; and finally, that it can be used for teams that work all in the same place, as for distributed work teams. When we find ourselves in these cases, it is not uncommon to create this process will be invested in a two-year project. Where, obviously, are the premises on January 1, 2010 not the same that the premises to January 1, 2012, etc. etc. etc.

In the previous case, surely the extreme agilistas will have more than one ulcer and begin to evangelize with the ABC’s ofKent Beck on AGILE and trends of the past 10 years. On the other hand, the lovers of the processes, will be dedicated to destroying the Amazon creating manuals of processes covering 1000 situations will never in any process, and that will then be a book died in some closet organization. Surely there will be a 3rd line of work, which will try to meet the real needs of the person/organization and on the basis thereof; It will create a proposal with a solution. In each case, does not help the proposed solution, but we consider that each a period of time we have to look at the way in which we are working and see if we can improve it.

Worldwide AGILE this is known as a retrospective, and all the agilistas I know are lovers of creating retrospective meetings. However, these badly conducted meetings, only represent a waste of time that little brings to a project and much less to an organization. As I am not going to write about this in this post, will leave the reference to a book that I loved about this item > Agile Retrospectives: Making Good Team Great (http://pragprog.com/book/dlret/agile-retrospectives). In CMMI is also taken into account this model, something the "I" is for Improvement and the "M" Model. For (understood) CMMI, processes, people and tools have the same value in the values triangle. Mind you, that you may like or not, but is a way of organizing and managing it is also valid in many cases. If you want to invest money in a book that will explain you the same as CMMI guides, but with a more human touch, therefore CMMI for Development ®: Guidelines for Process Integration and Product Improvement (http://www.amazon.com/CMMI-Development-Integration-Improvement-Engineering/dp/0321711505/ref=cm_cr_pr_product_top )).

In short, the constant improvement of the way in which we work is as important as the technologies with which we work.What is more, explore new forms of work will help us to improve the guidelines with which we are working and will also not help a broader perspective on how we can work.

But before concluding, I must point out 2 big problems we have in this aspect. On the one hand, be aware of "all the latest" leads to situations like that says Rodrigo Corral in this tweet.

We have failed with Scrum is not a reason to adopt Kanban. The reason must be that Kanban is what best fits your needs.

The mere fact that something fails, and there is an alternative solution does not mean that we should adopt her as soon as possible. How many times I’ve seen what says Rodrigo, I could not resist to respond with a somewhat annoying analogy:

@r_corral do can also be applied > > "I’ve had an accident in car, I now switch to the motorbike;" better learn to drive not?

Finally, the 2nd problem is as follows:

How is that the problems in computer science remain equal today than those we had 20 years ago it possible?

It seems a contradiction, since methodologies such as SCRUM are born by the 1993 beyond, but even today we still have the same problems. I wrote my opinion on this in my book, and I see that the post is a little long, I leave it to pending for another post.

Greetings @ Home

The Bruno

El Bruno on facebook El Bruno o facebook