In Waterfall we might need something else, but in Agile, what do we want from an Enterprise Project Management Office (EPMO)? If we have a relatively small company (total employees near 1,000, innovation group near 100). (Obviously, if the company were 300,000 people, it would be a different game.)
Let me discuss this in 7 sections, as follows:
- Premises
- Goals
- Two types of work
- EPMO's role
- Information to provide
- Actions
- Concluding comments
1. Premises
In Agile, we tend to want to keep 'management' light, and an EPMO to many people does not sound light.
In the Scrum community, we are trying to move away from 'projects' and more toward thinking mainly of teams and of releases and of products. So, we think "Team x is working on product Y and expects the next release Z to be coming out in another 5 weeks." This way of thinking typically has several implications:
- We think of customers and business value first.
- We want to release more frequently.
- The old ideas of 'project success' are meaningless.
- We expect almost all products to have a continuing series of releases.
- We look to one Team (or one scaled group) to deliver the releases for one product. It is a real team, with a real mission, and hence, highly motivated. And, usually, because of that, more successful.
Again, there is a sense that 'project success' (as we usually used to think of it) is meaningless. Changing scope - so what? Moving deadlines (as long as we are usually getting quicker releases) -- so what? Conformance to a original schedule per se -- so what? The only thing that matters is business success: and that happens via releases of 'product' to customers. And the people that are clearly responsible for delivering a release are formed into a Team (or a scaled group of Teams).
2. Goals
What are we trying to accomplish through an EPMO?
The main thing is that the ET (Executive Team) knows about the efforts underway, and is able to re-evaluate them and help them. By re-evaluate we mean they can stop them or maybe add something to them (if appropriate). If an effort (team) is in trouble, then the ET could look into fixing the key problem or problems (in Scrum, we call these impediments).
Now, imagine you have 5 Scrum teams working. Clearly the amount of reporting to the ET is relatively light.
So, the ET needs barely enough information to know about and act on things like the following:
- Identify whether the initiative is going well, fairly well or not so well.
- Review the relative benefits, costs and timelines of each release.
- Identify and perhaps address any of the 5 top impediments. (The ET may or may not decide to help with these, for a variety of reasons).
- See the timeline for the next release or two. And whether that is sooner or later than previously stated.
- Review and address any major adjustments in the scope of the release(s). (Minor changes are outside the interest of the ET.)
- Review and address any other major concerns (eg, budget issues, risks, future events, etc.)
- Review and address any recommendations for action (leave it alone, fix an impediment, stop the work, etc.). It is possible that different people might have different suggestions about this. And the ET may need to resolve them.
Bear in mind that every ET is plagued by long discussions that often do not lead to any action. Any EPMO activity needs to address this problem with 'committees.' Hence, lots of information that is 'just to be discussed' is contrary to what we want.
Outcomes:
- A member of the ET may ask to get involved more.
- A member of the ET may see that his/her department may need to get involved in the future (this should have normally been identified and addressed outside any ET meeting, but the ET meeting is also a place where this might be identified).
- Address impediments. There are many types of impediments. One might be: Some chickens are not helping the team of pigs enough, or might cause the release to be delayed.
- Fix certain people issues. eg, Direct that someone be added to or taken away from the Team.
- Approve or decline additional budget (or decide to cancel existing budget, ie, stop the work).
- Direct other significant course corrections. (A catch-all for special situations. We have already mentioned most significant 'course changes.')
Note: In general, we do not recommend any changes in team composition. This is usually harmful and usually reduces team productivity. But sometimes a set of people can be dysfunctional or can be seriously lacking in a skill set, and so some changes must be made. We would expect these to be infrequent, and really more in the nature of 'fixing impediments'.
As implied earlier, each Team will be fixing its own impediments, to the degree it can, and should not be reliant on the ET to fix all the impediments. Although, still, the ET can often help with some impediments.
One of the higher issues for the ET is balancing the relative priorities of one initiative against another. And these can change from time to time, for many reasons. Often the real issue is two efforts are contending for the same people (people that the Team wants as pigs or people that a Team wants as chickens.) This must be resolved.
Also, note: Even a project going well could be stopped, if it has a lower ROI than a new project that those same people might work on. (Obviously, this decision would not be made lightly, and is more involved than I will discuss here.)
Key point: We need the right information to be given to the ET to enable these outcomes.
3. Two types of work
We need to divide work into 2 types: real initiatives and 'other things we are working on.'
The real problem in life is that we try to do 15 things 'at the same time', we end up doing tons of task-switching, and nothing gets finished.
So, the EPMO should only concern itself with 'real initiatives'. If some departments want to or need to do some other minor work, that is for that department to track. Or maybe someone else to track. But it is not an initiative that the EPMO should track (or the ET should review).
In accordance with Lean and other sets of ideas, we strongly urge you to minimize WIP. This means, only have as many initiatives going as you have 'teams of pigs' to do them. This will go a long way toward helping to assure that the most important business value is delivered first, and delivered more quickly. Putting additional work in process only means that the most important things will not get done as quickly as possible, and that people will be doing (more) task-switching, which reduces their morale, their focus, and their effectiveness overall.
There may also be other kinds of work that needs to be reported to the ET. But this work is more in the nature of BAU (business as usual), and, again, is not something that the EPMO should facilitate.
4. EPMO's Role
What is the EPMO's role?
It is only to help clarify the key information to gather, communicate those information needs, and get the information to the ET on a periodic basis.
So, for example, the EPMO should not 'own' people (well, except barely enough to manage the information flow -- if you only have 5 or 10 Scrum teams, that is maybe one person). The EPMO does not do 'real work'...it does not 'do' the projects. One of the reasons to have an independent EPMO is that is does not have any skin in the game, and hence is more likely to be an impartial transmitter of information.
The EPMO must work with both parties (the Teams and the ET) to establish and revise the guidelines for the flow of information to the ET. This will be an evolving discussion of what is the correct, most useful information, given the cost of gathering the information.
Why? Because the information flow must balance the needs of the ET against the needs of the Teams. The Teams want (and the ET wants for the Teams) minimal overhead in producing the information. Invariably it is not really minimal. Similarly, most Teams do not see the bigger picture, and do not appreciate what information the ET needs to make appropriate decisions. So, there is always ongoing discussion of the most effective way to get the most useful information to the ET.
Also, assuming the Teams are respected (is there any other choice?), then a member of each Team should attend the ET meeting, to assure the 'backward' flow of information from the ET to each Team. The EPMO might take minutes of significant Team decisions made by the ET, but the flow of that information should normally be assured by attendance of a Team member.
Here we must digress and speak quickly of the eternal self-aggrandizement of any bureaucratic function. It is the nature of any bureaucracy to seem to want to become larger and make itself more important than it is. And, in addition to the extra costs, this slows down and demoralizes the real productivity engines, the Teams. This must be watched for. Especially since EPMO's tend to be staffed by very bright and very articulate people, who want to feel (more) important.
5. Information to provide
What information should the Teams provide?
Notice that I did not say 'what information should the EMPO provide?' This is because virtually all the real information comes from the Teams. Each Team understands the meaning and the context of the information.
Certainly the EPMO can contribute a little by helping the Teams understand the information and why it is wanted, and help them in collecting it with the least effort. The EPMO might have also a small role in making the information more 'transparent' (more accurate).
In Scrum, we stress the need for transparency. So, much of the best information can be obtained at the main Scrum meetings (the Sprint Planning Meeting, the Daily Scrums, the Sprint Review, and the Retrospective). If there is ever a question about whether the information given to the ET is accurate, then someone going to some of these meetings will identify whether it is (or isn't) accurate.
We obviously prefer that normal Scrum artifacts be used as much as possible. Or other artifacts that the Team has developed for itself for its own needs. And that these artifacts are only minimally revised (perhaps summarized) and given to the ET.
Here are some ideas about information that might be given:
- Current Ranking of the initiative by the ET. (Is it effort number 1, or number 14?). The Ranking was (is) based on ROI in the ET's opinion.
- Green, yellow, red indicator for the overall initiative (in the opinion of the PO). How well is it going, overall?
- Last release date and Next release date. (If changed, then also the prior estimated release date.)
- Release burndown chart
- Velocity of team over the last 5 sprints (and sprint length)
- Two sentences by PO on significant scope changes in the current release (adds, subtracts, etc).
- Two sentences by PO summarizing other substantive changes in last month (a catch-all)
- Access to Sprint burndown charts (maybe useful in discussion). (Perhaps via your Agile tool, such as Jira, Rally, Version One, etc.)
- Expected ratio of BV to cost for the next release. (This is hard for most companies, and may take some time to implement.)
- Happiness indicator for the Team.
- Full Team average vote (1-5 scale) on the next release (how good do you expect it to be, considering scope, date, quality, budget, etc.).
- Top 5 impediments
- Two sentences by the SM about action in the last month on impediments.
- Key risks (if anything substantial)
- Recommendations of Team (or requests for help)
- Recommendations of any other parties
- Any special information for this specific initiative
These are suggestions. Different people and organizations will use others. These should be evolving.
Usually the main criterion for including or excluding information is this question: "Will this information materially affect a key decision by the ET?" It the information is just 'nice to have', it is probably to costly versus benefit.
It is not useful to delay implementation of an EPMO pending some committee or other set of persons deciding on the perfect set of information to provide. In these matters 'waiting for perfection' is ill-advised, and learning from practice is strongly advised.
6. Actions
The ET will often take an action or actions during the meeting on a specific initiative. We would normally expect these to be mainly action on assistance with impediments. In any case, the EPMO person and the ET and the Team involved should track any actions agreed on.
Over time, there may also be discussions of and decisions on what information should come to the ET. More specifically...
- what information should no longer be provided
- what information should be provided for every initiative
- what information a specific initiative should provide.
7. Concluding comments
Finally, let us return to the initial notion. The ET and management does not deliver customer satisfaction. That is done, in Scrum at least, by the real Teams. So, the role of the ET and of the EPMO is rather limited, and in the scheme of things, relatively unimportant.
This is not to say that the 'team is on its own' with no help. And the ET can help a team, or, more accurately, direct that someone should help a team. And some real work may happen at the hands of real managers working directly with a team. So, not all real work will be done by the Team itself.
As a consequence, let us be modest about the usefulness of too much investment in the EPMO and the value of what comes out of ET meetings. It is useful, and we must do it, but the benefits are modest.
There is a different thing that some senior people provide that is crucial. We often call this 'leadership.' The leaders help articulate a vision and a mission that draws out the best in people, the best in the Teams. It inspires them and gives them a sense of purpose. This function of leadership is essential, and, when done well, extraordinarily important.
Some of the key values must be:
- Enable the Team to be motivated
- Get out of their way
- Do not overburden them with 'muda' (Lean term for waste)
- Help the Team
***
These are my current thoughts, expressed quickly. Your comments are welcome.
No comments:
Post a Comment