Ikiru and why some lean-agile projects fail

Many years ago when I was in college I had the opportunity to see the movie Ikiru (生きる) by Akira Kurozawa. As a nice way to finish my work week, I just finished watched it again while having dinner. The story is around an elderly man, Watanebe-san, who is a public office head of department who is diagnosed with terminal cancer. He immediately starts a desperate hunt to recover the 30 years he spend doing nothing as a public official, and after much soul searching he decides to help build a public park at a low income neighborhood. The park is finished shortly before his death, whose cause was unknown to his coworkers and family. At his funeral reception there are about a dozen other public officials of different ranks. It is there where an amazing display of bureaucracy is made clear, and after much drinking and discussing, those who remained at the room came to the realization of the reazon of Watanabe's death. Inspired by it they all determine to make their work as meaningful and really serve the public, only to get back to the same status quo once back to work.

There is a parallel to the story and why some lean-agile projects fail and, worse, why entire organizations fail in the adoption. Simply put, it is very easy to get back to the old habits. Many organizations claim to be doing agile, be it scrum, xp, kanban or whatever else, in reality they still do in good measure the same things they were doing before with minor modifications such as not sitting at their periodic meetings or using post-it notes for their use cases. This more often than not results in even worse dynamics than before the "adoption". If you want your organization to really adopt lean-agile then you have to fully embrace it and be willing to go through what it takes to really make the transition.

Journey to the Centre of the Ministry of the Economy in Mexico: part I

I started traveling to Mexico on business last January with the objective of injecting Agile and Lean practices into Mexican businesses. By the end of my first 12-day trip there I came to the conlusion that way too little was known about these and so instead of focusing on getting some contracts it was necessary to first evangelize about them, thus I decided to change strategies. As result, between January and April I gave 17 presentations on agile-lean at technical and leadership interest groups, associations, academia, and companies. The presentations were received with great enthusiasm and business-level meetings came out from some of them.

I was glad with the outcomes until another reality hit. Numerous Mexican businesses in the high tech, financial, and other white-collar sectors have to face a situation I expected to see on blue-collar sectors only, namely that of government mandated corporate governance such as ISO, CMMI, et-cetera. There is even a recent new regulation under the name of MoProSoft, a mexican model to regulate software development maturity that the Mexican Government approved as a norm for software development. Furthermore, it is undergoing evaluation by ISO to be accepted as a new standard. By now you might be wondering, is MoProSoft a model or a standard? Well, I wonder that myself and haven't got an answer for that yet. What I can indicate is that MoProSoft is, in good measure, a 1:1 mapping between some aspects of ISO and CMMI, plus the addition of a set of templates that need to be followed to fulfill its compliance requirements. Sounds heavy? It is! All those initiatives have been backed up by the Ministry of the Economy in Mexico.

I came to the obvious conclusion that if Agile-Lean are a great alternative to the aforementioned approaches to software development, and if corporate culture in Mexico is still heavily guided by government regulations then the obvious move to be effective was to reach that same government organization to get it to back up agile-lean. So, I took upon myself the quest for it. In March of this year I started talking to people in industry, academia, friends of friends, and so on trailblazing through professional networks, and going through numerous frustrations until by the end of November I got the luck to meet a person who connected me with a congressman directly who is directly connected with the Ministry of the Economy (this part is a great anecdote but I'll hold on to it for an article I'm writing). I met with the congressman, who liked what I have to offer so he asked me to give a presentation to other folks at the Congress building before bringing this to the attention of the Ministry of the Economy; and so I did. As result, those who attended gave to my proposal a thumbs-up and they agree this should be escalated to the Ministry. The congressman asked me to give another presentation, this time to a larger audience to then bring it to the Ministry of the Economy next month.

It's been an arduous journey but I am glad that I finally got to get some progress done before the end of the year. Hope things will move faster next year and that my objective of getting agile-lean be backed up by the Ministry of the Economy so that we can penetrate market more effectively.

I'll make a part-II posting when the time for it comes.

What happened to self-organization and collaboration?

While at yesterday's Agile Journal seminar in Santa Clara CA it called my attention that all presenters who talked about how they do scrum (oh, yes, other practices were mentioned but not talked about) said something that made me question how much self-organization they allow their teams to have. One aspect is that of story assignment. A self organizing team is one that allows its members to self-assign the stories to be implemented during each sprint, considering of course priorities and upon agreement with PO and SM. The teams mentioned at the seminar were given the tasks to implement by the SM.

Since the seminar was primarily to promote software tools the presenters talked about how much the tools have benefited their projects and how great it is for stakeholders to have a tool to go to for, say, write a story to then be assigned. Nobody talked about the importance to maintain face-to-face collaboration. Based on their description it seems the tool ends up being at the center of activities instead of being a means to capture and track the activities to facilitate documentation and reporting. People must continue having close communication and collaboration. A story should be discussed, estimated, and assigned properly.

A failed scrum project in pictures...

What could happen when a company doesn't take agile coaching..
(question is will they take coaching and the necessary training or abandon agile???)