Yesterday, I gave the keynote at Rally’s live and virtual Agile Portfolio Management event in Dallas. The event was quite a success and I think everyone, including the presenters, learned something useful. My keynote presentation, Agile Portfolio and Program Management in the Scaled Agile Framework, is here:
Category Archives: Agile Porfolio Management
Webinar Tomorrow: Agile Portfolio and Program Management
Sorry for the late post (had a nasty bug lately), but tomorrow I’m keynoting a live Rally in-person (we are here now, in Dallas, Texas ) and virtual event (live webinar) entitled Agile Portfolio and Program Management in the Scaled Agile Framework. In this webinar, I’ll be discussing the important role that an APPMO (Agile Portfolio and Program Management) organization plays in 1) Strategy and Investment Funding, 2) Program Management and 3) Governance. I’ll also be describing some of the legacy mindsets that can prevent a truly agile approach to these functions, and more importantly, what can be done about it. I’ll provide a brief update on the development status of the Scaled Agile Framework as well.
Rally will also showcase their new solution – Rally Portfolio Manager – which supports high-level program prioritization, team and project alignment to investment strategy, business view of program status, fact-based governance, and Roadmapping. If you are engaged in any of the portfolio or program management functions in your enterprise, you should take a serious look at this solution. (Yes, of course, a fool with a tool is still a fool, but an enterprise without an effective strategy for tooling large-scale agile development may be the biggest fools of all).
Chad Holdorf, agile ninja at John Deere, will also be describing some of his real-world experiences in bringing agile portfolio management thinking to John Deere’s Intelligent Systems Group.
The event will start at 9 AM CST and you can register here.
Rally will make the recording available post-event, so I’ll provide an update here as soon as its posted.
Tracking Large Scale Customer Releases
A few days back, my colleague, Chad Holdorf, published a video blog post illustrating one way to track enterprise-scale releases (using Rally tooling in this case). The post is here.
http://www.scaledagiledelivery.com/2011/07/01/how-to-track-customer-releases/
They’ll be more on Chad’s work in an upcoming post about John Deere’s implementation of agile at enterprise scale. That should make an interesting case study, which Deere has graciously allowed us to publish as a work in process.
Agile Portfolio Planning and Business Epic Kanban System Overview
My colleague and “agile ninja”, Chad Holdorf, has been working with agile at enterprise scale for some time now. He has adopted the Big Picture from my Agile Software Requirements book, which he describes as a “Scaled Agile Delivery Model” (I like that name a lot; I might even adopt it). Recently, he has been working at the portfolio levels of the enterprise to effect lean and agile thinking there too, and to provide a systematic way of moving projects from the portfolio (enterprise backlog) into development via a set of Agile Release Trains. He’s using the enterprise backlog model I described on my blog and the paradigm of the business epic kanban system , which I describe in Chapter 23 – Investment Themes, Epics and Portfolio Planning, of ASR. He has just published a short video/blog post that summarizes this system brilliantly. Check it out at: http://www.scaledagiledelivery.com/2011/04/22/agile-portfolio-planning/.
In addition, as agile tooling is a necessary condition for success at enterprise scale, he’s been collaborating with Catherine Connor at Rally (as have I) on the development of their new portfolio planning tool called “Stratus”. Here’s what Rally says about Stratus:
“Rally is previewing Project Stratus, a new application that elevates Agile planning and tracking to roadmap and portfolio levels. Based on collaboration with Rally customers, Project Stratus focuses at the PMO level on:
- Keeping development aligned with strategic business priorities
- Visualizing and managing projects and large features across the entire value stream
- Analyzing the roadmap to optimize delivery of value while minimizing risk
- Strengthening feedback loops between the PMO and development teams”
Now ideally, any method (with tooling) that really supported enterprise-level, agile portfolio planning would accomplish a number of objectives:
- make the backlog of potential and current portfolio projects visible
- provide wip limits so as to keep the full system in maximum productive flow
- provide a persistent, single version of the truth in the enterprise (avoid dueling spreadsheets/tools)
- provide visibility for how current development activities correlate to the enterprises current investment themes
- provide a capacity-based, systematic way of driving new epics into development
I think you’ll see from Chad’s video, that this system has the potential to accomplish all these objectives.
One last comment: Great job Chad and Catherine! This is clearly “new knowledge” that can help most every agile enterprise.
Release Predictability Metric
I’ve been using a “Release Predictability Metric” (RPM) on a number of larger agile programs. The goal of this key metric is to help the teams achieve a level of program predictability that their enterprise stakeholders can count on, while still allowing for taking on the reasonable risks that are necessary for innovation , as well as stretching to the maximum potential achievements in a PSI time box. In describing it to a colleague, I realized I had never blogged about it, so I’m posting this excerpted content from the new book to address that oversight.
=====================
Measuring Release Predictability
If you ask top executives what they would most like to see out of the software development process, many will answer “predictability”. And that is one of the many challenges in agile. We can reliably predict quality (by fixing it and adopting effective technical practices) and date (by fixing it) and cost (by fixing the team size and the PSI date) – but we can’t actually predict functionality – at least in the longer term. If we did, we’d be right back in the iron triangle that has served us so poorly in the past. Moreover, if we predicted and controlled functionality long term, then we’d have to temporarily ignore the variability and new opportunities the market presents. That isn’t agile.
However, as professionals, we must be able to provide our enterprise with a reasonably reliable predictor of upcoming events, at least near term, as well as some sense of the future product Roadmap that we intend to execute.
When implemented properly, the Agile Release Train can provide just such a predictability measure, at least for the next PSI (or maybe two). That gives the enterprise from 3-6 months of visibility into upcoming release content – enough to plan, strategize and support with market communications, release launches, etc. The release objectives that we established during release planning are our primary means to do this.
At release planning time, each objective is given a business value, assigned by the business owners for that program or subdomain. During each release retrospective, the teams meet with their business owners to self-assess the percentage of business values they achieved for each objective. This can be done both at the team and program level. For example, a program might rate its accomplishments as follows:
Actual Vs Plan Release (PSI) Objectives
Release Objectives Process Control Band
In the example above, the program accomplished 79% of its release objectives. The questions arises – how good, or bad, is that? To answer this, we must return to our lean principles and the context for the enterprise program itself.
On the surface, at least, it might appear that accomplishing 100% of release objectives is the only worthy goal. Closer analysis, however, tells us differently. In order for a team to routinely accomplish 100% of its release objectives, they must either
1) drive all risk out of the plan by eliminating or curtailing innovation and risk taking
2) back off so far on objectives so as to assure completion
Neither of these optimizes the economic impact of our efforts. To achieve that, we need to operate successfully in some acceptable process control band, so that the program has reasonable predictability, and yet allows for the variability, “optionality”, and stretch goals inherent with software development.
In our experience, a program that can reliability achieve most of its release objectives is a trusted program that is an extraordinary asset to the enterprise. In this case, the release predictability measure should fall in a process control band something like that in the following figure over time.
Managing uncertainty with a release (PSI) objectives process control band
In this figure, Team B is predictable, even though they do not routinely hit 100% of their release objectives. They can’t, otherwise there would be no room for innovation and risk taking. However, the enterprise can depend on the fact that they will do most of what they said they would do. Team A, however, is all over the map. It’s hard to manage any program or enterprise with the characteristics of Team A. You simply can’t depend on them to deliver anything like what they predicted.
By creating and measuring this predictability measure at every PSI, the enterprise can eventually achieve the right balance of predictability and risk taking, thereby achieving the optimum economic outcomes.
My Agile Denver Presentation from Last Night
Last night I presented to the local Agile Denver group. This was a variant of my Agile 2010 presentation, but one with a heavier focus on the scalable requirements (backlog) model. The title is:
Scaling Software Agility:
Agile Software Requirements
The content and flow is:
1.Lean and Scalable Requirements Model
Applying the Model
2. The Agile Release Train
3. Rearchitecting with Flow
4. Agile Portfolio Management
I promised to post it, so here it is:
Agile Software Requirements (Agile Denver).pptx
Thanks to Brad Swanson and Bob Hartman for arranging this opportunity.
Agile Portfolio Management Briefing
Tuesday night, I was the guest speaker at a joint meeting of the Denver chapter of the International Institute of Business Analysis (IIBA) and the newly formed Denver chapter of the Agile Project Leadership Network. We had a good crowd of 50-60 or so Business Analysis, Project Managers and the like. While most of the Business Analysts in the group were fairly new to agile, the attendees from APLN, of course, had more agile experience.
My topic was “Moving to Agile Portfolio Management”. The topic was of great interest to many in the group and we had a lively discussion about the issues of evolving the enterprise to take a more agile approach at the portfolio, as opposed to project or program, level. Of course much of this discussion revolves around the legacy (fixed budget-fixed scope-fixed timeline) thinking that is predominant in so many PMO offices, and how that thinking can be a major inhibitor to the achievement of real agility at the enterprise level. More importantly, we also discussed some ideas as to what to do about it.
I promised to post the slides from that presentation, so here they are. agile-porfolio-management-denver-apln-mar-2009
If you are a business analyst or project manager starting to see agile in your present or near future (and who isn’t?) you owe it to yourself to join one of these organizations.
Enterprise Agility – The Big Picture (14b): More on Agile Portfolio Management and the Legacy Mindset
Note: This is part of a continuing series (see the Big Picture Category on this blog) wherein we introduced an overview graphic intended to capture the essence of enterprise agility in a single slide. In a series of continuing posts, we have been working our way from the bottom (stories, iterations and the like) to the top where the enterprise vision and portfolio management resides. This post is one in a miniseries describing the last big icon on the upper left – Agile Portfolio Management.
The Big Picture - Agile Portfolio Management
In the last Big Picture Post, we introduced the portfolio, along with the challenges that agile teams are likely to find as the impact of their new and more productive models wends its way to the Project Management Office (PMO), which in some cases can be the “mother ship of potential agile impediments.” We also introduced the excellent DTE energy case study: Establishing an Agile Portfolio to Align IT Investments with Business Needs. This case study is an example of how an agile enterprise can first recognize, and then successfully address the significant changes necessary to allow the emergence of true enterprise agility benefits.
Since that post, I’ve been thinking that I would expound on the legacy mindsets that called out in the case study. But I’ve decided I can’t. They are just too well done and so symptomatic that I decided just to repeat them here. However, the accompanying descriptions and paraphrasing are my own. These are based on my own experience from two perspectives; 1) then, as an executive, managing portfolios and carrying some elements of these mindsets, and 2) now, as an agile executive attempting to change those very same mindsets!
The legacy mindsets called out in the DTC case study are:
- Widget engineering – The belief that software development is a repetitive, controlled and manufacturing-like business, rather than Research and Development. “Draw it up and build it like you drew it,” goes the thinking.
- Order Taker Mentality – Also known as “build what we tell you to build”. Founded on the belief that the customer is always right, seemingly all-knowing and under the assumption that they actually know what their requirements really are. The teams should just build it.
- Maximize utilization- The belief that if all resources aren’t fully utilized on paper then they won’t be fully utilized in practice. “They’ll just be idlers, wasting their time, waiting for their next assignment.” goes the thinking. “Fully assign them or lose them”.
- Control through data – The belief that
with the right kind of data – earned value metrics, design reviews, requirements and test plan inspections – we can tell where we are on the project. And then if we still can’t tell where we are, we’ll just ask for more detailed data until we can. - And we can plan out a full year of projects- Conveniently disregarding our last 20 years or so of experience in failing to predict projects a year in advance, we assume it’s a failure of our planning, not a failure of the basic paradigm. “If we only planned in more detail, we could really get it right this year.”
- Get it Done – The belief that our best case plans can be reality if we only try hard enough.
Also known as: “That was the plan we agreed to, now execute it.” And “when the going gets tough, the tough get going”. And lastly, the infamous “we know it’s impossible, that’s why we hired you for this job.”
Perhaps it’s obvious from my elaborations that I tend to get somewhat passionate about this topic. Perhaps it’s because my guilt shows through. Surely, I have been on the other side of this fence before iterative and incremental, and now agile, development methods proved their extraordinary worth. So, I know as well as any that if these legacy mindsets are not addressed, they will kill the agile enterprise initiative as surely as a fixed content/fixed schedule 60 hr/week death march.
Here’s why. The table below shows the manifestation of these problems in practice (as described by DTE along with a few of my own) and the real problems they create for the nascent agile teams.
| Mindset | Manifestation | Problems |
| “widget engineering” |
Fixed schedule, functionality planning Big Up Front Design/Analysis (BUFD) |
Long range plans Resources fully committed up to a year in advance Analysis paralysis |
| “order taker mentality” | Build what we tell you to build We are the boss of you |
False agreements. No buy in. Misses innovation contribution from teams Failure to meet expectations Mistrust No empowerment, lower motivation |
| “Maximize utilization” | Resources committed long range 100% allocation before “what if” Key resources assigned to multiple projects |
No time to think or innovate Dedicate resources to task or lose resources Thrashing – lost productivity of most valuable resources Exhaustion, burnout |
| “we can plan out a full year of projects” | Detailed wbs, earned value metrics, fully loaded Gantt charts | Plans are immediately obsolete, but not treated that way Earned value metrics don’t reflect actual progress |
| “Control through data” | Fine grain reporting and overhead Milestones that are not reflective of process or progress |
Reporting overhead slows actual development Annoys and de-motivates the teams |
| “Get it done” | Belief that best case plans must succeed | Deferred recognition of plan vs. actual Late discovery and re-negotiation Loss of credibility, mistrust |
You’ll probably recognize many of these mindsets, manifestations and the problems they create for the development teams. Many enterprises do. In one recent presentation I made highlighting the DTE case study, one PMO executive said “just delete DTE and put in [our company name here] and there you have it”!
Well enough crabbing and I’m sorry if I offended anybody. I just thought it important to walk through this pain field one last time, making sure we understand the problem so that the imperative for a solution is really, really apparent.
In the next post in this series, I promise to move to a more productive and proactive set of ideas to address these problems. One giant step further to actually becoming the agile enterprise.
Enterprise Agility – The Big Picture (14a): On Agile Portfolio Management and the Legacy Mindset
Note: In the post Enterprise Agility: The Big Picture, we introduced an overview graphic intended to capture the essence of enterprise agility in a single slide. In a series of continuing post (see the Big Picture Category on this blog ) we have been working our way from the bottom (stories, iterations and the like) to the top where the enterprise vision and portfolio management resides. In this post, we’ll start a miniseries to describe the last big icon to the left – Agile Portfolio Management.
A Particularly Relevant Case Study
Recently, while researching this topic for another purpose, I ran across an excellent case study from DTE Energy called: Establishing an Agile Portfolio to Align IT Investments with Business Needs. The article was written by Joseph Thomas and Stephen Baker and presented at Agile 2008. Unfortunately, I did not attend this presentation while I was at Agile 2008, but I found the whitepaper published in the proceedings. It appears to be available at http://submissions.agile2008.org/files/CD-ThomasBaker-EstablishAgilePortfolio-Paper.pdf and I highly recommend it for those readers of this blog that have
product or asset portfolios (and you know who you are).
Here was the introductory “grabber” for me:
“Those who implement agile software development and agile project management in a traditional corporate environment may encounter legacy corporate and IT processes that reflect legacy mindsets and cultures- These remnant processes, mindsets, and cultures represent opportunities to improve the systemic value that agile approaches are capable of enabling.”
This is a reminder that team agility does not automatically engender enterprise agility and in most all cases, the team is just the beginning. The article is surely relevant to the enterprise perspective, because when it comes to scale, DTE Energy is right “up there”:
“DTE Energy, a Fortune 300 is a diversified energy company involved in the development and management of energy related businesses and services nationwide with $9 billion in annual revenue and 11,000 employees. DTE Energy’s Information Technology Services (ITS) organization, now consisting of over 900 people, provides leadership, oversight, delivery, and support on all aspects of information technology (IT) across the enterprise.”
Illustrating the maturity of thought reflected in the article, DTE Energy’s IT teams have been implementing and extending agile practices in their enterprise since 1998, moving through CMM levels II and III via agile practices. They have almost a decade of agile adoption upon which to build their ongoing learning. As reflected in the case study, DTE also illustrates Kaizen Thinking (continuous thirst for improvement) that is the hallmark of top enterprise agilists. Evidently it is just this thirst that drives the agile initiative ever upward until it hits the level of portfolio planning and decision making at DTE.
The Transformation Starts on the Ground
The title of the article, along with the maturity of DTE’s agile implementation efforts, also reflects the fact that building the agile enterprise is a “ground up” exercise. The primary work must start with the development teams themselves. They build all the code. If they aren’t agile, no one is. Thereafter, dealing with many of the challenges at the corporate level, (with the Project Management Office (PMO) often being the control room of the mother ship) is likely to be a significant challenge that must be addressed. For it is there that projects and programs are initially formed, budgets and resources are determined, governance is established and longer term (and not particularly agile) external commitments are typically made. If not successfully transformed, many of the potential benefits of the agile enterprise – time to market, productivity and quality, ROI, revenue and profitability growth – may be heavily mitigated.
However, this next set of enterprise challenges is most easily addressed after the teams have first demonstrated the substantive productivity and quality improvements of the methods. That way, they’ll be standing on their accomplishments and can serve as an object lesson in what agile could do, if only unfettered.
But for readers of this blog series now is a later time and it’s time we addressed the big “portfolio” icon on the top left of the Big Picture
Legacy Mindsets Can Hinder Potential Enterprise Benefits
DTE’s whitepaper starts with a discussion of the various legacy mindsets that can inhibit achievement of the full benefits of the agile enterprise. These include: “widget engineering”, “control through data”, “order taker mentality” and more. This is an important underpinning for the enterprise transformation we are driving, because one can’t recognize solutions to a problem if one does not understand the problem. These mindsets must be understood and addressed before much agile progress can be made at the portfolio level.
We’ll discuss these legacy mindsets, and more from our own experiences, in the next post.
Scaling Software Agility 