The Agile Architect

How Agile Are You? Let's Actually Measure It! (Part 6: Project Management and More)

• By Mark J. Balbes, Ph.D.
• December 15, 2015

• Part 0: Introduction
• Part 1: Technical Craftsmanship
• Part 2: Quality Advocacy
• Part 3: User Experience
• Part 4: Team Dynamics
• Part 5: Product Ownership

In this final article of the series, I've combined the last few assessment areas: project management, risk management, organization support and change management.

Let's start with project management.

Project Management
It is a common misconception that there is no room for project management on an agile project nor is the role of project manager appropriate. As with all things agile, it depends. Certainly, the need for project management has not disintegrated. Most of the activities of a traditional project manager have either been transformed, subsumed in other activities or disappeared. However, when agile exists as an island within a more traditional organization, a project manager can act as an important buffer, allowing the agile team to focus on the "right" activities while the project manager translates to the corporate norm.

I have discussed Project Management in these previous Agile Architect articles:

• Are Agile and CMMI Compatible?
• Agile and CMMI, Part II: Tips from the Trenches
• Agile Deadline Ahead: Calculating Velocity
• Good Agile Is Messy Agile
• Reducing Agile Project Costs With Amortization
• Agile Expressionism 101
• Agile Advice: Don't Be Elite, Be Obsolete!
• Delegated Authority: An Agile Trust Experiment
• Making Agile Compromises
• Motivating Your Agile Team
• The Agile Act of Continuous Delivery
• Learn Faster with Agile Spikes
• Getting Things Done the Agile Way
  

Below are the assessment specifics for this area. Please see the introduction article for a description of the 0-5 scoring methodology referenced. While not shown below, zero should be used when there is no capability in any particular area.

Area 6: Project Management Scoring

A. Kanban

1. The team understands the basic concepts of Kanban but is not yet applying it to their work, e.g., they took a class or read some books or articles.
2. The team has a basic Kanban process defined with work queues. WIP limits may or may not be defined. There is only a general understanding of the work to be done in each queue.
3. The team has a basic Kanban process defined with work queues, WIP limits, and explicit criteria for the work to be performed in each queue (e.g., entry criteria, activities and exit criteria).
4. The team is managing their Kanban using metrics (e.g., velocity, cycle time, cumulative flow diagram) to measure their performance.
5. The team actively experiments with new methodologies and practices and is using metrics from the Kanban to measure the effects.

Principles: Value Delivery, Harnessing Change, Frequent Delivery, Business and Development Collaboration, Empowering the Teams, Communication, Measuring Progress, Sustainable Pace, Self-Organization

B. Reporting

1. The team seldom reports progress, status, etc. and only on an ad hoc basis.
2. The team has some basic reporting information they share out, e.g., at the demo
3. The team has a regular reporting cadence with defined stakeholders. This does not necessarily mean written reports. However, the team has defined ways to keep stakeholders and management informed with the information they need and want.
4. The team is measuring the effectiveness of their reporting mechanisms and adjusting to improve.
5. The team actively experiments with new reporting mechanisms and is using metrics to measure the effects.

Principles: Business and Development Collaboration, Communication, Measuring Progress

C. Meeting Records

1. Some meetings may have distributed minutes on an ad hoc basis.
2. The team is attempting to create a team approach to capturing meeting minutes and decisions.
3. The team regularly captures meeting minutes, decisions and action items. There is a basic process to follow through on outstanding items.
4. The team is capturing metrics about their ability to follow through on outstanding meeting actions and decisions.
5. The team actively experiments with new methodologies and practices and is using metrics to measure the effects

Principles: Business and Development Collaboration, Communication, Self-Organization

D. Milestone Review

1. Milestone reviews happen on an ad hoc basis.
2. The team is attempting to have milestone reviews on a regular basis.
   
3. Milestone reviews are occurring on a regular basis and influence the future work of the team.
4. The team is capturing metrics from their milestone reviews and is using them to improve the reviews.
5. The team actively experiments with new methodologies and practices for a milestone review and is using metrics to measure the effects.

Principles: Value Delivery, Harnessing Change, Frequent Delivery, Business and Development Collaboration, Communication, Measuring Progress

E. Staffing

1. The team is staffed with available people regardless of skill set.
2. Team staffing is attempted to be based on the needs of the team but the organization struggles to provide people with the right skills and abilities.
3. Team staffing is based on the needs of the team. When the team identifies a need for a new team member or that the team is overstaffed, the organization is able to respond effectively.
4. The team measures the effects of staffing changes on team effectiveness. This is used to improve future staffing behavior.
5. The team actively experiments with different staffing profiles in order to achieve a desire effect and is using metrics to measure the effects.

Principles: Value Delivery, Empowering the Teams, Sustainable Pace, Self-Organization

Risk Management
Every project has risks, many being out of your control. It's what you do about it that is under our control. With agile, pretty much everything we do is about risk mitigation. We automate tests so we can ensure a quality design and catch defect regressions. We implement small stories so we don't run a high risk of building the wrong thing. We retrospect regularly so we catch problems early. We keep things simple so we don't run the risk of spending too much or too long on the wrong things. We address technical risks early with spikes but we delay decisions until the last responsible moment to reduce the risk of making the wrong decision. But even with all of this in place, we still need to manage the risks that are outside of or just on the fringes of our control.

I have discussed Risk Management in these previous Agile Architect articles:

• Agile and CMMI, Part II: Tips from the Trenches
• Reducing Agile Project Costs With Amortization
• Protecting Your Fragile Agile Culture
• Yes, with Agile There Is Time To Think!
• In Agile, Simple Is Not...
• Finding the 'Simple' in Agile
• Agile Advice: Don't Be Elite, Be Obsolete!

Area 7: Risk Management Scoring

A. Risk Identification

1. The team has tribal knowledge of high level risks to the project.
2. The team is trying to create a process to identify new risks.
3. The team has well defined practices and procedures for identifying new risks.
4. The team is actively identifying new risks and measuring how effective their risk identification process is.
5. The team actively experiments with new methodologies and practices to identify risks and is using metrics to measure the effects

Principles: Value Delivery, Frequent Delivery, Business and Development Collaboration, Communication, Technical Excellence, Continuous Improvement

B. Risk Monitoring

1. The team has tribal knowledge of high level risks to the project and occasionally thinks to monitor them.
2. The team is trying to create a process to monitor known risks.
3. The team has well defined practices and procedures for monitoring known risks.
4. The team is actively monitoring known risks and measuring how effective their risk monitoring process is.
5. The team actively experiments with new methodologies and practices to monitor risks and is using metrics to measure the effects.

Principles: Value Delivery, Frequent Delivery, Business and Development Collaboration, Communication, Technical Excellence, Continuous Improvement

C. Risk Mitigation

1. The team uses tribal knowledge of high-level risks to decide when to mitigate a particular risk. Usually this happens once the risk becomes reality at least once.
2. The team is trying to create a process to manage risk mitigation.
3. The team has well defined practices and procedures for mitigating risks.
4. The team is actively applying risk mitigation strategies and measuring how effective their mitigations are.
5. The team actively experiments with new methodologies and practices to mitigate risks and is using metrics to measure the effects.

Principles: Value Delivery, Frequent Delivery, Business and Development Collaboration, Communication, Technical Excellence, Continuous Improvement
Organization

About Organizational Support and Change Management
Organizational Support and Change Management are two sides of the same coin. Organizational Support is about making sure the agile teams have what they need from the organization to be successful. Change management is about the agile teams making sure that the organization has what it needs to work with and exploit the successes of the agile team.

For an agile team to succeed, they must have the support of the organization that surrounds them. An agile team that works without support will quickly find itself distracted and drowning in the demands of the organization in which it finds itself at odds.

Change Management is an important and often overlooked ingredient for the success of an agile team. Related to Organizational Support, Change Management ensures that the rest of the organization understands what the agile teams are doing and why. It allows other people and departments to understand their role in the agile process and how they interact with these new, all-different teams. It also allows people to understand how their jobs may change without creating the fear of job loss that can occur when changes are happening that people don't understand. Too often I've seen people become protective of their non-agile practices because they fear their job or their colleague's job will evaporate with the wave of change that can happen during an agile transformation.

The assessment questions below are intended to assess an organization's support and change management efforts for agile software development teams, not for the question of whether the entire organization is agile.

I have discussed Organizational Support in these previous Agile Architect articles:

• Picking an Agile Pilot Project: First Impressions Matter
• Measuring the Business Value of Projects with Agile
• An Agile Holiday Open House
• Protecting Your Fragile Agile Culture
• Conducting the Agile Interview
• Delegated Authority: An Agile Trust Experiment
• Agility and the Annual Review
• To Think Agile, What's the Real Question?

I have discussed Change Management in these previous Agile Architect articles.

• You Can't Do Agile If You Haven't Seen Agile
• Picking an Agile Pilot Project: First Impressions Matter
• Breaking Through Development Project Barriers
• An Agile Holiday Open House
• Protecting Your Fragile Agile Culture
• Conducting the Agile Interview
• The Survivor's Guide to Agile
• Agile TBD
• Does Agile Apply To You?
  

Area 8: Organizational Support Scoring

A. Learning Culture

1. The organization is fixed in its culture and is only begrudgingly willing to learn if a business crisis necessitate it.
2. The organization is willing to learn but doesn't know how. They are attempting to address this.
3. The organization has a learning culture and is supportive of the changes that agile is bringing to the team.
4. The organization is eager to learn. They are aware of the successes of the agile team and wants to expand the success to the rest of the company.
5. The organization has an advanced learning culture. They have mechanisms to measure the effects of their learning experiments and experiences and use it to drive future learning.

Principles: Harnessing Change, Empowering Teams, Sustainable Pace, Technical Excellence, Continuous Improvement

B. Agile Champions (e.g., CEO)

1. The team has an agile champion in a mid-level manager. There are no other champions
2. There are multiple agile champions in the reporting structure from the agile team up the reporting chain
3. There is an agile champion at each level of the reporting chain and across other departments that interact with the team.
4. The company as an organization is championing agile with broad support across the organization.
5. The company as an organization has embraced agile is working with partners to bring agile to them.

Principles: Business and Development Collaboration, Empowering the Teams, Communication, Self-Organization

C. Organizational Governance (Impact on Team & Company Interaction)
Note that is this category, a zero indicates that the company has an organizational governance structure that inhibits agile transformation.

1. The company has no organizational governance.
2. The company has an organizational governance structure that is neutral to the agile transformation.
3. The company has an organizational governance structure that encourages the agile transformation.
4. The company has an organizational governance structure that is willing to incorporate the agile principles into their governance strategy and measure the effects of those changes.
5. The company has an organizational governance structure that encourages experimentation and measuring the results.

Principles: Value Delivery, Business and Development Collaboration, Empowering Teams, Communication, Sustainable Pace, Technical Excellence, Self-Organization

Area 9: Change Management Scoring

D. Internal Change Management

1. The agile transformation leadership makes ad hoc attempts to communicate the changes and benefits of agile to the team.
2. The agile transformation leadership is attempting to make regular and diverse communications to the team on how important the agile transformation is.
3. The agile transformation leadership has a robust change management strategy to explain to the team the benefits of agile, how it works, and how it affects them.
4. The effects of the change management plan are measured and the plan is adjusted accordingly.
5. The agile transformation leadership actively experiments with new methodologies and practices for their change management plan and is using metrics to measure the effects.

Principles: Value Delivery, Harnessing Change, Business and Development Collaboration, Empowering the Teams, Communication, Self-Organization

E. External Change Management

1. The agile transformation leadership make ad hoc attempts to communicate the changes and benefits of agile to the rest of the organization.
2. The agile transformation leadership is attempting to make regular and diverse communications to the rest of the organization.
3. The agile transformation leadership has a robust change management strategy to explain to the rest of the organization the benefits of agile, how it works, and how it affects them.
4. The effects of the change management plan are measured and the plan is adjusted accordingly.
5. The team actively experiments with new methodologies and practices for their change management plan and is using metrics to measure the effects.

Principles: Value Delivery, Harnessing Change, Business and Development Collaboration, Empowering the Teams, Communication, Measuring Progress, Self-Organization