Comments on: The Kanban Story: What We Do and What We Don’t Do http://blog.brodzinski.com/2009/11/kanban-story-what-we-do-and-what-we.html Dealing with software projects in real life Fri, 10 Feb 2012 19:07:34 +0000 hourly 1 http://wordpress.org/?v=3.3 By: Pawel Brodzinski http://blog.brodzinski.com/2009/11/kanban-story-what-we-do-and-what-we.html#comment-34913 Pawel Brodzinski Fri, 06 May 2011 09:58:40 +0000 http://blog.brodzinski.com/2009/11/the-kanban-story-what-we-do-and-what-we-don%e2%80%99t-do.html#comment-34913 @Tomek - I'd say that objections were pretty typical. People didn't want to "waste" time reviewing something which already works. They didn't expect to find real issues, except of some formatting glitches and they were afraid of having other tasks (code review) besides their regular stuff and same deadlines. I'd say that code review is one of those rather unintuitive practices - unless you try it and get it well it's really hard to get people jump on the bandwagon. I also think atmosphere in the team is crucial here since as long as people treat code review as potential attack on themselves you don't even have a chance to get it working. @Tomek – I’d say that objections were pretty typical. People didn’t want to “waste” time reviewing something which already works. They didn’t expect to find real issues, except of some formatting glitches and they were afraid of having other tasks (code review) besides their regular stuff and same deadlines.

I’d say that code review is one of those rather unintuitive practices – unless you try it and get it well it’s really hard to get people jump on the bandwagon.

I also think atmosphere in the team is crucial here since as long as people treat code review as potential attack on themselves you don’t even have a chance to get it working.

]]> By: Tomek http://blog.brodzinski.com/2009/11/kanban-story-what-we-do-and-what-we.html#comment-34911 Tomek Fri, 06 May 2011 08:44:01 +0000 http://blog.brodzinski.com/2009/11/the-kanban-story-what-we-do-and-what-we-don%e2%80%99t-do.html#comment-34911 Pawel, First of all, I did not realise the post id 1,5 year old. Somehow I'm glad to hear that the team has changed their mind on code reviews. :) Anyway, my main concern was why developers were against it. BTW. Keep on blogging, you are doing great job! -- Cheers, Tomek Pawel,

First of all, I did not realise the post id 1,5 year old.

Somehow I’m glad to hear that the team has changed their mind on code reviews. :)

Anyway, my main concern was why developers were against it.

BTW. Keep on blogging, you are doing great job!

–
Cheers,
Tomek

]]> By: Pawel Brodzinski http://blog.brodzinski.com/2009/11/kanban-story-what-we-do-and-what-we.html#comment-34891 Pawel Brodzinski Thu, 05 May 2011 22:14:10 +0000 http://blog.brodzinski.com/2009/11/the-kanban-story-what-we-do-and-what-we-don%e2%80%99t-do.html#comment-34891 @Tomek - Actually it has changed over time. We evolved and the team has changed their views on code review. You didn't expect we stayed with what we had year and a half ago, did you? Anyway the longer I think about it the more I'm convinced that we did have some kind of code review. Since we had collective code ownership (it isn't on the list as it came up as sort of surprise for us) developers were often working on the code not built by themselves. So each time they were basically starting with code review and refactoring. This realization might be the reason to change the stance against code review. In terms of convincing people to any practice, not only code reviews, I don't believe in extrinsic motivations. Since I wasn't able to convince developers at that moment and I definitely didn't want to take the power of deciding on engineering practices from them it was really no-brainer. The only option left was waiting until developers change their attitude and they actually did. Maybe tricking them into doing some informal code reviews helped, but does it really matter? @Tomek – Actually it has changed over time. We evolved and the team has changed their views on code review. You didn’t expect we stayed with what we had year and a half ago, did you?

Anyway the longer I think about it the more I’m convinced that we did have some kind of code review. Since we had collective code ownership (it isn’t on the list as it came up as sort of surprise for us) developers were often working on the code not built by themselves. So each time they were basically starting with code review and refactoring.

This realization might be the reason to change the stance against code review.

In terms of convincing people to any practice, not only code reviews, I don’t believe in extrinsic motivations. Since I wasn’t able to convince developers at that moment and I definitely didn’t want to take the power of deciding on engineering practices from them it was really no-brainer.

The only option left was waiting until developers change their attitude and they actually did. Maybe tricking them into doing some informal code reviews helped, but does it really matter?

]]> By: Tomek http://blog.brodzinski.com/2009/11/kanban-story-what-we-do-and-what-we.html#comment-34868 Tomek Thu, 05 May 2011 09:17:55 +0000 http://blog.brodzinski.com/2009/11/the-kanban-story-what-we-do-and-what-we-don%e2%80%99t-do.html#comment-34868 Paweł, I'm surprised that your team is against code reviews. When we worked at our Definition of Done (http://bit.ly/lnap53) it was my teammates who added point on peer code reviews because they recognized that it is a great way of: - learning about the code and understanding all aspects of the project, - finding bugs and spotting things that will hurt our development later In short they understand that having code reviews is beneficial mostly for them. Personally I believe having peer code reviews in your Definition of Done is essential for providing high quality code and I'm really happy my teammates share this opinion. I have a problem with understanding the reasons why developers vote against it. Don't they like feedback on what they do? Alas, I have no idea how to make someone want to have a code review if he/she does not feel like this. ...have you tried bribing them? ;) -- Cheers, Tomek Kaczanowski Paweł,

I’m surprised that your team is against code reviews. When we worked at our Definition of Done (http://bit.ly/lnap53) it was my teammates who added point on peer code reviews because they recognized that it is a great way of:
– learning about the code and understanding all aspects of the project,
– finding bugs and spotting things that will hurt our development later
In short they understand that having code reviews is beneficial mostly for them. Personally I believe having peer code reviews in your Definition of Done is essential for providing high quality code and I’m really happy my teammates share this opinion.

I have a problem with understanding the reasons why developers vote against it. Don’t they like feedback on what they do?

Alas, I have no idea how to make someone want to have a code review if he/she does not feel like this. …have you tried bribing them? ;)

–
Cheers,
Tomek Kaczanowski

]]> By: Pawel Brodzinski http://blog.brodzinski.com/2009/11/kanban-story-what-we-do-and-what-we.html#comment-2509 Pawel Brodzinski Wed, 23 Dec 2009 19:50:20 +0000 http://blog.brodzinski.com/2009/11/the-kanban-story-what-we-do-and-what-we-don%e2%80%99t-do.html#comment-2509 Joshua, Yes, if you want to achieve success implementing new practice you need to let them believe or make them believe in it. Otherwise you'll fail. And yes, if you want to make them believe it's all about leadership. Joshua,

Yes, if you want to achieve success implementing new practice you need to let them believe or make them believe in it. Otherwise you’ll fail. And yes, if you want to make them believe it’s all about leadership.

]]> By: Joshua Lewis http://blog.brodzinski.com/2009/11/kanban-story-what-we-do-and-what-we.html#comment-2504 Joshua Lewis Wed, 23 Dec 2009 12:52:18 +0000 http://blog.brodzinski.com/2009/11/the-kanban-story-what-we-do-and-what-we-don%e2%80%99t-do.html#comment-2504 True, but that's true of any adoption. You've got to make the developers (and others in the team) want to adopt the technique, otherwise the adoption will fail. I believe this is an issue of leadership, as well as an issue of adopting techniques for the wrong reasons (i.e. pushing new techniques into an environment, instead of pulling them based on need and value). True, but that’s true of any adoption. You’ve got to make the developers (and others in the team) want to adopt the technique, otherwise the adoption will fail. I believe this is an issue of leadership, as well as an issue of adopting techniques for the wrong reasons (i.e. pushing new techniques into an environment, instead of pulling them based on need and value).

]]> By: Pawel Brodzinski http://blog.brodzinski.com/2009/11/kanban-story-what-we-do-and-what-we.html#comment-2463 Pawel Brodzinski Mon, 30 Nov 2009 22:43:40 +0000 http://blog.brodzinski.com/2009/11/the-kanban-story-what-we-do-and-what-we-don%e2%80%99t-do.html#comment-2463 Odds are we'll give it another try soon, but I'm not pushing our developers here. I've told what <i>I</i> think about code review a hundred times but it's all about what <i>they</i> think. Odds are we'll give it another try soon, but I'm not pushing our developers here. I've told what I think about code review a hundred times but it's all about what they think.

]]> By: gsporar http://blog.brodzinski.com/2009/11/kanban-story-what-we-do-and-what-we.html#comment-2462 gsporar Mon, 30 Nov 2009 22:33:15 +0000 http://blog.brodzinski.com/2009/11/the-kanban-story-what-we-do-and-what-we-don%e2%80%99t-do.html#comment-2462 Agreed about "As long as developers won't want to do code review I'm not going to force them."<br /><br />If people don't want to do something and you force it on them anyway, it will fail.<br /><br />FWIW, if you want to give it another go, some tips on dealing with objections here: http://smartbear.com/docs/CodeReviewSocialEffects.pdf Agreed about "As long as developers won't want to do code review I'm not going to force them."

If people don't want to do something and you force it on them anyway, it will fail.

FWIW, if you want to give it another go, some tips on dealing with objections here: http://smartbear.com/docs/CodeReviewSocialEffects.pdf

]]>