I discussed recently changing the process in one of teams in the organization. In theory everything is totally easy. We need to assess current situation, find out what should be changed to improve the way the team works, apply new ideas and support them over some time to make them persistent and then go for a couple of beers and congratulate each other a stunning success.

In this specific situation we have already a couple of ideas which should help. And yes, they include K-word. Yet still the plan is to start as we didn’t know much about the team. We try to act as the hammer wasn’t the only tool in our toolbox, even though we do have a hammer too.

Once we know what is wrong we can apply a cure. And that’s where the hard part begins. If you look at typical pattern of change implementation you will see that the first period after inviting change sucks. People don’t know yet how to work with the new tool, process, rule, you-name-it. Outcomes are likely to be worse than with the old approach. After all, no one said changes are easy.

Now, here is the trick: if you’re trying to implement change you not only strive to overcome typical issues but also have a reluctant team, which doesn’t want any change at all, you’re going to fail.

People will get enough arguments to abandon change and if all they want is to get back to the good old way of doing things they will use this chance. What do you need to do then?

Get more team buy-in.

Actually this is what you should start with. When you assess current situation you talk with team members. If you don’t talk with people your assessment stinks anyway and I don’t want to touch it even with a stick. Use this opportunity to get people buy-in. You will need every single supporter you can have when issues start popping out.

Don’t implement change unless you’re able to convince people it is a reasonable idea which would help them and you really don’t try to make their lives more miserable. Even if you personally are convinced that you have a silver bullet which would change your crappy software house into another Google, only better, you won’t win against people who have to follow your process, execute your idea and deal with all of side effects of a new situation.

When I read discussions about some approach, which appears to be working rather poorly, the first thing which comes to my mind is lack of buy-in among people who are affected by the change. In terms of implementing agile we often forget that problems seen within development team are often triggered outside, likely by management. That’s why, for the purpose of this article, I use term “team” to name everyone whose work will be significantly affected by the change.

Anyway the pattern remains the same. You just need more buy-in. You may need to work on this with development team but you may need to work with management too. Whichever case is true in your situation, go fix it before you start implementing change. That is, unless you find it pleasant to fail.

Recently I speak pretty often about Kanban. It is a great starting point for follow-up lobby discussions about dealing with projects and leading teams. Surprisingly often I answer questions built over similar schema: given this situation or that issue, what would you do?

Since it is close to impossible to give a sure shot answer for question like this we either go deeper or we discuss a set of possible choices. However pretty often I’m left with this vague feeling that discussion, while interesting, was futile since we’ve just scratched the surface of the issue. To deal with the problem we should actually do something about that, not just talk. That is unless we’re Jedi and we can use the Force and tell the problem to disappear.

And there another problem appears. As soon as discussion is finished it isn’t my issue anymore. I don’t work for your organization. I have no power whatsoever to do anything to help you with the issue.

This brings me to the title question. Technically I can work for your organization. For a day. Or a couple of hours. You can make this problem mine. At least temporarily. But the question is whether you want it.

Hiring a consultant is a mixed blessing.

Pros

• Fresh blood. You bring someone with fresh point of view to the team. Pretty often it is a trigger to start discussion about some subjects or to reconsider old ideas which have been dropped for some reason. You can’t cut the argument saying that you’ve already discussed it. The least you have to do is to summarize outcomes of past argument.

• Experience (almost) for free. Coach or consultant brings her experience along. It should be significant. It should be built over a lot of “been there, seen that” situations. And this is something which vast majority of teams lack.

• Expertise. If you don’t make a mistake choosing a consultant you get subject matter expert who can help you to change some specific area of your organization. You may not be able to afford, or want, hiring the person as a regular employee since this whole employment thing is such a long relationship. I mean usually it is so. Consulting gigs don’t have that string attached.

• Not a full-time job. There are tasks which aren’t the part of the job of either of your employees, yet they should be done. You don’t need a skilled agile trainer in the team if you run small software shop but you could use his help, to take the most obvious example.

Cons

• No knowledge about the organization. Outsider by definition doesn’t know all the specifics of your company, thus her advice may be hardly implementable or a bit disconnected from reality. Learning specifics of the organization takes time. Time of consultant is usually counted in dollars. Lots of them.

• Hiring consultant is tricky. Not that it is hard to find one. There are plenty of them. (Or should I say us?) The problem is if you choose the wrong person you waste your money big time. Not only you spend dollars to pay the guy but also you spend time and effort to support his fruitless work.

• Not a full-time job. Consulting gigs are like short-term loans in football (or soccer for those of you who live in US). You get a helping hand but only for a very short time. Then the guy moves along and you’re left with whatever he leaves behind. He doesn’t have live with outcomes of his advice.

When we think about consultants or coaches there is also strong NIH syndrome. People tend to think they can do better by themselves than with help of outsiders. On the other hand if there isn’t strong leadership in organization it may be easier to reach people with the message when it is delivered by trainer, coach or consultant who isn’t the part of the company.

So coming back to the initial point, would you consider hiring an outsider as a helping hand to fix development process, implement new project management approach or work with your leaders?

If yes, please consider your humble author as an option. Either way, share your opinion in comments below.

Um, have I just written a sale pitch?

I have a news for you: IT industry is dominated by men.

- Pawel, why don’t you tell us something we don’t know?

There should be more women in the industry.

Which part of “something we don’t know” you haven’t understood?

Fine, you get the message. I just wonder why you don’t hire more women.

I confess in my current team there is round number of women. Zero. I worked with a few teams like this. And every time one of my goals was to bring a few women to the team. Why? There are a few reasons. I will generalize here and I’m going to do it on purpose. After an hour or so of interview you can’t really say what kind of personality you deal with, so you have to go with your biases and prejudices anyway.

• Women bring different soft skills to team talent pool. They’re usually more open and emotional than men. Do a simple test and recall your last retrospective or check the record from it. Can you see how different arguments were pointed by women than by men?

• Women bring more culture. Pure-men groups tend to change into something like herd of hogs. Bringing a woman on board magically improves everyone’s manners and language. I mean hogs are nice but I wouldn’t like to work with them.

• Women are more responsible. This may be one of my prejudices but I find women more responsible than men. I can hardly recall any woman who came to work having heavy hangover while I have no problems to name a long list on men who did.

• Women are more accountable. It is connected with the previous point. Women tend to treat their duties very seriously. Even when it is something they didn’t personally commit to but rather something their boss expects from them their commitment is usually stronger. And I think here about these unrealistic expectations many poor managers set against their teams too.

• After all, there aren’t many women in the industry so don’t make it even worse.

Having said that, I’m not going to hire woman over man just because of sex. If there’s a significant difference between two candidates I will always choose a better one, not the prettier one. But at the same time every woman entering an interview with me has a small plus for free at the beginning. I guess I could put it as one of recruitment tips but changing your sex isn’t a great tip, is it?

On the other hand I’ve seen enough prejudices working against women to throw my two cents. And I have a question for you: having two similar candidates which one would you choose?

I have a kind of love/hate relationship with headhunters. Few of my friends happen to be headhunters and they helped to find pretty good jobs several people I know. So they can’t be that bad, right?

On the other hand I happen to deal with headhunters in my professional life. I can’t say any of these experiences left me thinking how valuable and helpful these folks can be. I’d even say the opposite.

The other day I was on interview with headhunter. I can understand the guy didn’t check my technical knowledge in details as he just doesn’t know much about all this software development stuff. He’s never written even a single line of code and I doubt if he’s seen any. I’m perfectly fine with that.

What I’m not fine with is how he verified my soft skills. If I say I’m a kind of guru team builder I expect a series of question how do I know and how could I prove this. Like sharing my experience on the worst hire I made, star programmer leaving the team, firing rotten apples, solving serious conflict or whatever. I heard none of these questions. Pretty good summary of the interview was an inquiry about my English. The question was asked in Polish. As every other question during interview. How exactly the guy verified my skills? Would it be that hard?

I may be unfair for some headhunters but they rarely verify any skills of a candidate. They gather some resumes, go through some small talk which only proves the candidate isn’t a complete freak and that’s all. Content of their resume may be a bunch of lies spiced with some wishful thinking.

Rule 1: Don’t outsource competency verification to headhunters.

What you will likely from headhunter get is a bunch of resumes marked “not a freak” and labeled with a price tag. Don’t expect more. Don’t pay for more.

Some time ago I was asked by my former colleague to give detailed references to his prospective employer. As it appeared it was a headhunter who called me. He found my colleague, run him through recruitment process and now, the final stage was gathering references.

I answered a list of questions trying to be honest and fair for both my former colleague and the headhunter. The problem was the headhunter was over-interpreting every word I said. Average meant good, good meant very good, I don’t know meant good or very good etc. At the beginning I didn’t get it. What’s the point?

Well, the point was the job search was almost done, the candidate was almost accepted and the client was almost invoiced for a headhunting service. The only person who could screw it was me, giving too weak references. They wouldn’t allow it to happen. I guess I would have had to say the guy is a thief and drunkard and knows nothing about programming (which obviously wasn’t true) to change the result of reference check.

Rule 2: Don’t outsource reference checking to headhunters.

If you can’t or don’t want to do it by yourself then don’t bother. Just trust your intuition. But if you care at least a bit about reference checking just do it personally. If you want to outsource it you may take your dollars, you’re going to pay for the service, and put them directly into the shredder. It would work equally well.

And yes, in general I’m not a big fan of headhunters, but I often do consider them as an option. Not the favorite one but still. However there are parts of the recruitment process I would never outsource to headhunters. It would be just a waste of money.

What’s your experience with head hunters?

You may also like recruitment series:

• Recruitment Tips
• Avoiding Hiring Mistakes

I have a question for you. And yes this is one of this dumb black-or-white questions which don’t take into consideration the world is just gray.

If you had to choose a vendor among the one which you trust more and the one which can be paid less what would be your choice?

I pretty much expect most of us would say we would choose the trusted one. However what I see everyday people do the opposite. They tend to base on a price heavily.

Of course the question is flawed since it assumes that everything else is equal which is never true. However the message I’m trying to send here is that, despite what we say, we tend to make our decision basing on things we are able to measure. We can easily say this offer is $10000 cheaper than the other; we can easily say that this schedule is a month shorter than that etc.

Unfortunately we can’t say that our trust for the company A is at 5 and for the company B is at 7 (whatever 5 and 7 means). Personally I would probably be able to state that I trust one vendor somewhat more than another but it would be totally personal and your opinion about these companies will likely to differ much. And even if we both agreed we would have hard time trying to describe what exactly “somewhat more trust” means and why it is worth ten thousands more to our decision-makers.

And that’s why I’m not really surprised we tend to act differently than we use to say we’d do. The reason is simple.

Trust isn’t measurable.

Every time we face the task to compare few things we tend to base on aspects we can measure and that’s where trust falls short.

Luckily enough sometimes we are able to forget about this whole comparison thing and decide we just want to do business with a trusted partner. Even if they would be more expensive if we took an effort to compare their offer to others, which we don’t do anyway because, well, we decided to go with these trusted folks in the first place.

With trust in place business relationships tend to be significantly better. And yes, I can explain it. More trust means more transparency. More transparency means more information shared. More information shared means better knowledge about the situation. Better knowledge about the situation means better planning. Better planning means better outcomes. And better outcomes usually strengthen business relationship.

I would choose trust over price. If I stated I’d do it every single time I would lie (I did actually) but when it’s my own call or I’m strong enough to defend the decision trust trumps the price.

Agile Central Europe 2010 is over. It was the first year of the event and I surely hope not the last one especially that I treat it as my home agile event. Here are some thoughts on the conference which will hopefully encourage you to attend it next year.

Organization

The organization was almost flawless. Only issues I could point were minor. When you go to a 2-day conference you actually expect a few things to be pretty much screwed and at AgileCE screw-ups counter ended up with a very low result. Really, I can’t name anything which was really painful or didn’t work at all. Kudos to Paul Klipp and his team for organizing the event.

Sessions

I won’t describe sessions here – you can read about many of them in other AgileCE follow-up posts from Robert Dempsey, Marcin Niebudek or Pierluigi Pugliese. There should be videos on AgileCE site soon too. If I had to point my favorites it would be Rachel Davies speaking about retrospectives and Gwyn Morfey and Laurie Young with their session about simple low-tech solutions to different problems in software development teams, which was by the way also the most energetic presentation of the event.

A variety of different subjects discussed on presentations, at least from my perspective, was a good idea. Personally I’m not overly interested in agile coaching (not an agile coach, at least not yet) or programming techniques (not a developer anymore) but I can’t say I had a problem with finding sessions which had drawn my attention.

Open Space

Even if someone found a slot when nothing interesting would be happening there was always Open Space where everyone could launch a discussion on any subject. And great discussions happened there indeed.

Actually I would have really hard time to decide whether I value higher best presentations of the conference I mention above or Open Space discussions I had. It was also a chance for me to have a cameral follow-up discussion after my own presentation. In short: definitely a great idea.

Summary

Most of opinions I’ve already heard about the conference was enthusiastic on organizational side and at least very positive on merits and I second that. Of course you can’t leave everyone satisfied, so there are folks who would like to see more content which was fresh for them. However being familiar with majority of content should be pretty much expected if you practice a lot of what is preached on this kind of events.

If you use Scrum in your teams for a few years already or you have a couple of years of experience in Kanban chances are good you won’t be surprised by the people sharing their knowledge on these subjects. Personally I didn’t expect any epiphanies and experienced none, but that’s not something I would be disappointed about.

My primary motivation to attend the event was networking and discussion opportunities and I got more of that than I’d expected. Thanks to all who took some time to talk with me – I have a head full of ideas after the conference and looks like I’m not the only one. For some time now Software Project Management can be a bit dominated with ideas and thoughts originated at AgileCE but they aren’t purely agile-related anyway so bear with me.

And if you look for a final recommendation: I’ll be on AgileCE 2011, that’s for sure, and so should you.

I guess you’ve been in this situation: listening to a presentation of one of so called thought-leaders. It is a good presentation – after all, the person you’re listening to wouldn’t be considered a though-leader if he wasn’t able to deliver decent presentation. So you sit there and think “Heck, that’s how things should look like. He knows what he’s talking about. After all he’s a thought-leader. He can be trusted.”

Now imagine, exactly the same things are told you by your colleague next desk. This average girl who doesn’t speak much but is kind of obsessed about self-development and often reads all this strange stuff about project management. What would be your reaction? “You must be kidding me. That’s not going to work. Not in our organization. Oh, this may work in some of these start-ups, but not in our shop. Besides that all these things are just wasting of time.”

Same thing said – different reaction. Why? Well it’s all about authority. Your colleague has none and one of industry celebrities already leads the pack. But authority isn’t something I want to discuss now. You may be surprised but I believe you can actually choose wiser in the latter situation.

I’m going to be iconoclastic for a moment. Thought-leaders are the same people as we are. OK, they did something which brought fame, i.e. they were hanging around when agile manifesto was being signed or something. But since then they probably quit their jobs and started a consulting or training company selling their name and fame.

Don’t get me wrong, I don’t say that’s a bad thing. I’d do exactly the same if I were in their shoes (and I’d really like to be in their shoes). By the way if you want me to quit the job and become outrageously overpriced independent consultant feel free to help in spreading the word about my work here on Software Project Management – I would really appreciate that. But I digress. Starting a consulting business actually is a kind of win-win. There are people willing to pay a guy for sharing his knowledge and he is a knowledgeable person indeed. The problem is he becomes a bit disconnected with real work.

Consulting is theoretical job. You go somewhere, you tell how things should look like in ideal world, you cash your check and you’re done. At the same time people you’ve taught take the knowledge, try to apply it in their specific environment and struggle to get any decent results. They just don’t work in ideal world. And their work is all about practice, not theory.

Don’t treat thought-leaders as they knew it all because they simply don’t. They can have a lot more knowledge and experience than your colleague or yourself, but they likely know nothing about specifics of your situation. In your unique case they may know nothing.

All posts of The Carnival of Agile Bullshit.

Program of Agile Central Europe conference has been announced. The event is held April 8-9 in Krakow, Poland.

Among a list of great speakers you can find my presentation on Kanban. I’m looking forward to see you there.

As one of locals I’m also open to have a couple of beers on Thursday evening with you. Just let me know if you’re interested either here or on Twitter.

A discussion about convincing clients to agile is old already. I believe clients don’t care if you’re agile but to get most of your own agile adoption you usually need to change your client’s approach and that’s exactly where difficulties begin.

Agile is not a key selling-point; often it even makes selling a project harder. But you still want your client to accept the way you’re going to run the project. Why? That’s simple: at the very least you want to avoid BDUF and in the best case you need strong and frequent client’s involvement in the development process. And when we are at it – usually you want an agreement which reflect this kind of cooperation too. An agreement which uses more time and material basis than fixed fee for fixed work approach.

So yes, you need to convince your client to agile. How? Now, that’s a good question. There are a lot of answers, some good, some not-so-good, but I want to focus on one specific which is completely flawed. It goes like that:

“You, as a client, have a freedom to terminate this contract after each iteration, so if the whole thing doesn’t work for you it won’t cost you much.”

Sounds nice. But when I think about projects bigger than very small I hardly imagine a situation when I can see some features in their final versions during early iterations. I mean I can get some GUI doing things which I requested but it will be a mockup. On the other hand I can get the whole feature or two but they will be useless alone. Either way I can’t really say whether you do a good job or just a good show off. So I read it like that:

“You, as a client, have a freedom to terminate this contract after each iteration, but we’ll be halfway through until you’ll be able to say if you’re happy with the cooperation.”

It is still cheaper than it could have been, isn’t it? Well, it isn’t. I’ve already invested some money and, even more important, time. If I change a vendor now I’m losing twice and I have to start over. Odds are I’m already at the point where it’s easier to finish and fix instead of trash the project and start over. Thus I see it more like:

“You, as a client, have freedom to terminate this contract after each iteration, but when you know you want to do that most likely it won’t be cost-effective anyway.”

But I have a choice at least. Not that I would have much use of it but still, it’s my call. Sort of actually. This kind of rules is usually symmetrical. What does it mean? It means in most contracts both sides will have equal right to break it in specific situation. If I, as a vendor, can end cooperation in any given moment, so does my vendor. And we get to the point where:

“We, as a vendor, have freedom to terminate this contract after each iteration, i.e. when we hate your guts or we get a better deal somewhere else, and then you, as a client, are left out in the cold.”

You know what? I screw this kind of freedom. It looks nice on paper but I, as a client, have very limited use of it. At the same time I lose the stick I could use against a vendor which is a new risk for my project. Maybe the risk probability isn’t very high, but its potential impact is devastating. And yes, I’ve seen more cases of vendor abandoning the client than the other way around. And yes, it was a surprise to me at first. And yes, then I got used to it because it isn’t very uncommon.

OK, I admit there are projects which don’t look like that – you can either quickly verify quality of work or you have a comfort to trash the project and start over again even a day before its launch. On the other hand these projects don’t happen very often.

Freedom of agile contracts is overrated. When I wear my client hat I prefer to plan for longer relationship and fix it if it doesn’t work well. Breaking the relation is always hard and costly for client. A couple of iterations worth a month of vendor’s time means much more in terms of client’s preparation to kick the project off and usually a big slip in general plan. For a vendor it’s all easier.

You better don’t try use freedom as an argument to convince clients to agile contracts. At a first glimpse it may look appealing but if you give it more thought it is not.

Do you use freedom as an argument in discussions with your customers? How do they react?

A couple of days ago GMail greeted me differently. Instead of good old inbox I saw big shiny add prompting me to try out Google Buzz. Add I instantly hated. I was all: “Give me my damn inbox back. I don’t even want to seek damn ‘skip this’ link. I hate you Google!”

Wasn’t I supposed to write why I think Google Buzz is good? Well, thanks for reminding me.

Anyway, I finally checked Buzz and while I can’t say at the moment whether it is good product I can already say it is significantly better than recently released Google Wave when it comes to product management.

Product Communication

I learned there is something like Google Buzz because of this annoying advert I mentioned above but the only thing I was looking for then was ‘go to my inbox’ link. I didn’t even read what the heck the thing is all about. But the next thing I noticed was another link in my GMail navigation panel waiting patiently to be clicked. A kind of passive invitation – click me if you’re curious, click me when you’re ready.

With Wave it was a different story. People started writing how cool or how crappy Wave was. I checked it to avoid being out-of-date. If I wasn’t reading what Google is going to bring up next, and face it: most people don’t, I wouldn’t even know there is such thing as Wave.

What does it teaches us when it comes to product management? Make it easy to learn about your new product. Buzz is there, waiting for you to take a look whenever you feel like it. You see it every time you click on your GMail inbox, which many people do very often. Sooner or later you will check what the new product is. If you’re one of these huge corporations which gets a lot of PR you can also base on your fame and let people talk about your product, but it won’t be anywhere as successful as integration with one of your current applications.

First product is just one click away from you all the time. Another requires much reading, finding out what it is and getting an invitation. The latter is hell lot of work for average user.

Leverage Existing Products

Google has Blogger, Google Talk and Picasa, all producing some kind of feeds: posts, status messages and information about new pictures respectively. This may be automatically pushed to Buzz and magically people use the new app seamlessly. My first thought was: Twitter and Facebook statuses should be next. Well, actually Twitter is already integrated (one-way, but still). It just isn’t enabled by design since you have to point Twitter profile to finish integration.

Wave doesn’t integrate with anything. This is yet another stand-alone application. The only thing you can get is email notifications, but that doesn’t help with feeding Wave with any content.

If you launch new product addressed to mass market make people use it without even being aware of the fact. Sure, there aren’t many companies which can pre-configure everything like Google. Apple, Microsoft, maybe a few others. But even then let people do the configuration part only once and make the rest happen automatically. Even when someone isn’t coming back to the app as far as it goes on auto-pilot you build your user base up.

Make It Simple

Buzz copied Facebook and Twitter GUI, which already works great. One textbox where you write something and post/publish/submit button. OK, there’s configuration too which I don’t even try to learn at the moment. Somehow people I know just pop up and I start following them. When I wear my user hat I don’t even care how it happens. What I care is I can follow plenty of my friends and do it easily.

Wave tried to do too many things. Collaboration, conversations, pictures, videos, documents and all the stuff. Wave does many things but neither of them is done well. And worst of all it doesn’t help to link with your friends which, for social media app, should be the single most important goal.

Trying to get the product right at the first time is doomed. Trying to get every possible feature great with first approach is impossible. It’s much better to choose one or two features, do them good enough and then fix them until they’re great. Until then don’t push more half-assed features than you have to. If you do few key things right you don’t need to have everything on board at the day 1.

Summary

I don’t say Buzz is a good product. I don’t know yet. The thing I know is I will use Buzz because I already set custom status messages at Google Talk which should automatically make their way to Buzz. The same way a bunch of my friends will use it. Plenty of them don’t use Twitter or Facebook so this will be the first virtual place where we meet and that’s where Buzz kicks ass from the day 1.

That’s all thanks to very good product management strategy. Much, much better than it was with Google Wave.

Just a couple of days after launch more of my friends use Buzz than Wave. That was left-handed anyway, since it’s pretty easy to have at least 1 user.

It is possible Wave today is better product than Buzz. I’m almost sure it took way more work to bring Wave where it is today than to launch Buzz. And yet, just because of very wise product management, Wave folks should go ask Buzz team for training.

Even if tomorrow I’m going to learn Buzz sucks, I’ll keep coming back because:

• I use it anyway (seamlessly)
• It is at hand all the time
• It is used (seamlessly) by more and more people I care about

None of these things can be told about Wave.

It appears not only the product itself matters but also how you drive it.