I'm currently working on site with client. The other day I had a conversation with one of the project managers and somehow we landed on a topic of inducing a change in organization. Especially, when the change needs to be supported by management and management is not very supportive, because the problem is not very high on the priority list. Depending on the actual environment and type of change involved here are two strategies that might work.

Get allies. Often times you and your fellow colleagues feel the pain, know the problem and see the solution, but management does not really understand what it is that you are trying to solve and therefore is reluctant to support you or allocate funds needed to implement change. What you can do it to get an ally, who shares your vision and is willing to take the problem and solution to the management with you. If two people show up with the same problem, it is easier to get attention and have manager spend time thinking about what you have to say. When you open a meeting you called to resolve this problem with "We've discussed this problem with such and such (and those people are in the room) and we are in agreement that solution would be..." it is much easier to get through manager's internal "why do I care?"

Propose to try. This is based on The Puppy Dog Close approach. Here is how Tim Ferris describes it in The 4-hour Workweek:

The Puppy Dog Close in sales is so named because it is based on the pet store sales approach: If someone likes a puppy but is hesitant to make the life-altering purchase, just offer to let them take the pup home and bring it back of they change their minds. Of course, the return seldom happens.

The Puppy Dog Close is invaluable whenever you face resistance to permanent changes. Get your foot in the door with a "let's just try it once" reversible trial.

There is psychological resistance to make perceivably big decisions without "proper" consideration, which, of course, never happens if the problem does not seem very important to management. By making the change temporary you lower the barrier for amount of consideration on the change. If the change will be for good, most likely no one will question the decision to make it. And, of course, if change for some reason does not bring the relief, you need to be the first to admit it and revert back to older procedures.

What do you do to induce a change in organization?

(Image by Dina Middin)

Recently I discovered that during 2nd International SOA Symposium they published SOA Manifesto. It follows the spirit of the famous Agile Manifesto, which provoked many discussion and debates over the actual meaning of the statements of that manifesto. (Not) surprisingly there are many other manifestos related to software. Here are some to name a few:

• The GNU Manifesto
• The Mozilla Manifesto
• Open Cloud Manifesto

But there is important thing, which puts SOA and Agile manifestos apart from others -- they can not be simply declared by an individual to work. While one can accept, for example,  the GNU Manifesto and act as declared and make a difference. With SOA and Agile you can not manifest something individually -- the team has to embrace these ideas together in order to make them work.

I wonder when (and if) we will move to team manifestos instead on manifestos of individuals.

Have you ever visited a farm? A farm which produces milk, or meat, or even wheat, or corn? If you've been there, I'm sure, you've seen many interesting things all over the place: tools and mechanisms, people and animals. I'm also equally sure, you haven't seen there one thing - variety. Meat farms do not breed cows, pigs, chicken and rabbits. Milk farms do not feature cows together with goats on their premises. Grain farms do not harvest dozens of kind of grain. Instead they specialize in something and they try to stay as uniform as possible with respect to animals they grow, grains they seed and tools they use. Why do they do that? Because variety inevitably means higher costs of operation, but farms can not benefit from variety. For them it makes a lot more sense to have 200 cows of the same kind, than 100 of one and 100 of another since they require different treatment thus rising the cost of support.

On the other hand there are enterprises, which directly benefit from variety - zoos! The more different species you have in the zoo, the more money you can charge for entry tickets, the more visitors you can attract. Yes, operational costs go up as you add more animals - obviously lion requires completely different conditions than pelican, and most likely you will need two different people with different skill sets to look after them. But since you are able to directly sell this variety to customers, it does not undermine your profits.

So, the difference between a farm and a zoo is in their relation to variety: it kills the farm, but propels the zoo.

We see examples of both in our day-to-day lives. We enter farm land, when we rent a car, call a taxi, use corporate computer, eat in McDonald's. We go to zoo, when we shop in the mall, eat in the restaurant, buy a vacation tour.

Look at you business, department, or team and see what you are running - a zoo or a farm. Chances are that you are running a zoo, when you should be running a farm. Run a farm unless you really know how to benefit from variety, which zoo has to offer.

A friend of mine, Alexander Babich, started a new blog about productivity - ProductivyBlog.com.ua (in Ukrainian). I've been following another his another blog for ages and every so often I've learned about new useful tools and approaches, which changed the way I do things and changed for better. If you understand Ukrainian this blog is well worth checking out.

When you work as a Business Analyst, important part you job is to conduct software demos and software reviews with users. User reviews can help a lot to improve quality of your product, but you need to put some effort to ensure efficiency of reviews. Here some some hints on that will help. First and foremost, you go on those review session to hear users' feedback, positive and negative. You want to make users tell you what they like, what functions seem to be overly complex, where performance is not up to par. You do not conduct reviews to impress users, to have them breathlessly admire features you demo. You have to come to those reviews with the only desire to hear your users and make your software even better for them.

Be prepared to hear negative feedback and do not try to defend the approach you took to implement certain feature, when users say they do not like it. If you try to defend people will immediately feel that they are wasting time with you, because you do not care about their feedback and insist on you solution, when they call it wrong. Instead, you want to understand, why they think it is a bad approach, and then propose a solution to that. Audience will appreciate your care.

Make sure that your own feedback and comments were addressed before you show anything to users. Nothing can be more frustrating on the review than hearing something that you already know. At least you need to make sure that review participants are aware that certain areas of the product you review fall out of scope of today's session and they should not pay any significant attention to any gaps there.

Keep audience engaged during the entire review session. When someone makes a couple of comments, he feels like his mission here was accomplished and, as a result, will be less attentive, less willing to interrupt anybody to propose idea. You want to keep everyone in the game, and some tricks from presenter's toolbox can help you with that.

Great talk by Dan Pink at TED about pitfalls of extrinsic stimulus and scientific evidence for intrinsic motivation:

I kind of always felt that way, but now I've got evidence to refer to. Plutarch was right that

The mind is not a vessel to be filled but a fire to be kindled.

You can not stimulate creativity, you can only create environment for it to blossom.

Sounds familiar?

Failure means distrust. Distrust to you about delivering on your promises; distrust in your ability to make a difference; distrust in you taking care. Basically, it is as simple as:

1. Drawing attention to a problem without communication of causes and planned corrective actions.
2. Repeating the same error again (when you do not change anything after step 1).
3. Making problem a habit, when it happens for the 3rd time. Now it is clear for everyone that you do not give a heck about what's going on.

After step 3 there is almost no way to recover.

At the resort I stayed with my family for a vacation, we had breakfast served at 8:00 am. The first time a crowd of about hundred people had to wait for extra 10 minutes till they started serving, I remember my thought "Can happen. Probably, they wanted to please us with something special and underestimated the time."

Waiting in the crowd the next day I thought "Something went terribly wrong here. There must be a serious challenge involved at serving at 8 am."

After the third time nothing could make me come to breakfast at 8 am. I knew they did not care that we all had to wait for 10 extra minutes in a crowded room. I had to find a solution for myself and I did! Thereafter we came to breakfast 10 minutes late. In other situations, when your customers have more flexibility, they will simply quit your service. They will not do that because  there are issues, but because you do not care.

Take care to fix issues your customers face.

I was amazed when I saw this video. Object removal is especially impressive.

And it seems that you already can use similar technology in graphics and imaging products. Check out this Photoshop CS 4 tutorial and Liquid Rescale GIMP plugin.

For this weekend we'll get some reading on the topic of requirements in Agile:

• Writing Good User Stories. Nice concept of INVESTing in user stories.
• Latest description of FDD process. Pay attention to step 2 'Building a Features List'. Apart from precise definition of what a feature is, it introduces an interesting idea of time-boxing for features: a feature should not take more than 2 weeks to implement; if that's not the case - break it down.
• Why I still use use cases. Alistair Cockburn on what can be wrong with user stories.
• Writing Complete User Stories. Nice guide on how to address often perceived problems with user stories.