Transitional patterns are those that are usually just execute once to change the condition. In team formation, it plays an important part.
Following are 2 transitional patterns:
1. "Sakura" pattern: Most people don't want to be the first one. They're looking over their shoulders to see if there is somebody else doing it. "Sakura" pattern is to appoint somebody to act to be the first one to do something so others will follow.
2. Vague decoy pattern: When there are 2 teams which should be combined to form one team but they don't want to communicate with each other too much, information that one of the team needs is made vague on purpose so they are required to communicate to get the information.
Paper:
http://sourceforge.jp/projects/oss-ja-jpn/downloads/59755/Agile_2013_20130507.pdf/
Slide:
http://sourceforge.jp/projects/oss-ja-jpn/downloads/59755/Adapting_Agile_Methodology_to_Overcome_Social_Differences_20130802.pdf/
Saturday, October 26, 2013
Wednesday, October 9, 2013
DevSales - Developers and Sales uniting together
DevOps are allowing us to build and deploy faster, but are our sales really going up? Making new features available faster may help increase sales if the service already has succeeded somewhat, but what about for startups? What about for all of us who have toiled away development software without seeing none of them really hit?
What startups and most of us need is not a faster way to develop and deploy but a more surer way of making sales on what we develop. In comes DevSales - developers and sales working together to create a software that sales would more easily be able to sales to customers.
Nexlink was a company trying to find a way to make their software sale more. Most companies tries to find features that users would like more - develop for the users is the common concept. However, if you've actually been in a software business, you'll know that this isn't entirely true; selling a software is not just about development, you'll need a good marketing and sales teams.
In most companies, product planning and development teams just develop some software and tell sales to go out and sell. It's up to each sales person to think up on a way to sell it. In most cases, the only motivational reward is sales incentive from a sale.
What if sales team took part in product planning and development? What if sales people were able to provide input to from the beginning so product specification is not solely based on what end-users want but on what sales people wanted so they will able more able to make sales?
DevSales is about uniting development teams and sales teams so sales teams would be more motivated to sell the product. In the end, it's people who actually sell to other people. Focus on people over product - that's what agile is all about.
The result? Nexlink were able to sell to over 100 companies before the product was actually developed.
What startups and most of us need is not a faster way to develop and deploy but a more surer way of making sales on what we develop. In comes DevSales - developers and sales working together to create a software that sales would more easily be able to sales to customers.
Nexlink was a company trying to find a way to make their software sale more. Most companies tries to find features that users would like more - develop for the users is the common concept. However, if you've actually been in a software business, you'll know that this isn't entirely true; selling a software is not just about development, you'll need a good marketing and sales teams.
In most companies, product planning and development teams just develop some software and tell sales to go out and sell. It's up to each sales person to think up on a way to sell it. In most cases, the only motivational reward is sales incentive from a sale.
What if sales team took part in product planning and development? What if sales people were able to provide input to from the beginning so product specification is not solely based on what end-users want but on what sales people wanted so they will able more able to make sales?
DevSales is about uniting development teams and sales teams so sales teams would be more motivated to sell the product. In the end, it's people who actually sell to other people. Focus on people over product - that's what agile is all about.
The result? Nexlink were able to sell to over 100 companies before the product was actually developed.
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.
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?
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?
Saturday, June 15, 2013
Holding Study Groups
It's possible for a person to have agile mindself by himself/herself, but difficult for a project to become agile by oneself unless it's a one person project.
Having executive support, making everybody take classes on agile, promoting people to get agile certification are all good but they have only limited effect. I think it's because it's not too "fun" because they somewhat seems "forced" from somebody from higher up.
Agile is about people to "like" their work. If people only think of "kaizen" as a "work", there's not going to be too useful improvements. In such a circumstance, getting somebody to hold a study group maybe helpful. A study group is a voluntary gathering initiated by a member. The goal of a study group is just not to study with other but to increase community spirit so they would have similar thoughts. As such, a study group is not mandatory and is a mixture of study and play (often in form of going out to a drink afterward).
A company can promote study groups by allowing them to be held in a room at the company and compensation for activities (such as paying a little for members to meet outside the company.)
Having executive support, making everybody take classes on agile, promoting people to get agile certification are all good but they have only limited effect. I think it's because it's not too "fun" because they somewhat seems "forced" from somebody from higher up.
Agile is about people to "like" their work. If people only think of "kaizen" as a "work", there's not going to be too useful improvements. In such a circumstance, getting somebody to hold a study group maybe helpful. A study group is a voluntary gathering initiated by a member. The goal of a study group is just not to study with other but to increase community spirit so they would have similar thoughts. As such, a study group is not mandatory and is a mixture of study and play (often in form of going out to a drink afterward).
A company can promote study groups by allowing them to be held in a room at the company and compensation for activities (such as paying a little for members to meet outside the company.)
Monday, June 10, 2013
Moving beyond "Field of Dreams"
"Field of Dreams" is a terrific movie. If you haven't seen it, it's about a Iowa corn farmer who suddenly hear voice telling him that if he build it, he will come. Under threat of bankruptcy, the farmer plows his corn field to build a baseball field. The movie has a happy ending with people coming to watch baseball. Unfortunately, people don't hear voices too much. Building just based on a "dream" tends to lead to failure.
Nevertheless, I've seen so many companies following this path - "If you build it, it will sell". I haven't really seen any of these companies actually succeed, but they still hold this belief. Some have added "planning" - "If you plan it and build it, it will sell". This is true in some market, but I haven't seen any IT company succeed with this approach either because the market keeps changing.
It seems most human being don't have innate gift of knowing the right thing to build. We waste resources by building wrong things instead of being inefficient in our tasks. If a company is measuring utilization rate of their employee instead of trying to become a more of a learning organization, the company is actually wasting resources.
"Field of Dreams" is a good movie, but I'll rather bet on Lean Startup to start a business.
Nevertheless, I've seen so many companies following this path - "If you build it, it will sell". I haven't really seen any of these companies actually succeed, but they still hold this belief. Some have added "planning" - "If you plan it and build it, it will sell". This is true in some market, but I haven't seen any IT company succeed with this approach either because the market keeps changing.
It seems most human being don't have innate gift of knowing the right thing to build. We waste resources by building wrong things instead of being inefficient in our tasks. If a company is measuring utilization rate of their employee instead of trying to become a more of a learning organization, the company is actually wasting resources.
"Field of Dreams" is a good movie, but I'll rather bet on Lean Startup to start a business.
Subscribe to:
Posts (Atom)