Thursday, April 30, 2009

Moprosoft and agile: can do

Back in 2001, the same year the Agile Manifesto was published, the Secretary of The Economy in Mexico created a national program for software development and called it Prosoft. The program's objective was for the software development industry in Mexico to reach levels that compete internationally; an ambitious goal with no execution plan. The initial efforts consisted on evaluating the ISO-9000, ISO 15504, SW-CMM, CMMI and concluded that none were adequate because "they do not comply with the requirements expressed by the national industry". I think it is good that their conclusion was not to use any of those standards or models although I fail to see what the difference would be between software development in Mexico and anywhere else in the planet, besides cultural aspects, to the point of needing a new model to be developed. Writing good software and being effective in developing it should be a basic premise anywhere. As result, the Mexican Association for Quality in Software Engineering (AMCIS) collaborated with the National University of Mexico to develop their own model for the Mexican small and medium size software companies and called it Moprosoft (http://www.comunidadmoprosoft.org.mx/).

In a nutshell, Moprosoft was developed over several years and in 2005 was declared a Norm to be utilized by the software industry in Mexico; it is documented in four volumes and most of its definition is a mapping of ISO/IEC 15504 and SW-CMM to what they considered adequate for software development within the boundaries Prosoft established. One addition they made was the inclusion of a large set of templates that need to be followed to document the design and implementation of the entire development cycle. There is five levels of compliance similar to those on some standards and models. Moprosoft definition is published in four volumes. Last but not least, the ISO is on its final stage of approval to accept it as one more of its standards. At industry level, this meant that the Secretary of The Economy established it as a standard that software development organizations in Mexico must follow and the ripple effect is on with adoption in several countries in Latin America.

Those of you who do agile might be thinking “oh no, it happened again” or something along those lines with respect to the friction dealing with standards and models. The question is how to do agile development under those circumstances. We have learned how to be agile even under an ISO or a CMM/CMMI environment and even some ISO auditors have learned the benefits of accepting documentation a-la-agile. The trick with Moprosoft is that the model not only establishes what to do but also includes detailed definitions on how to do it in the form of templates, think big-process-up-front.

The intention of this blog is to start a discussion and I’ll begin with some observations. Moprosoft adoption has serious disadvantages such as:

  • BPUF. Four volumes of documentation and numerous templates imply a steep learning curve. For a software organization to be ramp up an achieve compliance it will be necessary to delay release dates
  • Agility loss. The high level of detail to document imply that changes in the process will require big process adjustment effort, which will further delay projects and discourage software teams to do improvements over the products developed
  • Slowness. Technologies evolve more rapidly than we can keep up with and having a heavyweight process in place makes it even harder to stay up to date
  • Time to market is compromised. this is critical to business success and the friction that comes with compliance might just be the one thing that makes a company lose against the competition
  • Productivity doesn’t improve. Because this is a repeat-for-each-project activity the friction remains no matter how many projects are developed under the model
  • Creativity loss. Also, the time spent doing compliance work is time that could be much better spend doing creative work for the product being developed

One other aspect to consider is that in practice most teams use models as if they were standards, and that adds even more friction because standards establish a process to be followed whereas models recommend a methodology to take as starting point from which to customize. So, one interesting aspect with Moprosoft is that it was created as a model but it is now about to become a standard!

The best approach to the problem, IMO, is not to follow the model and instead adopt agile practices. For those teams who already have no alternative but to be in compliance my suggestion would be that instead of aiming for level 5 compliance they should be as lightweight as possible to remain within level 3, which is what is considered a good-practice level of compliance and use agile for the planning, estimating, and implementation/test process. Fit the practice within the templates and show auditors how the agile practice works within compliance and how it is also more effective than traditional practices.

Saturday, April 11, 2009

Lean Manufacturing for electric manufacturing companies

My last business trip to Mexico included meetings with two electric manufacturers. One of them had a fairly good level of manufacturing process in place, with an reasonably clean/ordered plant and a good skill set baseline. The other one had a rather chaotic atmosphere: overcrowded in some areas, extremely hot, and with some workers building several different items at the same time. The commonality they have is the quality of their products is hurting them although, and surprisingly, the first factory more than the second one. Although both companies are profitable they lose money in the faulty products they produce and one of them even lost it's most important customer.

Both companies keep ISO compliance but the time/money consuming compliance activities have done little, if anything, to fix their problems. One first one has made efforts to follow JIT and Six Sigma but to no avail. I noticed during the visit to their plants two common denominators. They both hace a genuine interest on improving their processes; and they have received very limited coaching on how to implement and enforce a good manufacturing process.

I gave them a presentation on Lean Manufacturing and how it may help them produce better products and potentially get their workers to be more productive. Their response was enthusiastic and now it is a matter of them deciding if they want to give Lean a shot.