How do we get Enterprise IT to align with our customer? The questions we ask our customer are indicative of our assumptions. Those assumptions are correlated to our relationship with our customer, and our understanding of that customer’s pain points or frustrations with IT. But how do we get past assumptions, and how do we break out of our [current] relationship with our customer, to invent a better relationship?Continue Reading
In interacting with a software team recently, I realized that communication is often not the strongest suit that developers play. Here are some patterns that I observed that I find harmful to effective software delivery:
1) Communicate via status – When developers are using tools to manage tasks, defects, or other work packages, they often fall into the trap of simply updating the status of the work item as a means of communicating that something out of their area needs to happen. The primary problem is that while status may identify what needs to happen, it doesn’t communicate the following: Who is responsible for it, and when it needs to happen. It also does not provide that person any guidance as to what has gone before. If you need something from a team mate, (especially co-located) get up out of your chair and go talk to them. Failing that, send them an e-mail with the pertinent information, so that they can express the appropriate urgency and responsiveness.Continue Reading
Caution: Rant Ahead!
Ken sends a note to Carole, his boss: “I need to know what systems our teams use for client servicing activities, can you help”? Nothing wrong with asking for information. Unless you’re asking people who don’t have a reason to know about what you’re asking.
Carole forwards the note to Joe, a project analyst: “Hey Joe, can you help Ken with this?” PUNT! Carole is newer to the group, and not as familiar with what systems are used. She thinks that Joe who has done numerous projects with systems may have some information.Continue Reading
In my prior post ( ITStrategyInternals ) I explained a little about patterns and practices. Patterns and Practices within IT go hand in hand, in that we have an established solution, and a body of knowledge and expertise around that solution.
I think that we sometimes think that by selecting a tool, we have defined a pattern. So let me say, that patterns are at a higher level of abstraction than a tool. A pattern may require some tooling, but it should not be specific to a tool. The body of expertise around implementing a pattern with/through a specific tool is a practice. So ORACLE DBMS is not a pattern, but a data warehouse may be. Likewise, MQ Series is not a pattern, but a message bus may be. We may have a practice around implementing a message bus using MQ Series, or TIBCO, or Tellurian sockets or Oracle SOA Suite.
Tools are really only valuable, in that they enable the delivery of patterns. Tools can be anything from an integrated development environment (IDE) to a component library to an operating system. Programming languages are not tools, but editors and compilers are. Programming languages are patterns. SQL is not a tool, but MySQL is. SQL is a programming language that is a common part of a relational database pattern. We have come to expect that any tool that enables a relational database pattern implements some version of the SQL programming language.
Those of us who have been in this industry for a few years, realize that the players (tools) change pretty frequently. As a new pattern emerges and is perceived as valuable, it disrupts the market for a while, then the tools supporting the new pattern prosper, and the others diminish and sputter towards irrelevancy.Continue Reading