I recently published 20 Bad Behaviors of Agile Product Owners and decided not to leave this subject one sided. In trying to improve the organizational culture and more specifically, the culture in IT, the CIO and IT leadership must consider, review, and improve on its own behaviors.

So this week I’m itemizing some of the bad behaviors in IT. Like my previous most, I haven’t seen these behaviors in any one organization or person – it’s a collection that affects individual and teams from time to time some worse than others.

Behaviors

1. Mentally says no, or actually says no to an idea or request without listening to the business need and priority
2. Doesn’t accept responsibility when there is a screw up. It’s always someone else’s fault
3. Is always critical of other people’s development or engineering work
4. Empowers business users to select technologies or overly specify solutions without understanding the nature of the opportunity or problem and identifying scalable, supportable options
5. Communicates in technical jargon or overly complicates the message back to a business user when responding to a question
6. Fails to automate tasks and leaves significant manual steps in a technical solution
7. Doesn’t drive to become a technical expert. Does not read documentation. Fails to question vendors and consultants to ensure knowledge transfer on new technologies or solutions
8. Allows meetings to go off agenda by bringing up issues that are only tangentially related to the topic being reviewed
9. Doesn’t collaborate with technology colleagues. Leaves issues lingering so that he or she can be the hero to resolve them
10. Under invests in the time required to learn new technologies and solutions. Doesn’t consider free resources to learn about a technology or practice. Wants training, but does not identify opportunities to leverage what they’ve learned.

Agile Development

1. Creates blocks and waits for requirements without engaging the stakeholder or proactively proposing opportunities, problems that need to be addressed, and solutions
2. Creates technical debt but does not itemize it in the backlog to be fixed
3. Only does what was requested and doesn’t question members of the development team to make sure the requirement and solution are complete
4. Fails to align solutions to target architectures, data models, and other standards.
5. Doesn’t check in code into version control daily. Checks in code that breaks the build.
6. Thinks xx and other non-descriptive variable names are acceptable in code
7. Over engineers solutions and inflates estimates
8. Holds back and under commits to sprints. Does not push the extra mile and over commit when there is a business need
9. Doesn’t provide documentation, training, or other knowledge transfer to ensure colleagues can support the technologies he or she developed
10. Treats quality assurance, testing and security as an afterthought and doesn’t bake these paradigms into designs.
11. Doesn’t implement unit tests, performance evaluations, or other test driven practices to ensure that code is reliable and functioning properly
12. Skips or does not participate in standups, commitment, retrospectives and other agile meetings

Operations

1. Makes systems changes without following through and insuring it had the desired impact
2. Fails to regularly communicate status when resolving a critical issue
3. Thinks the application is working normally because the systems are fine and network, cpu, and storage monitors are all green
4. Chases rabbits when trying to diagnose performance issues without reviewing logs and metrics to guide efforts to areas of higher importance
5. Says a system is “ready” when the underlying application hasn’t been fully installed, configured, and connected to operational and support systems
6. Claims a systems capability such as backups, snapshots, or disaster recovery is available but doesn’t create and test procedures to ensure they are operational
7. Doesn’t participate in the agile development process until the version is near-ready for release.
8. Fails to listen to business users on the context and priority of their service desk request. Prescribes technical answers and solutions that does not fully address the business problem facing the user.
9. Doesn’t follow standard builds, deployments and configurations.
10. Doesn’t track utilization and other capacity trends to ensure that policies, procedures, and system resources are realigned when required.
11. Considers the cloud and SaaS solutions as competing technologies to on premises solutions and does not provide sufficient operational solutions or problem resolutions around them