The Agile Manifesto, created by seventeen guys from the field of software engineering eighteen years ago has certainly changed the way we create software solutions fundamentally and radically. The great majority of software development projects is done using agile practices like Scrum. Today, everybody knows the famous “we value X over Y” statements:
Trapped in the vortex of digital transformation, almost all industries are facing challenges caused by highly accelerated technology innovation cycles, new and disrupting competitors, and, last but not least, a tremendous amount of technical debt in their vast historically grown IT landscape.
To deal with this area of tension companies trust in ‘Agile’ gurus that tell them how they must change their organization and culture to become ‘agile’. If we look at the complexity of the application landscape of a typical company it becomes obvious that they simply can’t be agile without renovation projects that make their legacy IT agile.
What you should do:
Reduce your technical debt step by step by the renovation of your legacy IT. Agile IT landscapes make companies agile, not agile coaches that focus on culture and organizational aspects.
Hire business architects instead of agile coaches.
When Agile software development was born in 2001, it defined a set of four principles:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
I have worked in several Agile teams where ‘responding to change over following a plan,’ often got misinterpreted to mean “don’t have a plan.” Those teams often find they waste time by adapting too much.
I have been working as a part of many Agile teams. In the beginning, whenever I introduced myself as an ‘Architect’ colleagues became mistrustful and started to perceive me as the breakman of the team. For that reason, I would never name myself an ‘architect’ again. It seems as if many hardcore agilists perceive architecture as the enemy of Agile. But is that true?