Blog

Agile Project Approaches for Senior Managers: Common Misunderstandings and Key Benefits

ROI of Agile

Agile project approaches are en vogue these days. Hardly a day passes without a new article talking about the advantages of managing a project using an Agile approach like Scrum – so persuading senior decision makers to go “Agile” is not problem – or is it?

In many organizations, the reality is that using an Agile project approach is still greeted with skepticism by senior decision makers.  Project Managers or vendors trying to persuade decision makers to approve Agile need to understand the reasons for this resistance. Often it is simply based on misunderstandings about what “Agile” is and is not. Here are a few of key misperceptions and how you can best address them:

 

Misunderstandings

Misunderstanding 1: There is No Overall Project Plan

Since Agile/Scrum “project” team only works in 2-weeks-iterations there must not be an overall budget, timeline or project plan – “so how can I, as the project executive, determine budgets and resources or make predictions for other departments?”

The reality: Agile does not mean Chaos! Methods like Scrum are highly disciplined methods, where every iteration (or “Sprint”) is planned and strictly monitored on a daily level. In addition, most Agile projects will start with an initial iteration that we call Sprint 0, or even a classic high-level analysis phase to determine the overall scope and complexity, fill the initial product backlog, and provide overall estimation on cost and timing – ideally resulting in high-level architectural blueprints and a release (e.g., Minimum Releasable Feature -MRF) plan. The key benefit of applying an Agile approach is that the requirements are not fleshed out in minute detail, but are coarse-grained “requirement containers” that aid in planning. It is even possible to agree on fix-price contracts using Scrum!

Misunderstanding 2: All Team Members Must be Co-Located

“My teams are distributed across locations spread across the country and the globe …so how can Agile work properly?”

The reality: Colocation is the ideal situation for Agile (and really any project!) – but increasingly rare in today’s globalized business environment.  Personally, I have not had the luxury of co-located teams in any of the projects I have been involved in over seven years.  In fact, the last project we ran using Scrum had team members located in India, Sweden, Netherlands, Switzerland and the US.  There are great software-based tools that replace Pin-Boards; some as simple as Excel, SharePoint, and web-cams or sophisticated as Rally or Jira. Distributed Teams certainly take more effort and skilled leadership – but it is not a show-stopper.

Misunderstanding 3: All Team Members must be Full-Time Assigned to the Project

“My staff has multiple responsibilities and I cannot afford the luxury of assigning them to the Agile project full-time.”

The reality: Again, ideal situation but more often than not impossible. You can carefully manage with part-time team members – however, there is danger lurking here: Some of the key staff needs to have a significant availability. A Scrum master not able to participate in the daily meetings or key planning session, a product owner not available to respond to questions will put the project at a major risk. An a high fluctuation of team members will make it impossible to make future predictions using velocity.

Misunderstanding 4: “Scrum is Only for Software Development Projects”

“This project’s objective is to redesign our business processes to support the implementation of a new ERP and CRM package … we can’t use Agile for that.”

The reality: It is true that the Agile approaches like Scrum were developed by people in the software development world. But the principles of Agile, Scrum, other advanced “enabling” techniques like Lean and Kanban have long since transitioned over into the business world. SAP and Microsoft (and a host of others) have embedded Scrum elements into their respective ERP implementation methodologies (e.g., ASAP, SureStep) and I have seen Scrum used successfully on projects like Technology Roadmaps and CRM system implementations. It is not the domain of the project that is relevant, but rather factors like company culture, complexity, or regulations that determine how Agile you can be.

Beyond Misunderstandings: Benefits

Now that you have successfully addressed senior management concerns about Agile, it is time to focus on the benefits.  For senior managers, two of the biggest are ROI and RISK.

Agile Pushes Up ROI

Business Value Agile vs WaterfallScrum approaches say that the Product Owner and Agile Teams should focus on activities that deliver the highest-value business benefits.  Company money is spent on what really matters. If a budget has to be cut, a working product is always available and –following Pareto’s 80-0 rule – covers the business critical requirements. Product backlogs are sorted by business value or even by some notion of ROI. This approach also means that an organization is not spending money on activities like documenting features that will never see the light-of-day.

 

AGILE Reduces RISKAgile Risk Reduction

In any organization, business, operational, and competitive risks build up over time.  This is especially apparent in large, long-running projects or initiatives.  These are the type of environments where Agile approaches excel – with their built-in capability to reduce risk – the risk of a sunk investment.

Risk of Solutions Not Working: Short (generally 2 to 3 week) iterations deliver working products – so the customer or internal stakeholders quickly get tangible work products. Typically, users get their first working version of a new solution for testing and feedback in as little as 1 or 2 iterations versus what is often months on projects that follow a more sequential project approach.

Risk of User Rejection. In Agile, users are engaged from the beginning and throughout the project. User feedback on early versions of the solution directly influence the subsequent iterations. The likelihood that users will ultimately reject a system is therefore very low.  Compare this to users truly experiencing a new system six or twelve months after the start during a “User Acceptance Testing” phase.

Comments are closed.

About FitForProjects

Based in San Francisco, we specialize in dramatically improving organizational performance by utilizing pragmatic analytics and advanced project management techniques.

Contact Us

Need to contact Us? You can send an email to via LinkedIn or Facebook