You should change your culture and mindset to successfully implement Agile and DevOps

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".