The Agile Congruence Framework Part 1

1. Identify Symptoms

There is some reason that your organization wants to change and make an investment in technology. In the past when I have assumed that all stakeholders were on the same page with the problem that we were solving I was usually wrong. Taking the time to identify and understand the symptoms and ensure that there is agreement among stakeholders on the problem statement is a key first step to scoping your change process.

2. Understanding your Inputs

The inputs to the Congruence Model are considered outside of the scope of the managers ability to change. Some of the specific aspects of these inputs various managers may have influence in changing, but typically do not have control over. Table 1 shows some common themes to capture and questions to ask when evaluating your organization’s inputs.

An understanding of the things that are out of your control but affect your organization is important to effectively maximizing your organization’s effectiveness. 

Strategy
Corporate strategy	Are you a product company, a consulting company, a services company?Are you attempting to grow in a new market or maintain market share?Are you looking to deliver a premium product or serve clients looking for low cost solutions?
Product Strategy	Are you creating a SAAS application, a mobile app, an installed application? Is your application stand alone or part of a larger application infrastructure?
Technical Strategy	How will your application be deployed and hosted?What frameworks are in place for integration with a larger product?What infrastructure could, should, or must be used by your application?What are your organization’s tech standards?Are there constraints on supported languages?
Sales Strategy	Does your company sell your product as is, or will the sales team sell customization projects? Do you sell one-time licenses, a retainer-based contract, per use contract?
Environment
Regulatory	What are your organizational regulatory requirements?What if your organization’s process for vetting and approving changes from a regulatory perspective?
Audit	What are your organization’s audit requirements?Who owns the audit process?
Competition	Who are your competitors?How do you evaluate your position in the marketplace and how does that drive your change process?
Technology	Who are your key technology advisors?How will you evaluate your client’s ability to adopt potential technical changes?
Resources
Budget	Do you have a fixed budget?How will you evaluate cutting or expanding project scope?
Talent	Do you have the talent on both the development and business teams?What are your sources of new talent?What training opportunities are available for the teams?
Infrastructure	What existing infrastructure can be leveraged?

Table 1 Some common themes and questions to ask to help understand your organization’s Inputs.

3. Define your Outputs

Chatham Financials’ former COO loved to say, “If you don’t keep score you are only practicing”. Having key performance indicators in place to evaluate your change process before beginning the process is essential to evaluating your success. Agile software books frequently discuss the concept of always working on the highest value features but measuring and assessing value is rarely discussed. Ultimately your company will look at metrics like performance or cost. These are obviously key indicators of your organization’s success but are typically difficult to link back to software changes. 

Metrics like batch valuations per hour or documents processed per day per employee are much more relatable to you direct software changes, and easier to watch evolve over time. They are also great tools to align your development teams and business teams around the same goals. When the developers and users of the software have clear and measurable objectives their alignment and motivation increase, and you are more likely to see the desired organizational changes. 

While these metrics are important, so are informal measures. Talking to people within and adjacent to your organization should be just as important as your KPI’s. Some managers get tunnel vision when they are too focused on a few key metrics and end up missing the mark completely. 

• Do you have KPI’s in place for the organization?

• How frequently can you measure your KPI’s and how does this compare to your release cycle?
• Do you have a history of measurement over time to compare changes to?
• What informal measures do you use to measure organizational effectiveness?