By: Mike Holka

I’ve heard many managers of IT organizations proclaim to each other that we need to “Go Agile”. “If we can do that, all of our problems will be solved”. Interestingly, the same managers that make that proclamation rarely know what it means to “Go Agile”, let alone what their organization would look like or how it would behave when they are done. Contrary to popular belief, “Going Agile” may actually cause more organizational dysfunction and should be carefully thought out, understood and planned before embarking on the transformation. 

First let’s review some of the values and principles of Agile that organizational culture and/or policy will impact. Be advised, items perceived as not related to organizational culture or policy were removed from this list.

• Values
  • Individual and Interaction over Process and Tools.
  • Working Software over Comprehensive Documentation.
  • Customer Collaboration over Contract Negotiation.
  • Respond to Change over Following a Plan.
• Principles
  • Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage. 
  • Business people and developers must work together daily throughout the project. 
  • Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. 
  • The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. 
  • Working software is the primary measure of progress. 

Many organizations have been around for years and are set in their ways in terms of culture and process. The culture and organizational structure can and does hinder efforts to “Go Agile”.  In some organizations, a culture of fear resonates. This fear actually hampers open, honest and candid communication. In its most insidious form, this fear, prevents the free flow of ideas to solve problems. 

Human Resources Departments define the job descriptions, and then categorize them into salary ranges. Ranges are typically based on the number of years with the organization, years of experience or educational degrees. From there the organization defines a structure, the infamous Organizational Chart. In its traditional form the org chart creates inefficiencies in communication as information technology personnel are typically separated from the business folks they are assigned to support. 

IT Departments can become hamstrung with Human Resource job descriptions, and organizational charts when forming project teams. They define the resources needed in terms of project roles, which likely are contrary to job descriptions. Conflicts arise as the project manager tries to explain the work to be accomplished by the Team. The phrase “that’s not my job” is the first symptom of this impediment. 

From an organizational perspective, one of the biggest impediments is the lack of business collaboration. This is sometimes caused by the organizational hierarchy or the simple notion that the Project Team (business users and technicians) cannot be co-located to allow the collaboration and cooperation to take place.   The lack of collaboration usually results in poor communication. To correct the perceived communication issue, managers and project managers will tell their Teams: “all communication must go through me”. This is usually done in the interest of consolidating the communication process so that we don’t bother the business areas. The reality of it is…it actually creates a bottle neck in communication. Team members must be empowered to go directly to the person who can help in the most effective, efficient manner. 

Governance policies and procedures increase the rigidity of work flow.   Project Management Offices by their very nature can create a work environment that can stifle the transformation. Strict adherence to methodology where documentation is more important than working software goes against the core values of being Agile. Audits that focus on the creation of documentation and approvals encumber the Team by artificially slowing the productivity while process catches up to the work being accomplished. 

Legacy processes, techniques, status reporting, budgeting, and governance will likely change as part of the transformation. It is the responsibility of the Mgt Team to comprehend the change they are embarking on, understand it, embrace it and facilitate it. Without management support, to the executive level, the organization will not be able to embark on a transformation let alone sustain it. 

An Agile Transformation will likely be the most complex organizational change experienced by the management team. It must be understood that the transformation will affect everyone in the organization. I invite those that are contemplating an agile transformation to first review the Agile Manifesto – Principles: https://agilemanifesto.org/principles.html. I also invite those responsible for leading the transformation to review the works of Dr W. Edwards Deming. While it is true that Deming’s work is pre – 2000, the concepts and philosophy are still relevant today, for ALL organizations.

Good Luck on Your Transformation!!                          

Mike Holka is a PMI Certified Project Management Professional with over thirty years of experience in the development, maintenance and implementation of computer systems for insurance, human resource and banking industries. As a project manager, he has led application development teams through the entire systems development lifecycle (SDLC).  He takes a customer and business centric approach to information technology, has a solid IT background in multiple technologies, as well as a demonstrated track record of leadership and the ability to foster a team environment.