It
has been a while since my last post.
So I thought of closing off our discussion on code reviews in agile
environments, hopefully providing some sense of understanding. So in this post I will discuss my perceptions
around code reviews also known as peer reviews.
When I posted this topic I used the word “agile”, with a very specific reason. There seems to be a lot of opinion associated
with the word agile, especially in the software development industry. So let’s explore that briefly:
Who is Agile, What is Agile when
am I agile
Often
the word agile has different connotations depending on the context, environment
and industry it is used in. In a supply chain environment the word agile has a completely
different meaning and this insinuation of the word agile for supply chain environments is referred to
as agility.
“Agility
is all about customer responsiveness, people and information, cooperation
within and between firms and fitting a company for change.”
So
looking at the software industry. “Agile software development” was coined by
the Agile
Manifesto in 2001. The philosophy around being agile is
summarised as follow:
·
Manage change
(Being responsive to change )
·
Collaborate and
communicate (Keeping the customer informed and happy)
·
Maintain Quality
(Ensuring quality is delivered )
The
adoption of an Agile methodology has been trigger in reaction to manage the
points listed above, and to combat (not eliminate) the constraints that often
impede the success of a software deliverable.
So, without trying to sound too much like a project manager. These constraints often make its presence
known through:
·
Some scope of
work that needs to managed
·
Controlling the
cost around that particular scope of work
·
Managing the resources
and time in to ensure that the scope of work gets delivered timeously.
These
three constraints manifests itself thorough,
·
Resources (Can include physical infrastructure)
·
Time Constraints
·
Scope of work
·
Cost
The
improper balance and management in any of these areas undoubtedly leads to a compromise
in the quality of the software being delivered.
In reaction to this risk, different software development methodologies
have been developed, of which agile is one of them. Each one of these
methodologies comes with its own benefits and are in no way perfect, but
pronouncedly aims to prescribed approaches
to solving the day to day problems, which is somewhat disconnected from
reality. Martin Fowler summaries this
concern as follow:
“The most frequent criticism
of these methodologies is that they are bureaucratic. There's so much stuff to
do to follow the methodology that the whole pace of development slows down”
– Martin Fowler
There
are several articles, journals and blogs that profess on the different software
methodologies. This post is not intended
to cover them to the nth degree, but rather to add some informative context to the current perceptions.
Common sense is maybe not so commonly understood
My deliberate attempt of
using the word “agile” in this post was to gather your responses and hopefully,
see how the term “agile” is often misleading.
In all honesty when I initially posted the question Can "agile" software environments,
truly accommodate decent code reviews.
I
had no idea on what responses I would get and the question I posted was both
impulsive and unbiased, but this has led me to think about this a bit more
carefully.
So to get back to code reviews in the context of agile, the simple
answer to my question is yes, agile environments can cater for descent code
reviews. But how much time has actually
been spent whilst trying to answer this question. To me it seems like another common sense
answer that is not so commonly understood.
It should be remembered that code reviews (Note: I am not using
the words “best practices” but rather “improvement practices”) is an
improvement practise in an agile environment, whether it is conformed too or
not, it can be adopted and adapted to suit the needs of the development team.
This means “Agile software environments” as quoted in my questions
is intended to be adaptive; this implies that there is some compromise to any
changes over and above a set expectation, as long as everyone reaches consensus
around the expectation.
I have been
working on a project where we were allowed to move items on and off a product backlog during
a sprint cycle with only one condition
from the customer. The condition was
“The delivery date does not move”. This
is yet another example of how an agile software environment needs to be
adaptive with some compromise.
Improvement practises such as code reviews are often removed from
the methodology itself, and merely serve as a catalyst to the delivery using
the specific methodology.
One of the bloggers asked a question “around using” code reviews
in a business intelligence development team, to me the concept is the
same.
The inhibiting factors that prevent a development team from adopting
improvement practises are often symptomatic of agile barriers. However improvement practises should not be treated as
the norm as James
Barrow (former colleague) mention in reply to this post, but should
rather be absorbed in a manner that is conducive to the dynamics of a software
development team.
One major benefit of code reviews is that is has the distinct
ability to limit the defect density during the delivery of a software product,
this goes without say. However the
profound benefit in following an improvement practise such as code reviews lies
in the culture it provokes within a software development team. This practise provokes what I call self-motivated behavioural change around
quality, when encouraged correctly.
I would highly recommend organisations and development teams to
adopt code reviews as an improvement practise. Please
look out for my next post which will be some guidelines around adopting code
reviews effectively.
