- Business justification for the project
- Project costs and time estimates
- Risk Management
We use Scrum, and it is true that framework like Scrum doesn't explicitly include any of the above. And yes, you CAN leverage formal project management methodologies to supplement Agile development, but is this really what you want?
It comes down to this: Your project teams might be Agile, but is the surrounding organization Agile?
If you are operating as an Agile organization, many of these classic project management activities are already handled, without a lot of overhead. Just as a framework like Scrum strips away the bureaucratic overhead from project teams, organizations should assess how the principles of Agile development can be applied towards achieving business agility.
Agile doesn’t mean “no documentation,” and some things might need to be written down – particularly if the information needs to be shared by a great many people over time. But keep the noise down to a minimum. An Agile Organization operates in real time, not through paper.
We need to budget and staff projects just like everyone else, and we create the necessary documentation to share and discuss our justification with others up and down the organizational hierarchy. As a management team we concern ourselves with running the business, constantly evaluating where we are investing our time and effort, the risk/reward tradeoffs, and making real-time adjustments as required.
When it comes to planning, Agile teams can estimate their work just as well as any project can. The work is sized based on what you know at the outset. With Agile development (just like any other project), you will be presented with the evidence of velocity that indicates just how much can actually be accomplished as the work gets performed. This allows you to gauge a release date. This does mean that Agile projects need to invest some time in "looking ahead" and sizing User Stories; Agile development is not about diving into coding without planning or designing...
If you are expecting to deliver all of the expected features on time, on budget, with quality, you are setting yourself up for disappointment. For a variety of reasons, most software projects don't succeed in hitting all of these criterion, at least not with delighted customers. Change is typical, particularly as customers get their hands on the software and experience it first-hand. Delivering to spec might allow you to make your deadline, but you might be leaving customers wanting and more work queued up for the future. Agile development seeks to identify and perform this work earlier, so that the customer is delighted and you can move on to other projects.
As a management team, we manage risk by talking with Scrum Masters, Product Owners, and those we call Program Managers (those who coordinate work between our organization and customer-related projects). We do this by meeting formally once a week – talking, without written status reports – to help uncover any issues or concerns. And we make on the spot adjustments and/or take action steps to initiate corrective action if there are problems.
We also manage risk by staying informed on a daily basis. We leverage the "information radiators" of our Scrum teams and observing our teams in action. We attend stand-ups as chickens (not talking), review the burndown/burnup charts and listen to the team talk, seeking to understand what they are contending with.
We also respond immediately when the team has impediments, unblocking them so that they can continue to be productive. We’re acting in real time in concert with our Agiile/Scrum teams, supporting them and assessing how our teams and business are operating without adding overhead.
Our management team also meets routinely to review and discuss the product backlog/project priorities with each Product Owner. We collaboratively work with the Product Owners as stakeholders, keeping our organization’s priorities aligned and everyone on the same page. We assess risk, costs and anticipated benefit(s) along with determining if staffing changes are required as a result and taking action to make that happen.
We also sit in on sprint reviews, reviewing the progress of the team as well as participating on customer calls. I also make it a habit to walk and talk informally during the week, in addition to holding one-on-ones with my direct reports.
There is a tremendous upside to operating in real time. People are more engaged because management is paying attention, and you can catch issues and support teams through real-time knowledge acquisition and action. You can also recognize a job well-done at the moment, not on a performance review months later (if you happen to be made aware of it at all), providing another boost to those who report to you.
Where does project management fit in? We do have people who interface with our customers, so there is a role for project managers. In some cases, it might make sense to change the role and even expand it in some ways. Perhaps your organization has a lack of management capacity (or perceived lack) to operate in real time. If this is the case you could try allowing your project managers to operate more as actual managers with greater decision-making authority.
The end goal is achieving true business agility, which means that managers should strive to wring out as much latency and organizational inertia that impacts productivity as possible. Look for and eliminate the overhead and operate in real time. Participate in the moment (when you are truly needed) instead of judging after the fact (that's annoying and less then helpful). The reward will be greater engagement and productivity.
Much of what Agile development leaves out is all about running the business, and there is plenty of planning, risk management, budgeting/staffing, etc. that is occurring on a continual basis – if the management team is operating effectively.