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.