Flipping the iron triangle

Tech

Flipping the Iron Triangle

BY Jennifer Bleen

Practices such as limiting the amount of work being performed in order to get more work done may seem counter intuitive.

Triple Constant

B

eginning an agile adoption is a disruptive change that impacts not only the processes used by team members performing work, but the organization’s culture and your role as a leader. Agile is a set of values and principles shared by application development and product lifecycle methods and frameworks. Practices such as limiting the amount of work being performed in order to get more work done may seem counter intuitive. In my opinion, the paradigm shifts required are the toughest for leaders. Not because they are difficult, but simply because they are unfamiliar territory. More often than not, no one explained in practical terms what the paradigm shifts really mean for everyday business as usual. In this article we will explore some aspects of one such paradigm shift, the triple constraint or iron triangle flip.

For those of you unfamiliar with the triple constraint concept, an organization

managing projects in a traditional manner will generate a list of requirements up front.

This defines the scope of the project and drives the project’s planning efforts. Estimates and schedules are built based on the scope. The triple constraint is named based on the idea that the three factors of scope, cost and time are all related.

Decisions and changes to one, impacts the other two.

At any point in time you can only constrain two items. For example, I can define scope and let that drive my schedule and cost. If I want to reduce the amount of time it will take to deliver the scope, my cost will change. If I change my cost and schedule, my scope will change. Other models expand the triple constraint to include architecture, risk, quality and/or customer satisfaction as these are also affected by changes in scope cost and time. For our discussion, we will keep it simple and focus on the iron triangle: cost , schedule and scope.

MODERN GOVERNMENT · May - June 2013

7

Before I dive into the paradigm shift, let’s explore the goal of introducing agile.

Fundamentally, the goal is to drive toward predictability, flexibility and quality of our product and service delivery.

We need a way to respond to the ever faster changes in our market place. In addition to fickle consumers and general market place changes, government organizations may experience change with each election. For some organizations the election changes may happen more frequently than their current project lifecycle. A new law maker governs within the fixed time box of the seat held. Driven to make a noticeable change before the next election, your organization is provided an arbitrary deadline by a law maker to change a manner in which you operate. Many times this is in the opposite direction of the predecessors orders. Introducing agile into your organization is not as simple as mandating all new projects start following agile practices and processes.

Remember, agile is a set of values and principles supported by practices.

Now let us return to the triple constraint flip. Most organizations practicing agile use fixed time boxes known as sprints or iterations to create a potentially shippable product.

The work is ideally performed by a dedicated and consistent team.

Given my team is fixed, I have a fixed cost or run rate for that team. My time is constrained by

8

May - June 2013 · MODERN GOVERNMENT

the time box. If my time and cost are fixed variables, they will drive the amount of work that can be delivered. The scope that can be delivered is the value being created for the organization.

Sounds simple, right? What does this really mean to your organization? Let’s look a couple of the factors.

First let’s explore time. What does it mean to have a time box.

Similar to the law maker in office, your team has a fixed start and end date to deliver work. Let’s understand the assumptions around time. In order to deliver a potentially shippable product in a time box, we must have the right people on the team, they are self-organizing and have the resources available to perform the work needed.

In order to be successful, a team must be accountable and have ownership. Ownership in the deliverable and ownership of the method in which to create the deliverable. Most day to day decision making needs to be within the team. If the team is required to ask permission and gain approvals on all decisions their ability to meet commitments within a time box are hindered.

In my experience, I have found government agencies have a strong military influence.

By nature the military has a dominate command and control culture. Rightfully so, lives are at stake when out in the battle field.

Knowledge workers on the other hand have different needs. Too

Introducing agile into your organization is not as simple as mandating all new projects start following agile practices and processes.

If the team is required to ask permission and gain approvals on all decisions their ability to meet commitments within a time box are hindered.

much command and control can stifle creativity, lower moral and hinder productivity. The trick is to find the right balance between the organization’s strategic goals, the organization’s culture and your leadership style.

Leaders who learn their managing techniques within the military often find it uncomfortable to let go and let their subordinates make the decisions. Many times identity and ego are tied to position and authority. Giving up decision making authority may feel like a loss of power. It also requires trust. Trust in the process and trust in the team. In order to be successful as an agile organization, you will need to allow your teams to make day to day decisions.

To help you over this hurdle, I suggest, you define clear boundaries for decision making.

Set allowable change tolerance thresholds. This is especially useful in union environments.

Clearly defining the boundaries of each role’s authority for decision making around changes and day to day decisions will help set expectations and help keep peace with union requirements. I used this technique with a government, union managed client where agile practices were introduced.

The thresholds defined allowed the product owner to make the priority decisions on work to be completed by the team, this included the robustness of the features to be delivered within the release. However,

IT Investment

One example is to complete unit testing of new features and deploy to a shared system testing environment where dedicated testers are available to finish testing. Then create a technology roadmap to improve your environments to evolve into an agile organization over time.

Another barrier to time is not having the supporting technology to complete work within the time box.

if a feature was to be moved to another release or omitted all together it took a superiors sign-off. For the organization, two sprints would be packaged into one production release. We had created a product roadmap and aligned features to release dates. By making this distinction, the development team was able to explore with the product owner the best way to meet the needs of the organization and deliver on time without having administrative overhead of capturing approvals for each low level requirement. Because we had contracts in place with vendors, thresholds went on to define when procurement was to be involved. More on that later.

Another barrier to time is not having the supporting technology to complete work within the time box. Definition of done is extremely important.

For work to be considered done, a set of requirements must be met. Usually this means the requirements have been fully integrated, tested and are ready

to be delivered to production.

Coupling agile engineering practices such as acceptance test driven development and automated continuous integration with a framework such as scrum will allow an organization most flexibility.

Note, the automation is key.

Without automation, the team will slowly lose their ability to deliver within the time box. For example, a team is building a new application. In the first sprint they build and test the features.

In the second sprint they build features set two and regression test feature set one. In sprint three, they build a new feature set and regression test one and two. If the regression testing is manually completed, the team will get to a point where no new work may be introduced in the sprint as the team regression tests all the prior sprint’s new work. If your organization is in a situation where you do not have the technology to support agile fully, you may need to look at a hybrid model in the short term.

Now let’s look at scope. As we discussed above, if time and costs are fixed then scope varies.

Many government agencies work with vendors based on contracts with defined scope. If scope is variable, how can we measure a vendor’s services for contract payments?

First, let’s remember one of our goals is flexibility to the changing needs of the organization. In order to be flexible, we have to accommodate the changes of the organization needs.

We want to be able to do this without introducing unnecessary administrative overhead. An example of how this was handled at a government agency I coached, was to clearly define the time boxes and roles in the vendor contract. General scope items were identified but not committed. The roles were clearly defined for both the vendor’s roles and the roles to be filled by dedicated full time employees of the organization.

This is a partnership and both parties must be at the table.

The product owner role was defined as the accountable role for directing what was built and the priority. This role was

MODERN GOVERNMENT · May - June 2013

9

If scope is variable, how can we measure a vendor’s services for contract payments?

10

filled by the organization. The organization had clearly defined authority and accountability.

This accountability on the organization is the shift in the paradigm. The organization had a stake in the game and could no longer blame a vendor if something was not delivered since the organization was defining what was to be worked on every step of the way. This also minimized the need for a lot of administrative change control overhead. Remember the change tolerance thresholds we discussed earlier, they also applied for contract changes. If the product owner wanted to add scope that would extend the contracted number of sprints, a contract change would need and require appropriate superior approvals.

As for vendor deliverables, in order to receive payment, the vendor provided sprint reports describing what features were planned and what features were delivered along with end customer reactions to the sprint show and tells. Metrics on the number of points or any other velocity metric were not included. Points are a relative

May - June 2013 · MODERN GOVERNMENT

unit of measure to define the effort and complexity of a piece of work. Velocity is the sum of all work pieces completed during a time box. The team’s track velocity internally to gain insight into predicting the amount of work they are capable of completing in a time box. Points are not transferable to another team. Beyond a team’s use, the values can be misconstrued. For example, if one team reports a 20 point velocity and another reports a 30 point velocity, does it mean the one who completed 30 points did more work? No. If a leader attempts to use this as a means of comparison, the behavior it will drive is inflated point estimates not increased output. Increased out point requires continuous improvement and removing obstacles standing in the team’s way, including unnecessary process.

We have only touched on a few ways one paradigm shift from an agile adoption is a disruptive change. Through knowledge of these changes you will be one step closer to fully attaining the benefits of predictability, flexibility

This accountability on the organization is the shift in the paradigm. and higher quality products and services that agile is capable of delivering. By truly understanding the nature of the disruptions you will understand and respond appropriately to the needs of your team. My parting suggestions for leaders new to agile are have an expert conduct an agile readiness assessment to help you understand where your process and technology constraints exist. Then hire an enterprise agile coach to develop a roadmap for the agile adoption and help you navigate the cultural and leadership style changes required on your journey to becoming an agile organization capable of quickly responding to change no matter which way the political winds may blow. [MG]