Agile Engineering practices is a bad name. It suggest that only engineers should care about them. Many of them do, but improving practices and paying back technical debt is huge investment, requiring time, money and commitment. In most organizations approval from the top is necessary. And usually engineers are at the bottom of the structure. So they need to ask for permissions to do refactoring get right tools and implement solutions that are hardly seen by customers. Sometimes they are heard by their managers who let them spent some time on that “engineering stuff”. But that happens rarely and even in these cases the investment is usually limited as “we’ve business to do here you know.”.
The problem is, that decision makers don’t see value in these agile practices, refactoring and paying back technical debt their engineers talk about. That’s because people at the top of organization think about money, ROI, budgets, cash flow and providing value for their stakeholders and customers but not about something they might perceive as engineers’ fad. As long as their competitors have the same problems with adapting their products to market’s needs companies can survive for years. But as soon as a new player is more responsive, their world can quickly collapse. And even “too big to fail” companies might soon disappear.
To make conversation about engineering practices interesting to decision makers we need to speak their language. We need to show them Return on Investment from implementing agile approach, or explain costs of not having it. Product Agility Checklist is a document I’ve created for starting this conversation and identifying the biggest issues your product and business might observe that are caused by lack of Agile Engineering Practices.
You can download it here: Product Agility Checklist. Please let me know if you’ve found this checklist useful.
You can find more guides, cheat sheets and brochures in our Agile handouts database.