Posts Tagged With: Change management

Impacts of traditional project funding models on agile delivery

In one of my previous articles I’d written about the need for change across multiple areas of an organization when undertaking an agile transformation. A key enterprise partner is the Finance department and the organization’s model for project funding will have significant influence over successful agile delivery.

Traditional project funding models are anchored to periodic (annual, semi-annual or quarterly) portfolio re-planning exercises which ingest updated forecasts for active investments and funding requests for new ones. The funding approach for an investment might be one time lump sum, split into two pieces (e.g. seed and remaining), or progressive through the use of funding tranches.

The challenge with all of these funding approaches is that they are based on an estimated cost of a project rather than the funding we wish to allocate to a product, capability or service.

So what challenges arise from a project-centric funding model?

It can result in higher risk, premature financial commitments.

Even in those cases where a funding tranche approach is used, the expectation is that the estimate for the current funding request will be at a high level of confidence. Now nothing prevents project teams from requesting a minimal amount of funding (e.g. one sprint’s worth), but in most cases, project funding approval processes are not lean enough to encourage such behavior. Given this, teams choose to make a funding commitment tied to a major milestone such as a release which might span multiple sprints worth of work. The danger in this is that unless we have a long lived team with predictable velocity working on a well understood product, the level of confidence in the work to be done and how complex that work is will drop the further out we go resulting in a team being at risk of a cost overrun.

Now you might say that agile delivery approaches can work when we fix cost and time and let scope or requirements be the variable. This is true, but how do we know how much to budget up-front to be confident in meeting business needs?

It can also encourage sloppy product management.

When product owners receive funding for a single project and don’t have any guarantees that they will receive funding for follow-on work, it is tempting to throw everything and the kitchen sink into the project backlog and to procrastinate on making tough prioritization decisions. With product-centric funding, the product owner can effectively prioritize the product backlog with confidence that there is available funding for incremental evolution of the product’s capabilities.

Moving from a project-based to a product-based funding model is a challenging people, process & technology change, but will be a powerful accelerator for your agile transformation.

 

 

 

Advertisements
Categories: Agile, Project Portfolio Management | Tags: , , | 1 Comment

Gantt charts still have a place in the agile-verse!

Those of you who have followed me for a while will know that I value pragmatism over absolutism when it comes to delivery practices, tools and techniques. Pick the right tool for the right job should be a guiding principle followed by all project teams.

Easier said than done!

It is difficult when enterprise standards dictate a fixed tool set, but it is even more challenging when a company is undergoing a fundamental transformation of its delivery practices. When adopting new delivery frameworks it is tempting to embrace the bright, shiny new tools while branding those of the previous delivery approach as obsolete, but if we understand the context in which their usage will still add value we should still find a home for them in our toolboxes.

A good example of this is the use of Gantt charts by teams who are following an adaptive or agile delivery life cycle.

Although Gantt charts have been around since the early 1900’s, just as with people, age is not negatively correlated to value. Tools such as burn-up charts provide an objective means of evaluating progress towards completing a release, but it is rare outside of pure product development contexts to find projects where a traditional representation of a schedule wouldn’t also provide some incremental benefits.

This need could arise from any of the following causes:

  • Complicated dependencies between the outputs from different teams
  • Work streams that are delivered using traditional, deterministic life cycles
  • Activities performed by supporting roles working outside of the agile teams

The project team will want to define the best way to combine the use of traditional and agile scheduling tools to avoid information duplication and inconsistency. Agile teams can continue to use their default tools, but traditional scheduling tools can be used to track other work which is not captured in the backlog yet still needs to be completed for project success. If there is a need to have an overall integrated project schedule, the agile teams’ sprints can be shown as a series of sequential fixed duration activities without the need to decompose those to any lower level. By reviewing burn-up charts, the exact number of such sequential activities can be adjusted to reflect accurate completion dates.

With significant change, there is a greater likelihood of success if you preserve valuable current practices when introducing new ones.

Categories: Agile, Facilitating Organization Change, Project Management | Tags: , , | 2 Comments

Are your agile transformation blockers like agents in The Matrix?

Agile transformations are susceptible to a variety of impediments but sometimes these hurdles are not as high as we believe them to be.

In almost any company other than a startup, some or all of the following tangible blockers will not only be present at the beginning of the journey, they may continue to stymie teams years into their transformation.

  • The inability to dedicate primary roles (e.g. Product Owners, Agile Leads) to a single value stream
  • Geographic dispersion and distribution of team members
  • Legacy integration requirements which throttle the pace of continuous integration or continuous delivery
  • Complex compliance requirements
  • Onerous and inefficient procurement policies
  • Labor contracts or other constraints on developing generalizing specialists
  • The lack of comprehensive automated test suites or similar accelerators
  • Delivery and control partners who cannot be influenced to transform their delivery models

Are these likely to disappear quickly? Not likely. Some such as technical debt or legacy integrations can be eliminated over time with persistence and sustained investment but others are a natural by-product of a company’s industry, the free market or globalization.

So when I hear teams complaining about these blockers during their daily stand-ups or in their retrospectives I recall Morpheus’s exchange with Neo at the beginning of The Matrix.

Morpheus: To your left there is a window: open it… use the scaffold to get to the roof.
Neo: No way. No way. This is crazy.
Morpheus: There are two ways out of that building: one is that scaffold, the other is in their custody. You take a chance either way: I leave it to you.

Neo’s fears and doubts are more crippling than the lack of a dumpster below his office building which he could jump into or a fire escape ladder close at hand to get to the roof.

As the movie progresses, Neo continues to struggle with overcoming these constraints and Morpheus continues to coach him: You have to let it all go, Neo. Fear, doubt, and disbelief. Free your mind.

But Morpheus, like agile coaches, can only show the way.

Teams, like Neo must walk the path themselves. Once Neo understands the Matrix for what it is and embraces his place in it, his perception of limitations including agents evolves such that he no longer perceives them as great a threat as he and others make them out to be.

Once teams successfully adopt the right mindset, they can respect the impact of organizational blockers but continue to discover ways of being agile.

 

Categories: Agile, Facilitating Organization Change | Tags: , , | Leave a comment

Blog at WordPress.com.

%d bloggers like this: