Tuesday, July 23, 2013

Doing agile instead of learning to become agile

We have an overseas work experience program where we sent an employee to work at an oversea company for a year. This isn't to gain technical experience because we select one of our best technical people out - it's to gain experience with working with people from other culture and to experience living in other society.

Japan is an island and have been isolated themselves for a very long time. There was only 1 port in Nagasaki open for foreign trade. This long isolation suddenly came to a stop when a US navy led by Commander Perry demanded Japan to open their ports.

Even with Internet making communication with people from other countries possible, many Japanese do not take opportunity and tend to stick with themselves. The danger of this is that it's difficult to create something non-Japanese would like. I think this is the main cause of several Japanese IT companies creating offices in other countries but closing them after few years.

Back to our work experience program, the first employee came back this month and he did a presentation on what it was like to live in San Francisco and to work in a US company. He didn't use the word "agile" but what he was explaining was what agile is - getting working software rather than doing research, members finding their own tasks and finding for themselves on how to solve it, having short meetings, and people interaction over technology.

In the meantime, many Japanese have been taking Scrum courses. Scrum is one of the popular IT keywords in Japan. Many companies now are being to have Scrum Master and Product Owners. However, they are still having rigorous planning with top - down project structure. They think they are doing agile because they are "using" Scrum.

I beginning to think it's better for more people to go and actually work in a condition where it's agile rather than "trying" to become agile - people don't become agile by learning, they become agile by doing.




Sunday, July 21, 2013

Building Kaizen Teams


The first step in a Kaizen is not to just gather and get some improvement ideas, but to create an environment where everybody wants to contribute.

To sustain agile movement, it is efficient to create self-governing team to check on each other's progress. If you studied about Kaizen, this is really what it is all about it's about having self-governing teams to continuously improve instead.

I used to work for a company which had a top-down structure. They decided to do "Kaizen" but they had bosses tell their subordinate to think up of a way to do some improvements and gave them quota on number of ideas. They got their number of improvement ideas but nobody really was too excited about doing it.

What we are doing is forming a voluntary teams where each can share their ideas with other teams. The teams are meeting half a day each week to share what they have done, the problems they are currently facing, and what they plan to do. Others can provide better ideas.

I've often heard about respecting others. On a Kaizen team, it's not about respecting others but more of respecting human being with all the characteristics whether they be good or bad. Respecting someone tend to create a vertical relationship and that's to be avoided.

Monday, July 15, 2013

When to stop "agile practices" and "agile tools"

I'm seeing many "agile" movements getting started by organizations where people think they are doing agile by renaming roles to those used in Scrum and by using "agile tools". This really isn't agile - the first topic in the Agile Manifesto is "Individuals and interactions over processes and tools". Nevertheless, people accustomed to processes and tools just don't get it. The consultant may know this isn't really agile, but is pressed  to get the "agile movement" started in an organization and found this to be much easier to get results in a shorter time frame.

When I was learning violin, my teacher told me to stop practicing for  a week or two when I got into a bad habit. He told me that trying to "undo" my bad habit isn't going to work because the more I think about it, the more I'll actually do it. It was better to forget what I was doing and to start over.

Recently, I'm beginning to think the same think with agile. Having development team do "devops" by using using "devops tool" such as Chef and not getting operation team involved during development isn't actually devops. During a "standup Scrum daily meeting" sitting down because the meeting is taking too long and it's too tiring to do it standing up is missing the point of "standup meeting".

To get an agile movement started, it's necessary to "accept" these practices at the beginning to get people involved, but it's necessary to stop these when the movement gets started because it really does more harm than good in the long run. I think the big question is when it is best to stop these non-agile practices from being called "agile" or was it better to not accept these as being "agile" in the first place?