Embracing scrum

I recently gave a series of training courses on scrum and XP to a company in Latin America which, after much negotiation, decided they only needed training but no consulting. The majority of the participants in the courses haven't had any contact with agile or lean in the past, including the 3 managers who were also attending. As I expected, there were 3 kinds of attendants: the enthusiastic ones, the "am here because I was sent to attend" ones, and the skeptic ones. The second kind of attendants got enthusiastic reasonably quickly. The skeptic ones, on the other hand, happened to be the managers and they were having a hard time just being there during most of the first day. Imagine their reactions when I talked about the need to let go of command and control, empowering the team, the "waiter" metaphor about what their role in the team should be, etc.


I should say I admire that non of them gave up on me and continued attending the course. I was trying to figure out a way to make them appreciate the concepts better and decided to do two things. The course includes two or three small exercises, and one 3.5-hour long hands-on scrum session of 4 sprints. During the small exercises I made sure the managers were performing teammate roles instead of leadership roles because I wanted to recall what it is like to be on that side of the group structure. I typically do the same for the scrum exercise because it has proven to give me better results, however in this case I decided to assign the managers as scrum masters and as product owners. The strategy worked great. They were a bit confused at first trying to apply their command and control skills together with other ones they typically use, but throughout the exercise they allowed me to guide them through and by the third sprint all the teams were working fabulously.


The following week I paid a visit to the company and was pleasantly surprised to see one the managers applying things they learned during the training. There was one in particular who had embraced the methodology fully within his team and was pushing his boss hard to convince him that they needed to extend the scope to cover customers. The director agreed and I am now preparing the ground to start giving consulting to them and their customers.

"...b b but I was only being agile"

A company I was working with had an important release to production coming. At the same time the CTO was working on a prototype for a future feature and everybody was clear on that. Since I was in charge of product releases I made sure everything was ready to "push the button" to production the day before the set date and went home with peace of mind, only to arrive to the company the next morning to discover that the push to production had included the feature the CTO was prototyping. Needless to say I was a very unhappy camper, and although the feature didn't break anything it was not production-ready. We had a meeting with executives about an hour later and I brought the issue to everybody's attention, to which the CTO replied that he pushed the feature without consulting anybody because, quote "...b b but I was only being agile", end quote. To which I replied "there is a big difference between being agile and doing something that has absolutel nothing to do with agile and could've createed a permanent scar on the company's reputation!".
Yes, I was quite bold and, yes, everybody had their eyes wide open because I confronted the CTO in a way others wouldn't dare to even consider. The company already had a long history of people trying to cut corners under the excuse of being agile and I knew that if managers and executives did not set the right example then individual contributors would also feel entitled to continue doing so. All features pushed to production from that day on went through the right process.

Partnership with Version One

Shojiki Solutions has partnered with Version One. This will increase que quality of service to my customers. I like the tool because of its ease of use and its slim approach in that it allows users to spend more time doing agile than using the tool. :-)

Writing about agile while confined to avoid getting Swine Flu

Arrived to Mexico City on business last April 27 just two hours short of the WHO’s request to close Mexico's borders due to the swine flu. Not surprising, this has been the less productive of all my business trips: For example my last 10-day trip included 12 meetings and 3 presentations. This 14-day trip I ended up with lots of cancelations and so far have had 3 meetings and if nothing else is cancelled will have one meeting and one presentation before returning to the USA in six days. I even got to experience no traffic in Mexico City, wow! Better be safe than sorry, right? Streets are empty and remind me of a scene from the Spanish movie "Abre Los Ojos", remade as "Vanilla Sky" in English. Fortunately, I am staying at a very safe place, away from public contact and have been feeling as well as usual.

On the bright side, this has given me time to take some rest and do some writing, including an article on agile, standards, and models to be published on the Software Guru magazine this summer, and preparing some more training materials.

Mexico City traffic, vendors and self-organization

Everybody who has ever visited Mexico City for sure remembers the traffic. Think New York City traffic is bad? ...think again! A few decades ago the expressways and highways, although small for USA standards, were fast and a joy to ride. Nowadays traffic is so bad that on a recent day while stuck in bumper-to-bumper traffic on Viaducto (an expressway) I saw locals walking in between lanes selling all sorts of things, from sodas to cigarettes, chewing gum, fruit, etc.; they even had banners posted on the expressway’s walls announcing products and prices.

What amazed me the most was how efficient those people were. Keeping an eye on which lanes were moving more slowly to shift from one to the other so maximize the chances of making a sale. Monitoring the overall traffic to determine if they should step aside for a few minutes or stay put and increase sales. They are also distributed along the road so that each person has a “reasonable number of customers”. They knew intuitively that it was better to disperse along the road when cars where moving at a slow steady pace, and to get closer together but in between different lanes when cars were barely moving. I was amazed by the efficiency of their self-organization.

I started thinking about how I’ve seen development teams be less efficient when they are being managed, thus waiting for a decision-maker to come and order changes, and how much more efficient they become when they self-organize. It is better to identify the demands of task-at-hand, assess the situation, determine a course of action, and act.

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.

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.