Share it

Thursday, February 19, 2015

A story of one code review

P1010524


As told by a developer: 

A. and D. told me that the changes that were done to method “E” on class “C” are not needed, and also those two test cases for these changes were not needed. So A. and I removed those. I promoted these changes to my stream.
I don’t really understand why. 
Also A. said that the test “T” should make sure we are asserting that those values are really still there. I thought it did do that, but I guess not.
Also D. suggested an improvement to the code that I don’t fully understand: In class “U” method “D” we can pass the “c” into the “T” method on line 35 and then we don’t need to pass it in on line 39. I didn’t catch exactly what he was saying to do.
I may be missing some other things too.


I hope code was improved as a result of the changes made based on this code review.  But even so, this is not the best way to run code reviews.

P1020736

Sunday, February 8, 2015

Are we having fun yet?


Legoland theme-park has very few Lego creatures. A staff member explained:

- It is a lot of work building them out of small bricks. 

That just sounds backwards. Building with Legos is fun, not work. How can that be?

For the folks working at the Legoland building from Legos is hard work. The resort operates by strict, unbending rules. Cheerful staff, while smiling and genuinely trying to be helpful, is going by a well-memorized script. Thinking on the job is discouraged, and absolutely no initiative or having fun is permitted. These guys look and act like well-behaved robots, which they are payed to be during the work hours. Robots do not have fun, no matter the activity. 

Most of us are not paid to build Legos, but a lot of our jobs can be no less fun and creative than putting little colorful bricks together. It is important to not let rules, scripts, and check-your-humanity-at-the-door culture ruin that fun.

Lego Bricks

Thursday, January 29, 2015

Empowering Agile teams: culture clash. Part II


This is a follow up to the earlier article on this blog "Empowering Agile teams: culture clash".

Agile frameworks empathize empowered teams, flat structures, and meritocracy. Agile transformation is about re-defining who holds authority and responsibility.

Agile approach both allows and requires all participants to care. This is the other side of the struggle. While it is hard for command-and-control management to step away and let the team self-manage, it is even harder for the team members to suddenly start to care.

Power concentrated on the top of the org chart leads to classical principal-agent problem. In many a traditional organization team members have no reason to care about technical quality, steady pace of delivery, or building the product that customers actually want. Management makes decisions about what gets done and how results are accessed, and carries responsibility to the customer. Team members are expected to show up and do what they are told.

Self-managed teams, the corner stone of the Agile organization, have the information, the skills and the power to deliver what the customer wants. To become self-managed and claim that power, the teams also needs a will, and perhaps some incentives, to care about the organizations’ success. Agile transformation is about reminding people of their power, and waking up that will to care and be in control.