There was an error in this gadget

Sunday, August 16, 2015

Make your code reviews Agile

When discussing dealing with technical debt, fragile and buggy code base, and improving quality of the technical community, code reviews are a popular suggestion. Code reviews sound wonderful in theory: a junior or simply not-so-good programmer presents his work for review to an experienced grander-than-thou colleague, receives excellent suggestions within one hour, and another hour later all suggestions are implemented and the code transforms from nasty to near-perfect.

Enter reality. Thorough review of non-trivial code takes a long time. It is becoming increasingly harder to do a quality review as the time needed for the review increases. The pressure to provide a quality review suggests that more time is needed, and more time spent in review leads to poorer reviews, creating a downward spiral leading to deadlock.

Team dynamics are also affected. Giving a small number of reviewers the authority to dictate changes in work they are barely familiar with, without much feedback on the outcome of those changes, reinforces the bad habits of the reviewers and further entrenches their biases into the codebase. People required to accept suggestions without a possibility of challenge or feedback soon start to despise the reviews, the reviewers, and the suggestions. Neither reviewers nor authors feel responsible for the quality of the end results: reviewers because they only spent a little time reviewing, and authors because they were forced to make changes against their judgement.

So, are code reviews doomed to fail?

For code reviews to be a successful code-quality tool, consider an Agile approach. Make code reviews small and nimble, and have the entire team in charge of making, accepting and implementing generated suggestions.

That means everybody reviews everybody else’s code, in tiny little chunks. No formal meeting should be required. Everybody is invited and encouraged to generate improvement suggestions on all other team member’s work – and expected to defend their ideas. There is no separation of roles into those who critique, and those who are being critiqued. All team members are required to ask for and work with peer feedback.

Thursday, July 23, 2015

Successful remote teams

In this day and age of total technological connectedness working from home seems like a no-brainer. There is email that we check every passing second, the smartphone that can reach us anywhere anytime, and increasingly sophisticated tools that allow sharing any kind of elegantly structured and totally chaotic data across every imaginable divide.

Yet, telecommuting remains rare, and remote projects remain hard. Outsourcing, in its more typical implementations, fails spectacularly and often. Organizations’ worst performers are often found among those “working from home”. (Best performers work from home, too, but that’s a different blog post.)

Overall, distributed groups face higher challenges and more risks on the way to becoming strong, coherent teams. Remote contributors must strive harder to successfully work together with others, compared to the regular folks who show up to the office every day.

For a team to be successful, members must share a vision, a flow, sense of connectedness that allows to think and make decisions together while maintaining unique perspectives.People on successful, productive teams interact many times a day to maintain working relationships. These interactions can be small or profound, like a quick ‘hello’ in a hallway or a heated discussion over lunch. More importantly, such exchanges are typically informal, unscheduled, and “just happen” – and they are absolutely essential to keeping the team in great shape.

Successful distributed teams have the technological means to have these interactions, too – but the opportunities do not ‘present themselves’. When other team members are not within eyesight, it takes conscious, deliberate effort to think pick up the phone, start up an IM conversation, or send an email. It is even harder to regularly take the time to share a joke, a story, something that’s not immediately essential for the work at hand, but serves a more long-term purpose of maintaining team spirit.

People who work remotely regularly and with great success, have made these kinds of intentional “extra” interactions part of their regular routine. The same way mature teams, organizations and their members produce high-quality results, mature distributed teams, organizations and their members make sure to stay connected and engage in lots of team interactions.

The maturity and effort required for a productive, successful remote working relationship may or may not be visible to a typical regular office worker Joe, who is having grand visions of working from home in his or hers pajamas. 

Tuesday, June 23, 2015

Scrum in TV shows and in real life

In an old episode of HBO “Silicon Valley” show, a soft-spoken MBA-bearing non-technical dude introduces Scrum to the hard-charging engineering team by presenting them with a Scrum board. The purpose of the system is declared to be “visibility into who is working on what”. As it becomes clear in the next 30 seconds, the actual value the team gets out of using the Scrum board (and, by extension, Scrum) appears to be the competition between the engineers who appear to work harder and faster on their separate stories to one-up each other.

So what is Scrum, and what does it do? offers this definition: “Scrum is a management and control process that cuts through complexity to focus on building software that meets business needs.” If that’s too complicated, here’s another attempt at an explanation: “Scrum itself is a simple framework for effective team collaboration on complex software projects.”

While this does not explain what Scrum is (one should take multi-day training courses to fully groke that), it starts to emerge that Scrum is about:

  1. teams
  2. complex projects
  3. visibility into the work of and collaboration between individual contributors

First two items describe common reality, while the last one is often a hard-to-reach state.

Visibility and collaboration are a worthy goal for many organizations. Teams produce better value if all participants were fully aware of the overall vision and what other people are working on.

Collaboration and friendly competition are known to improve productivity and quality of the work. Installing and maintaining a Scrum board is a lot less work than adopting proper Scrum. Yet, it is a tiny investment with outsized return.