As with many other practices, Agile is more about the developer mindset and
team culture than the tools or methodologies. While the later can support Agile
development, without the proper mindset and culture they are bound to be just
another tool to do check lists, adding to work and not reducing it.
Throughout my time as a developer and leading teams, it has been interesting (to say the least)
finding developers that can code the whole day without ever compiling, even less
running and unit testing and even more rare, integrating the code. This may come
from practices that were appropriate (and may still be appropriate) when
execution time had a high cost, where people had to schedule their runs or going
even further back, when developers didn't have "execution rights" on their own
code. While for most projects and for most environments that is no longer the
case, people that lived through those times still feel this is a sound practice
which gets carried on to new developers as part of the team culture.
For Agile and DevOps to truly add value, developers need to embrace not just
the tools and methodologies but the mindset and culture of continuous feed back
and collaboration.
Culture and mindset changes do not happen over night. Under pressure we tend
to fall back to our old patterns. When I decided to learn to "touch type" or use
the mouse with my left hand, I certainly worked slower.In times of pressure
felt tempted to fall back to finger typing or switching to the right hand mouse. It
was through forcing my self to stick to my plan that I eventually mastered both.
After a small dip in productivity, my productivity increased substantially. Now I can just
think what I want to type without worrying at what my fingers do, they just
move.
But it is not just the personal changes that need to happen, the environment also needs to adapt. From the physical environment: Where we sit, where we meet, how
we collaborate, to changes in the legacy code we are working with.
Here is where we need to accept some temporary pain: It seems that
there is a chicken and egg conundrum between continuous unit testing and
refactoring. It is easier to refactor code when it is properly structured to be
"unit testable" the conundrum is that with legacy code we tend to start with code that has
evolved to be "un-unit-testable": Big chunks of code with multiple code paths that do more than one thing and . This leads to fear of
refactoring as it is difficult (or even impossible) to properly unit test the
changes. Developers and managers need to understand that here, they will need to
slow down the development cycle due to the inherent risk of the refactoring. The reward will be refactored code which bring higher productivity down the
road.
I will close by extend my old saying "Don't bring a tool without a practice" and
add "and ensure that the mindset and culture changes to adapt to that
practice".
