Is the agile adoption failing you? Are you skeptical of the transformation process that you have undergone? Is the board room meetings all about figuring out issues with agile adoption and transformation programs? Chances are you are right. This blog post is aimed to help you introspect and figure out what is it that you've given amiss or have overlooked.
1. Adopting only technical practices
 |
| Ouch! it hurts.. |
Nearly every organisation I visit for business or otherwise, I smell a ton of work-pressure on the development teams and as if that is not enough, the management decides to get the development teams go through a series of trainings for quick learning and expertise on that niche skill. This is really a sad tale of development teams.
I think fortunate are those companies that reached our to me directly or indirectly for getting this technical training done. Because whenever I get such enquiries, I query them with loads of questions on the teams that attend the training and the work pressure these teams have in their typical work-lives. I then politely tell them that this wouldn't work no matter how hard I work together with the teams. In all honesty, I recommend the management or sponsor to not burn money paying for any such technical trainings with the hopes of overnight productivity improvement. To that end, I've decided to not go the trainings way at least for now (until I discover novel and meaningful ways to reduce the learning curve of the training attendees).
Software development is craftsmanship. There are the science parts to it without doubt, but the art side of software development is where the real fun is. It takes learning without stress, practising with joy, seeking feedback for introspection, teaching to learn, mentoring with empathy, et all. For you to witness all these, set the company culture right, break hierarchy and build roles, encourage openness and collaboration, delegate both power and responsibility, allow fast failures, induce entrepreneurial spirit, celebrate learning and knowledge sharing.
2. Adopting change management, devoid of technical practices
 |
| Image Source: Wikipedia | Agile - Engineering Practices = Silent Death |
Think about it. Moving from "Use Cases" in the RUP world of software development to "User Stories" in the Agile world and breaking it to smaller user stories, and developing features just in time don't last (very) long. Why? There would come a time when you'll start having estimations go from good enough to bad to worse.
The unpredictability increases as surprises keep slapping you on the face with the rise in code complexity. It takes serious guts and openness to admit this state. You've spent a ton of money to reach this state and you don't want to admit failure at this stage. Very few companies wake up to this reality and raise an alarm. Frankly, these companies are better off admitting failure at least at a later stage, than their counter parts going through hell silently.
It is common sense to think that maintenance is a necessity in day to day life. Unfortunately, it is uncommon sense to think that code too deserves this kind of maintenance. It is with regular code maintenance, that you can face the challenges of rise in code complexity. And this regular maintenance of code is all about refactoring the code for better design, readability and maintenance. Barring a few simple refactoring cases like renaming, extract method, inline method, etc, it takes sustained practice to reach the level of expertise. Code refactoring first requires education in learning bad versus good code, then the safety net of unit tests, and then the discipline of writing test first code with deliberate practice - in that order.
Conclusion
Rome was not built in a day or week or for that matter not even in a few months. "True Agility" too can't be built in a few days or months. Having said that, it doesn't take very many years the way many Agile Consulting organisations project things to be for their profit. The time an organisation takes to transition to true agility depends on a lot of factors - culture, organisation systems, people practices, technology practices, team motivation, etc.Finally, if it looks like a classical chicken and egg problem, you aren't alone in the game. I intend to talk about this subject in my future talks this year. If you're in a hurry, do feel free to reach out to me.