Transforming Technology Organizations By Investing in Culture and Practices

Should IT only be a services organization to the Business? Should it only provide a services catalog around incidents and requests and a PMO to oversee projects when required? Will perfecting service levels and project execution be good enough for the Business to compete when innovation and data driven practices are so critical for competitiveness? Will IT be able to consider optimal solutions when they require a mix of Cloud, SaaS, and on premises components and significantly more data integration and application development across them?

That is the question facing CEOs, CIOs and IT leadership and many have come to realize that keeping the lights on and just getting things done in IT is not good enough. The new IT charter includes investing in Digital Transformation, enabling a Data Driven Organization, and maturing IT innovation to fuel business growth and efficiency.

IT Culture and Practices

I've been posting on IT culture to raise awareness how important it is when a business is trying to transform and innovate. My post, 10 ways to improve IT Culture with Agile, DevOps, Data, and Collaboration speaks to the good signs and ways to improve IT culture by investing in specific practices like Agile and DevOps. I went a little deeper with 5 Principles on What Makes a Great Agile Team and provided more specifics on what makes an agile development team succeed over long periods and contribute to IT culture. I then went to the dark side pointing out 20 bad behaviors of agile product owners and 33 Bad Behaviors of Agile Developers and IT Operations to highlight a list of behaviors that have negative contributions to IT culture.

My message? If you want to improve IT culture, you have to target positive practices but also correct for negative behaviors.

Course Correcting Negative Behaviors

Let's look at some negative behaviors from my last post and consider options and solutions. What practices should IT Leadership focus on to improve IT culture and address bad behaviors? Here are three:

Drive Collaboration and Communication Behaviors to insure teams are working well with their business colleagues on opportunities, solutions, and innovation. To irradiate the dividing line between "requirements" and "implementation", the number of people in the IT team that need to be able to communicate and collaborate with stakeholders is significantly larger than in decades past. Improving communication is an easy starting point to get developers, system administrators, engineers, business analysts to be better prepared to collaborate. Here are some places to start:

Mentally says no, or actually says no to an idea or request without listening to the business need and priority
Communicates in technical jargon or overly complicates the message back to a business user when responding to a question
Creates blocks and waits for requirements without engaging the stakeholder or proactively proposing opportunities, problems that need to be addressed, and solutions
Fails to regularly communicate status when resolving a critical issue

Evangelize actions that drive IT Efficiency - It isn't going to be easy to justify investments to fix manual work in IT or to dedicate application development releases to fix bad software. Both of these issues need to be avoided before they are created and fixed incrementally over time. It's why addressing behaviors like

Fails to automate tasks and leaves significant manual steps in a technical solution or
Creates technical debt but does not itemize it in the backlog to be fixed or
Doesn't provide documentation, training, or other knowledge transfer to ensure colleagues can support the technologies he or she developed

Insure IT decisions are data and quality driven - IT is the hub of so much operational data, yet they often leave out the discipline required to review this data, develop metrics, and leverage in their decisions on priorities, problems, and solutions. If IT isn't using its own data, then how can it be a part of a data driven organization? In addition, if IT isn't paying attention to quality or security, then how can it deliver reliable and safe solutions? These behaviors underscore issues that need need to be course corrected:

Chases rabbits when trying to diagnose performance issues without reviewing logs and metrics to guide efforts to areas of higher importance
Over engineers solutions and inflates estimates
Treats quality assurance, testing and security as an afterthought and doesn't bake these paradigms into designs
Doesn't implement unit tests, performance evaluations, or other test driven practices to ensure that code is reliable and functioning properly

Are you ready to lead a cultural transformation?

continue reading "Transforming Technology Organizations By Investing in Culture and Practices"

33 Bad Behaviors of Agile Developers and IT Operations

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

Mentally says no, or actually says no to an idea or request without listening to the business need and priority
Doesn't accept responsibility when there is a screw up. It's always someone else's fault
Is always critical of other people's development or engineering work
Empowers business users to select technologies or overly specify solutions without understanding the nature of the opportunity or problem and identifying scalable, supportable options
Communicates in technical jargon or overly complicates the message back to a business user when responding to a question
Fails to automate tasks and leaves significant manual steps in a technical solution
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
Allows meetings to go off agenda by bringing up issues that are only tangentially related to the topic being reviewed
Doesn't collaborate with technology colleagues. Leaves issues lingering so that he or she can be the hero to resolve them
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

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

Operations

Makes systems changes without following through and insuring it had the desired impact
Fails to regularly communicate status when resolving a critical issue
Thinks the application is working normally because the systems are fine and network, cpu, and storage monitors are all green
Chases rabbits when trying to diagnose performance issues without reviewing logs and metrics to guide efforts to areas of higher importance
Says a system is "ready" when the underlying application hasn't been fully installed, configured, and connected to operational and support systems
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
Doesn't participate in the agile development process until the version is near-ready for release.
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.
Doesn't follow standard builds, deployments and configurations.
Doesn't track utilization and other capacity trends to ensure that policies, procedures, and system resources are realigned when required.
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

continue reading "33 Bad Behaviors of Agile Developers and IT Operations"

Agile Culture - Are You Developing Solutions or Solving for Business Opportunities?

Here is the hardest problem for a performing agile development team -

Can you build me something that does A, B, and C for Users X and Y and have it completed within the next couple of weeks

What is the problem with this form of requirement? Many of you might start with the obvious that you need more details around A, B, and C to gain a shared understanding with the product owner or stakeholder of their requirements. Then, some of you will focus on "couple of weeks" and recognize that the product owner is trying to fix both scope and timeline which needs to be managed, ideally through agile estimation and prioritization. Others will also guess that the team already has a backlog and this requirement is probably an Epic that needs to be prioritized and planned for a release.

continue reading "Agile Culture - Are You Developing Solutions or Solving for Business Opportunities?"

Labels