BayAPLN September meeting update

Joshua Kerievsky gave a presentation entitled Agile Brushstrokes in which he made an analogy between software development practices, particularly agile practices, and painting styles. He mapped how certain art styles such as baroque (romanticism) and coco are rich, elaborate, and time consuming just the way traditional software development is; and some agile practices that get too heavy on governance or other controlling/monitoring activities could also get there. Compared also with expressionism, cubism, and impressionism. He mentioned that Impressionist Agile is the point at which the team moves so fast and fluently that aspects such as iterations and backlogs start fading away to allow room for more fluidity, but made sure to point out that to get there it is very important to get the basics well-rooted.

Make sure to assimilate the values and principles, understand fully the methodologies, and practice them for a period of time before venturing into exploring new forms otherwise you may end up in the same--or worse--shape than you were before adopting agile.

The chasm after the chasm

Agile is no longer a competitive advantage. It is at the summit of the Early Majority, meaning, either you do it or be left behind.

Micro-scrumming

Last week I visited Financiera Independencia (a large nation-wide microfinancing company in Mexico) after having trained 18 staff over a month ago. It caught my attention that one of the engineers had on his cubicle storage a micro version of a scrum table. He said it is very useful to him to manage his own tasks following the scrum structure. I thought it was both cool and cute.

A good start, part 2: Get your executives on the same page

After training Bursatec on scrum and itroductory-level agile management, I had the opportunity to give a brief talk to the executive team of Indeval--the intitution in charge of financial assets within the Mexican Stock Exchange. All excecutives were very receptive and discussions were right on target although short due to time limitations. I think there was a good outcome and executives seem interested on learning more.

It was easy to see why Indeval is such a successful enterprise: executive involvement, timely decsion making, front-running, investment on infrastructure and personnel improvement. Their current work towards lean-agile adoption is an important step forward as well.

Their got a good start and I look forward to working with them on stage 2 of their lean-agile adoption consulting for them and providing more training.

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.