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.