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.)
Saturday, June 15, 2013
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, 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.
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.

The next thing you'll probably notice is that we're all in one room. There's not president's room (the presiden't desk in the one in the back of the picture). His desk is right in there with everybody else's desk. Having one large room has been traditional in Japanese work environment but most presidents prefers to have their own rooms. It seems Google's Larry Page has his own office - well not here.
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)