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.
Wednesday, June 5, 2013
Doing Away with Personal Desks
I've previously talked about not having private rooms in an office to make communication better. We're not the first company to do this, but most employees also do not have fixed desks at our company (exception is our president who has a fixed desk so the employees will know when he's in). Employees are freely able to move about and sit with people they are working with. If an employee is working on several projects, he/she will be able to change desks during the day to communicate and work with other members of the project.
We, also, have white boards where people can easy sketch or paste task boards. The noise level isn't too much but if a person wants to concentrate on something, he/she is able to go to a "concentration room" located in another floor. To avoid a person from just locking himself/herself in the room too long, we have a time limit a person can use the room per day.
We have a chat system and each employee also has a mobile phone so users will be able to chat or talk across the room to find where the other person is at.
Managers tend not to always sit with members of a team unless he/she is needed at that time. Nevertheless, since we don't have private rooms and people can just see each other, members can just go up and talk with a manager when needed.
You may have noticed, but we don't have desk cabinets. Each employee is given a locker to put all his/her stuffs in. This discourages writing paper documentations - we value individuals and interactions over paper documentations.
We have a chat system and each employee also has a mobile phone so users will be able to chat or talk across the room to find where the other person is at.
Managers tend not to always sit with members of a team unless he/she is needed at that time. Nevertheless, since we don't have private rooms and people can just see each other, members can just go up and talk with a manager when needed.
You may have noticed, but we don't have desk cabinets. Each employee is given a locker to put all his/her stuffs in. This discourages writing paper documentations - we value individuals and interactions over paper documentations.
Thursday, May 30, 2013
Becoming Agile - Organizational Changes
Organization changes are difficult. As I've written before, the president of the company supports changing the organization to become more agile and I'll be talking about one of the successful project at Agile 2013. Nevertheless, I live is a real world - nothing works the way it should. We have our shares of failures.
The second topic in the Agile Manifesto is "Working software over comprehensive documentation". When this is applied to business, it "Getting things done over planning to get started". It's nice to talk about what others should be doing or what they should do, but I think the Manifesto is more concerned about what "I" can do.
I like Kotter's 8 steps to leading change, but I also like the Dragonfly effect - 1. Focus, 2. Grab Attention, 3. Engage, 4. Take Action. Kotter's steps are too academic while Dragonfly effect is more down to earth and more doable as an individual.
As an example, trying to get organizational change to survive doesn't sound too interesting especially in Japan where most companies still have life-time employment. However, I'm very interested in happiness. If I have become happy and can make everybody around me happy, that would be great! That's what Dragonfly effect is all about - making everybody happy.
Agile is concerned about motivation and I think happy people are more motivated. Maybe instead of trying to change an organization, it may be better to just try to do something that'll make everybody around you happy. I have to admit that I haven't succeed yet in this endeavour yet, but I'm going to give it a try.
Following is a quote by Maya Angelou.
"I've learned that people will forget what you said, people will forget what you did, but people will never forget how you made them feel."
Instead of talking to people, I maybe able to do better by making people happy. Instead of trying to change an organization, it maybe simpler to concentrate on making people happy.
The second topic in the Agile Manifesto is "Working software over comprehensive documentation". When this is applied to business, it "Getting things done over planning to get started". It's nice to talk about what others should be doing or what they should do, but I think the Manifesto is more concerned about what "I" can do.
I like Kotter's 8 steps to leading change, but I also like the Dragonfly effect - 1. Focus, 2. Grab Attention, 3. Engage, 4. Take Action. Kotter's steps are too academic while Dragonfly effect is more down to earth and more doable as an individual.
As an example, trying to get organizational change to survive doesn't sound too interesting especially in Japan where most companies still have life-time employment. However, I'm very interested in happiness. If I have become happy and can make everybody around me happy, that would be great! That's what Dragonfly effect is all about - making everybody happy.
Agile is concerned about motivation and I think happy people are more motivated. Maybe instead of trying to change an organization, it may be better to just try to do something that'll make everybody around you happy. I have to admit that I haven't succeed yet in this endeavour yet, but I'm going to give it a try.
Following is a quote by Maya Angelou.
"I've learned that people will forget what you said, people will forget what you did, but people will never forget how you made them feel."
Instead of talking to people, I maybe able to do better by making people happy. Instead of trying to change an organization, it maybe simpler to concentrate on making people happy.
Wednesday, May 29, 2013
Becoming Agile - Common misconception in agile Scrum
Lean and agile share common concepts including common misunderstanding. I encounted one while reading Eric Ries "The Lean Startup". Near the end of chapter 4, Ries writes "students have an overwhelming temptation to focus on the tactics it illustrates". A little further down, he writes, "The Lean Startup is not a collection of individula tactics. It is a principle approach to new product development. The only way to make sense of its recommendations is to understand the underlying principles that make them work".
Similary, Scrum functions well as a container for other techniques, methodolgies, and practices. Just creating roles prescribed by Scrum and adapting practices is not going a project agile. Neither is trying to hire a consultant who'll come in and give instructions to members. Scrum just makes the problems transparent so that members themselve will be able to see it more clearly and take necessary accords to improve the situation.
A person was complaining about evil of telecommuting and how every company should not allow it. He gave an example of Yahoo.com deciding not to allow telecommuting. He is partially correct. I know of a US software subsidiary in Japan. Unfortunately, the president of the Japanese subsidiary doesn't speak Japanese, have knowledge of Japanese customs, nor understand the Japanese market. That really isn't the main problem - the main problem is that whenever I phoned him, he's always at home. In fact, everybody at the company seems to be at home. To make the matter worse, nobody wants to come to hold a meeting. At a company like this, I don't think telecommuting should be allowed.
Nevertheless, I know of several successful open source companies with members telecommuting. The point is, there's not absolute practice that fits all situations. Project owner and members should decide what works for them the best in their current situation. Lastly, remember that situation changes over time so adjust practices to fit the "current" situation - just don't institute it once and forget about it.
Similary, Scrum functions well as a container for other techniques, methodolgies, and practices. Just creating roles prescribed by Scrum and adapting practices is not going a project agile. Neither is trying to hire a consultant who'll come in and give instructions to members. Scrum just makes the problems transparent so that members themselve will be able to see it more clearly and take necessary accords to improve the situation.
A person was complaining about evil of telecommuting and how every company should not allow it. He gave an example of Yahoo.com deciding not to allow telecommuting. He is partially correct. I know of a US software subsidiary in Japan. Unfortunately, the president of the Japanese subsidiary doesn't speak Japanese, have knowledge of Japanese customs, nor understand the Japanese market. That really isn't the main problem - the main problem is that whenever I phoned him, he's always at home. In fact, everybody at the company seems to be at home. To make the matter worse, nobody wants to come to hold a meeting. At a company like this, I don't think telecommuting should be allowed.
Nevertheless, I know of several successful open source companies with members telecommuting. The point is, there's not absolute practice that fits all situations. Project owner and members should decide what works for them the best in their current situation. Lastly, remember that situation changes over time so adjust practices to fit the "current" situation - just don't institute it once and forget about it.
Tuesday, May 21, 2013
Becoming Agile - How Agile are Japanese IT Companies?
How agile are Japanese companies? Some may think companies in US and Europe are way ahead of Japanese while some other may think the opposite. I can't speak for all the Japanese companies, but I can tell you how it is at a company where I work.
When you're reading, please remember that I work for a very traditional Japanese company - our parent company is an utility company. Think of something like Chesapeake Energy.
To actually be an agile organization, I think it's really necessary to have executive support as well as willingness of members involved in a project. I've seen some "hidden" agile projects but it really doesn't go on the long run because it's nothing stays "hidden" too long. You'll also meet less resistence if there's a executive support.
By executive support, I'm not really talking about an executive just saying he/she supports agile in a project, but more of having an executive supporting organizational transformational to make the business to be agile. Agility is having business benefits rather than a better code in shorter period of time. Projects are just part of the business.
As such, I want to talk about the company where I work before talking about agile projects.
If you visit our office, the first thing you'll probably notice it the posters at the entrance and all over the room. "Be Agile! Think Global!". There's no explanation of "agile" but it makes everybody remember the words "agile" and "global".
It's much better to have no walls between desks - no personal offices for everybody to communicate much better. I sometimes see glass walls that enables everybody to see each other, but we have NO walls. This way, not only can we see each other, we can hear our president talks and he can hear us talking too. I think this builds better trust. It also ables him to more easily walk around the office without too much attention because we're seeing him all the time - it won't be a visit or a tour out from his office.
There's also other activities including wage structure, incentives to adopt agile in projects, paid CSM and CSPO educations. I'll probably be able to explain more on what we're doing and answer questions at the Agile2013 conference.
In Kotter's 8 steps for leading change, we're probably step 4 "Communicating the Vision for Buy-in" because we still have the traditional workflow systems. I think step 5 "Empowering Broad-based Action" and step 6 "Generating Short-term Wins" will come together.
BTW, we also have another slogan - "Invent the Future!".
Subscribe to:
Posts (Atom)