Monday, November 27, 2006
Why IT Executives simply don't understand Agile methodologies...
Figured I would share several IT executive anti-patterns when it comes to truly being agile...
Listed below are some key considerations:
| | View blog reactionsListed below are some key considerations:
- Mistaking management for leadership: These two words are not interchangable! Many IT executives promote folks up through the ranks either based on demonstrated competencies and/or the ability to influence neither of which is representative of being a leader. When was the last time you sent your architects to leadership courses? Agility requires leadership and facilitation (distinct from representation) and not everyone is born with those skills
- Process as a substitute for competence: In many shops, process is used to turn valuable IT staff into repeat-after-me uber-consistent Full-time equivalents which demonstrates that they don't get the real value of process. Processes should harness collective competence and figure out how to leverage breadth and diversity. Consider your enterprise architecture team and the various challenges they face. You may need someone who understands business architecture, and someone else who understand your enterprise strengths, weaknesses, hisotry, IT portfolio, culture and politics well enough to make business architecture successful. Process should uncover the unique capabilities of individuals and eschew attempting to make everyone the same
- Education is key: Understand that it takes a long time for most people to deal with paradigm shifts as they may not be lucky enough to have IT folks such as my peers where shift happens. To be successful in paradigm shifting you need to do more than just executive communications but instead acknowledge that you need to educate others. Education doesn't happen by reading memos as this is best known as knowledge transfer. Education only happens via face-to-face conversations. Do your IT executives only talk to their direct reports? If so, you are guaranteed to fail.
- Allow for failure: In many IT shops there is more of a desire to not fail than to succeed. In order to accomplish meaningful transformation, IT shops need to experiment and try things they haven't done before. Some attempt to mitigate failure by hiring consultants which only works at some level and is almost guaranteed to result in mediocrity as they will push best-practices which assume there is only one single way of doing something...
- Learn how to ask for help: Nowadays many executives are afraid to ask for help which at some level requires them the ability to admit to not knowing everything. When was the last time you heard your boss say: I don't know? Asking for help is not about the hierarchy but more about finding those with perspectives that can be beneficial regardless of whether they work in your shop or even your compeititors. For example, if you are struggling with a component of enterprise architecture, SOA, etc consider reaching out to folks in Fortune 100 enterprises who have had demonstrated success in this area. I am sure they would be willing to help
