Agile and the Enterprise Part 1: Project and Portfolio Management

Can Agile be scaled to an Enterprise level? A typical enterprise,  for example a large national or multi-national bank,  is a monolith of an organization that employs thousands of people, services millions of customers and is always bound to government regulations and audits. These organizations often contain large and complex (and often rather old) IT systems backing their myriad of products, services and business processes.

 

When trying to promote Agile development methods at an organization like this, the hurdles are plentiful. These groups often struggle with:

 

  • Using countless technologies
  • Working with vendors located across the world
  • Having numerous dependencies on other systems that do not follow your Sprint timelines
  • Dealing with project management that imposes Waterfall-style milestones regardless of the development methodology the project is using

After examining these struggles, one is left wondering, “How can Agile possibly scale to the organization’s multiple applications, and the program and portfolio management?”

 

It is obvious that focusing on lower-level development techniques does not address project management at the strategic level. The good news is that the past few years have seen the emergence of techniques attempting to address this—the most referenced is Scaled Agile Framework’s “The Big Picture” (scaledagileframework.com).

 

The problem with many project management offices is that they have a “legacy mindset”. By “legacy” we mean Waterfall-style of project management. This is expected, because the practice of project management is not restricted only to IT projects. The Waterfall model itself stems from software engineers looking to manufacturing and construction projects for inspiration. At the time the model was proposed, it was the best that we had, and it stuck.

However, when the model was tuned to physical systems, we soon realized that the development of software systems lives in a very different context. You wouldn’t expect a brand new office building to be ready in one month, but you can demand such velocity for your application changes. You wouldn’t expect to be adding new design features to that office building every few weeks, but changing and polishing business requirements is common. Software applications model business processes, underpin your products and services, and are closely tied to your competitive advantage.

 

Investment decisions

To understand portfolio management from an agile perspective, we need to start at the project investment stage and recognize how investing in an agile project differs. We are used to determining how much projects cost by simply looking at time and resources required. In a Waterfall world, these values are derived from project scope. However, the Agile model forces the requirements to be variable and adapts these as required, causing the scope to be rather dynamic. This can wreak havoc on traditional estimation and investment methods.

 

The Agile methods require us to come to terms with the fact that scope and the timing of delivered items will be uncertain. However, the highest priority items will always be delivered first via pre-determined release schedules. This converts the big upfront project investment into an investment “stream”, where budget is allocated in an incremental fashion to the highest priority items.

 

Enterprise Releases

One aspect preventing Agile from scaling is the fact that it deals with managing a single development team—and often a single application. This is where techniques such as scrum of scrums and Agile Release Trains help to span Agile across multiple teams and multiple applications. Scrum of Scrums brings together multiple development teams with interfacing system components. Agile releases encapsulate multiple sprints, and often multiple teams, in a larger iteration with the aim of facilitating a production release. This arrangement results in release planning activities that differ from the typical Waterfall project-style Gantt charts. The timelines are a set of pre-determined fixed boxes, while the content of each release is planned discretionally.

 

Another reality in today’s large organisations is that not all teams, even not all members of the same team, are located in the same geographical location. Online agile management tools, such as our own HP Agile Manager, assist with collecting and reporting on the work being done at a sprint and release level—especially in a distributed environment.

 

Milestones and Project Tracking

Many large organizations use the Stage Gate® system at the portfolio management level. The system is essentially based on the Waterfall model phases, with gates between each phase dictating the checks that need to be passed. It is not hard to see how complete misalignment of project priorities can occur when an Agile teams attempts to retrofit their reporting into the Stage Gate® structure.

 

 In an Agile world, a Milestone is essentially the end of iteration, where a review is conducted to analyse the iteration success. Release tracking items include reports such as:

 

  • Burndown charts
  • Velocity charts
  • Number of stories accepted
  • Number of test automated
  • Number of defects raised

An Agile project management office may work with different levels of milestones, such as reviews of individual sprints and reviews of overall cross-product releases. An additional milestone specific to large distributed systems is periodic synchronization of multiple systems – in the Waterfall context you may refer to this as the System Integration Testing.

 

Be sure to visit our dedicated Enterprise Agility page to find out how HP can help in this space.

 

Have you tried scaling Agile to Project and Portfolio level? What are you experiences?

 

 

The views expressed in my contributions are my own and do not necessarily reflect the views and strategy of HP.

 

 

References:

Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley, 2011.

 

Leffingwell, Dean. Scaling Software Agility: Best Practices for Large Enterprises, Programs, and the Enterprise. Addison-Wesley, 2007

 

Scaled Agile Framework. URL:  http://scaledagileframework.com. Retrieved on 22 May 2013.

Comments
Robert Biewolf(anon) | ‎06-27-2013 03:08 AM

Dear KateD,

 

Indeed you touch an interesting point, not just from an execution and management control perspective. The biggest questionmark right now that I have, has to do with the phase prior: the bid phase. How does one then bid and size a typical few 100M dollar project in case it is to be based and executed with Agile in mind. Any examples to share? it might not be an issue at all of course, assuming there is at such instance sufficient granularity and in depth understanding of what is all takes, such that Agile just boils down to a seqeuencing execercise. However, I figure it isn't that simple. Hence the question.

Regards,

Robert

 

KateD | ‎06-27-2013 04:38 PM

Hi Robert, 

 

You raise an interestring question. 

A fixed bid contract requires upfront estimate of time, budget and scope, however it is not news that in reality scope creeps and changes. It may in fact be more predictable and beneficial to plan for regular reviews of the scope to control for this.

You're right, it is advisable to have a good idea of deliverables and some history of velocity to understand the required timelines. But it also requires a cultural shift on the customer side to recognize that they cannot envision the entire scope upfront, allow room for movement, and be prepared to work closely with the vendor.

 

 

KateD

 

Leave a Comment

We encourage you to share your comments on this post. Comments are moderated and will be reviewed
and posted as promptly as possible during regular business hours

To ensure your comment is published, be sure to follow the Community Guidelines.

Be sure to enter a unique name. You can't reuse a name that's already in use.
Be sure to enter a unique email address. You can't reuse an email address that's already in use.
Type the characters you see in the picture above.Type the words you hear.
Search
Showing results for 
Search instead for 
Do you mean 
About the Author
Featured


Follow Us
The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation.