A good start, part 1: Include your customers from day one.

I spent the last three days training around 30 people from Bursatec, one of the most important financial systems enterprises in Mexico, which is responsible for the software systems for most of the Mexican stock exchange . The attendants showed lots of interest through their continuous participation, discussions and questions. It was great how inquisitive they were because it showed legitimate interest on learning Agile-Lean, how to use it effectively, and identifying what is beyond its scope. One important area of difficulty they emphasized upon was governance; not from the agile-lean standpoint but rather from the regulatory side in terms of allowing things to be done that way.

Of all things, the one I particularly liked was that for the first time I had a group where participants included the actual customers (2 of them). That gave a great opportunity to both the P.O.s and the customers to better understand how important they are in the success of their projects and the right way to do their part to be successful.

Kudos to Bursatec for a good start!

Company evaluations from latinamerican customers' perspective

One of the first activities with potential customers is to perform a company evaluation and to present a proposal. My first direct contact with potential customers is often through a presentation on agile-lean and the services I offer. As result, they usually request a quote. I offer them two options: either a rather shrink-wrapped quote or a customized solution that will require a company evaluation. The evaluation has a small cost and 75% of that amount is deducted if they accept my consulting services.

Paying for an evaluation is common practice in the USA and customers actually like a lot the option of the cost deduction. My experience in Mexico has been quite different. Most companies do want an evaluation but are reluctant to pay for it, arguing that it should be part of the bid effort to win a contract. I explain to them that the evaluation goes beyond a small set of questions focused only on a project; it is an in-depth analysis of diverse aspects of the company to understand and determine how agile-lean can significantly improve they way they create their products and services, and it will require two to three days worth of work. Furthermore, the evaluation provides them with information that can help them make better decisions on diverse aspects of the company and its projects. Their point of view remains unchanged and I had instances in which they were happy with the evaluation but didn't proceed with giving me a contract.

An strategy that I started applying recently for such case is do just enough to gather the information to generate a good proposal and report to them the results in a meeting (showing spreadsheet tables and diagrams) but don't give them the document itself. If they see value in it and want it then they have to pay for that service; and if by then they want it more detailed then I proceed to continue the evaluation at a deeper level only if payed in advance.

Test-early, test-often

The recent news on instances of iPhone 3GS oveheating and even exploding brings an opportunity to revisit the importance of testing early and testing often. Every software and hardware technologies have aspects that are hard to test and it is not uncommon for a new product to have flaws that need to be fixed shortly after release to market. One reason for it is that the market itself is the best test environment possible. Most problems encountered have to do with either scalability, use flow, or extended usage. The second and third kind can be minimized if the product is used for as long as possible and played with at all times. A very important factor to increase the efficacy of this test-early test-often strategy is to make sure that feature prioritization takes into account risk-value factor. What this means is that the features that add more value and are of higher risk should be developed first so that the level of risk decreases over time thanks to intensive and extensive testing.

This is a great time for Mexican enterprises to invest on technology

Carlos Slim, a mexican entrepreneur and one of the richest men in the world, invited Mexican entrepreneurs to invest and to be prepared for the recovery in the economy. Carlos said that this and next year are a great time to invest (quoting him: "Creo quye este año y el que entra son buena época para invertir"). He also pointed out that technology is a key industry on which to invest.

Click here or here for more information.

North BayAPLN August meeting note

I'm back home from this month's North BayAPLN meeting, which took place at the Salesforce building in Market St, San Francisco. David Chilcott, principal at Outformations, gave a presentation on Effective agile meetings. The premise is to apply lean thinking and to extrapolate scrum practices to the way we plan and conduct meetings, and that by doing so meetings become cost effective and productive.

David suggests to manage a meeting as a sprint where the agenda is the backlog, an agenda item a feature, the desired outcome a user story, the agenda item owner is the product owner, etc.. Amongst other things he also talked about having roles and responsibilities within the meeting attendants, which I think is cool because not only the roles can rotate bu also because, and this is my point of view, is a subtle way to get attendants more involved and as result more attentive and productive. His presentation is available at the Outformations website.

Same as with agile-lean, most of what effective agile meetings is about is actually common sense. And as with agile-lean, even being common sense meetings are rarely planned and done right (or just good enough, if you know what I mean) until it is presented in a "formal" way.

SG article on Agile-lean with standards and models

Software Guru published my article on agile-lean with standards and models, which has two objectives. I try to clarify the distinction between standards, models, and values because I often see people use them as if they meant the same and because they are used the wrong way in practice. I also indicate some ways in which agile-lean can be used in enterprises that require governance under a standard or a model.

The contents of the article published are edited from the original article I sent, which is often the case when publishing articles on a magazine. For those of you who would like to read the original you can find it on my website's documents page under the title:

• Spanish version: "Beneficiando estándares y modelos mediante agile-lean"
• English version: "Agile-lean benefits standards and models"
  

The importance of good software development in Financial Institutions

Mario Sandoval, president of the AMFE (Asociación Mexicana de Entidades Financieras Especializadas) announced that real state development is key to reactivate the financial market. On a similar note, Stefano M. Stoppani, Principal Director or CRIFMexico and Regional Director for Latinamerica, mentioned back in February that proactive fianancial management infrastructure (for payments) requires the usage of four aspects to allow for the right decisions to be made and for efficient execution:

• software
• processes and organization
• data
• analysis

What his means for us is that Agile-lean management and software development, if implemented, can play a crucial role in all of them.

On the software side we have methodologies such as scrum, XP, etc. that increase the efficiency of teams and the overall quality of the software generated. On the process and organization side we have agile-lean project management which creates a better structure for all stakeholders, including customers, to collaborate and make decisions. Agile databases enables data modeling and their implementation to be done more effectively. Good modeling is crucial to good analysis and agile modeling provides waste-elimination ways to do so without consuming vast amounts of time and resources.

Partnership with Nagarro

The partnership with Nagarro was finalized last June 6. Nagarro (http://www.nagarro.com/) is an outsourcing company with offices in the USA amd Europe, and with software development facilities primarily in India. The partnership benefits Nagarro as a new opportunity to start penetrating the Latin American market. It allows Shojiki Solutions to offer high caliber outsourcing services to its customers in the USA and Latin America.

Jim Highsmith's new book

I had the opportunity to meet Jim Highsmith at the Marriott Hotel in Mexico City's Reforma, where he gave a course on Agile Project Management through the Cutter Consortium. Jim is a very enjoyable person with a great sense of humor and enough anecdotes on agile to entertain people for weeks.

Started reading the recently published second edition of his book Agile Project Management: Creating Innovative Products. This book is to become a must-read for all people interested on Agile, whether or not they already practice it. It covers from the basics to in-depth aspects of project management that are of high concern to enterprises of any size. The focus is very practical and it is organized in a way that introduces people new to APM in a fluent way. The first portion of the book, chapters 1 to 5, introduces some practical principles and a model as a means of introduction. The second part, chapters 6 to 10 explains the different phases in which a project can be structured. The third part focuses on scalability, governance, cost, schedule, and scope; all of them issues of high concern for companies considering agile adoption. The final chapter discusses the need for a shift in thinking about how we develop products.

Reading this book will save you the need to read a large amount of other literature oh the same subject.

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.