Top Six Reasons Corporate IT Avoids Agility

With all the talk about "IT agility", you would think that the only thing holding corporate IT back from moving quickly are external forces like funding and resources. I actually think some Corporate IT teams might actually avoid being agile. Here are the top five reasons:

1) Agility means risk. Optimally this is calculated risk but regardless it is still risk and risk makes people nervous. Unless IT leadership supports and rewards risk taking, it will not happen. Not all risk taking leads to something successful so people avoid it unless they get air-cover from their leadership team.

2) Agility requires speed. Good decisions in IT typically takes time. IT teams usually follow some sort of Project Lifecycle process which typically follows a "waterfall development model". Scrum or Agile development radically changes the typical waterfall model that most IT teams follow when doing projects. Unless IT leadership supports an iterative development model, IT will continue to follow the slower waterfall approach.

3) Agility requires that IT has a broad understanding of technical solutions and options - this means that IT needs to be at the top of their game technically. The broader IT's understanding of technical options, the more likely IT will be able to identify solutions that are agile. If IT is not focused on staying technically current, they are at a disadvantage.

4) Agility means more work for IT. Rapid releases, brain-storming, rapid development, etc will mean more work for the IT team. IT teams are typically fully utilized simply keeping things running and barely have time to think about being agile. Agile requires IT to work differently, leverage different processes and follow different policies. IT leadership needs to support this change or it'll be status quo.

5) Agility requires IT to be creative. IT has to have the ability to think creatively and provide options when discussing solutions with the business. This creativity may make IT uncomfortable because it requires one to think outside the box. Engineering typically is more anchored on facts and figures than creativity.

6) Agility requires business acumen. IT must have business acumen. This means that IT understands both the business strategy, direction and vision as well as how the business operates, the business processes and policies. With business acumen, IT can actually proactively meet the business' needs. Without business acumen, IT is relegated to an order taker. Order taking is reactive and not agile.

Comments

Post a Comment

Popular posts from this blog

Enterprise Architecture Inside Salesforce

Image
  Enterprise  Architecture Inside Salesforce Enterprise Architecture — How We Do It Internally The two words, “Enterprise Architecture”, elicit various reactions — everything from “ we tried that and it doesn’t work ” to “ we need that! ” to “ we have an effective EA practice ”. Unfortunately it is possible (even easy) to do Enterprise Architecture  incorrectly , with an approach that is lethargic, technology-first and theoretical — the classic ivory tower. (In Salesforce, the internal IT group reporting into our CIO is called “Business Technology” so you’ll see me use BT to refer to Salesforce IT) I lead the Salesforce Enterprise Architecture team within Business Technology and I’m often asked the following questions: how does Salesforce do Enterprise Architecture? why do you need Enterprise Architecture? how do you shift the conversation to business capabilities? Illuminate — The “How” of Salesforce Enterprise Architecture Let me start with the “HOW” first. Within Sales...
Read more

Illuminate - Business Model Exploration

Image
  Illuminate — Business Model Exploration One of our world-class Salesforce Enterprise Architects, Jonathan Laudicina ( https://www.linkedin.com/in/jonathan-laudicina/  ) has done amazing work on Business Model Exploration. I want to highlight some of his work and I think you’ll find it useful. As a reminder, Illuminate is the Enterprise Architecture Methodology that we use inside Salesforce as well as with our customers. The overall Illuminate methodology is depicted below. You will notice that Business Model Exploration is the first step in Illuminate. Business Model Exploration is the methodology we use with customers to articulate: External Forces pushing on the business Internal Forces pushing on the business Customer specific Business Model Canvas At the heart of Business Model Exploration is the Business Model Canvas. It is the place in which you capture key factors about a company’s specific value proposition, partners, customer segments, cost structure and revenue str...
Read more

5 Key Components of a Successful Enterprise Architecture Function

  5 Key Components of a Successful Enterprise Architecture Function 5 Key Components of a Successful Enterprise Architecture Function Creating and managing a successful Enterprise Architecture function requires a variety of different hard and soft skills. In addition, each company is different and the Enterprise Architecture function needs to calibrate and align itself to the specific company. However, there are five common features of a successful Enterprise Architecture function that are applicable to all companies. 1. Governance Enterprise Architecture (EA) requires governance, however not in the form of complex documents, forms or processes.  Definitely avoid EA being seen as the policy-enforcement team — people will avoid EA if the perception is that EA is a blocker.  The best governance starts with a simple, recurring dialogue across multiple functions facilitated by EA. I am always amazed at how valuable it is just to get cross-functional teams to  talk . Pick...
Read more