How to Manage an Agile Project

You want to create the most valuable software possible — as determined by your stakeholders — in the least amount of time and for the lowest cost. There are many different methodologies you can choose from to deliver your project, from Agile project management methods to Waterfall or a hybrid of the two.

So, what do you do?

Agile versus Waterfall for Projects

The “Tension” on Agile Projects

You need a solid plan and a clear picture of what your project will deliver — and a way to control and monitor progress — while at the same time being able to release the most creative and productive energy of your project team.

But is it possible to think everything through in advance, or is it better to think things through as you go, and still end up with the results your stakeholders want?

There’s an inherent tension here, be it a push and shove or a top-down versus bottom-up. It’s like the yin and yang of project management. The answer, like Buddhism, is in taking the middle path or approaching things from somewhere in between.

That doesn’t mean being a project manager on a large Agile project isn’t tense. With rapid deployment, you can feel that tension and you need to resolve it…

How to Resolve the Tension on Agile Projects

Start by answering one of the biggest questions on your project, “What is value?” Defining value will take a lot of collaborative effort among team members and stakeholders. Together you will determine what you actually want to see in the end, based upon value.

Here are some guidelines for determining value:

  1. You need something of value that connects what the developers are doing to what the stakeholders want, and a process to negotiate that throughout the development project.
  2. You want requirements that are at a high enough level to stay out of the developers’ way, yet provide value by giving sufficient detail to guide and empower the Scrum teams.
  3. Top-level requirements must be understandable to allow for clear integrated testing to show if Agile-developed features satisfy those requirements and provide the value desired.
  4. You need a well-defined end state so that everyone knows where you’re going and what value is being created.
  5. You need a well-defined yet flexible timeline to get where you’re going to realize the value.
  6. You need milestones to do value assessments to determine where you are in the project and if course corrections are needed.

Agile Case Study

Let’s say you are on a large and complex software development project with a minimal viable product. There are numerous Scrum teams, in multiple locations and under different organizations, but all on the same project. The tempo is fast, with new sprints every two weeks. There is a constant stream of meetings — sprint planning, design reviews, requirements meetings, integrated test planning, Scrum of Scrums and more!

The wheels are turning, there’s lots of iteration, but where is it all going? How do you sort through all of the activity and ask the right questions? How do you determine what’s going right, what’s going wrong and what is needed?

Ask these three basic questions:

  1. What are we building? What is clear and what not? How will we know when we are done? Is there user acceptance? 
  2. By when? And how can we monitor our progress — toward getting done what we know and prioritize, and clarifying what we don’t yet know — and make course corrections along the way?
  3. How can we do it at the needed quality level, for the least cost, and with the most efficiency?

It seems, based on these questions, that it’s all about controlling what we can in the short to medium term and then figuring out the rest along the way. You want to empower people to contribute along the journey, assuring stakeholder concurrence and moving toward an increasingly clear picture of an end state of value.

This last point — moving toward a clear picture of the end state — is where a lot of Agile projects can come up short, simply because they are too short-term, incrementally focused and lack an eventual longer-term goal.

The Value of the Agile Approach

The reason for Agile in the first place is that in software development, because of changes in technology, technical complexity and rapidly changing needs, it is hard — often impossible — to know exactly what you will need at some point down the road. As a result, a healthy acceptance of the fact that you cannot know it all up front can help you to adopt to a more Agile mindset. A drive for clarity on the end state can help you to properly guide Agile teams to a yet unknown place where stakeholders will be satisfied.

Back to the case study on this complex and challenging agile project: How do you know when you are “getting there”? Can you just be satisfied to say that “we are making progress”?

My answer is a bit trite: You cannot be satisfied that you are making progress until you are satisfied.

Going a little deeper, you know that you, your team and your stakeholders are on a learning curve. At the same time you need to make progress. In large part, it’s all about tempo. It’s about setting up a system to ensure that all these things are happening.

Agile accommodates this challenge beautifully. It enables you to be managing a relatively short duration project — let’s say six weeks plus or minus — while at the same time chasing after that vision for the ultimate end state. Using a rolling wave, you are constantly managing this short term project that has 95% clarity, and closing out bits and pieces while you push on to the next set of bits and pieces that come into clear view.

Clarity on the final end state might be 50% at best. It’s initially a bit like hitting a golf ball toward the flag. At first, you know that you can hit in the general direction of the flag — although often you cannot even see the flag, but just know it’s out there.

So you start out with a strategy about how to get down the fairway — considering wind, slopes, hazards and your own knowledge and capabilities — and into a position where, as each shot is taken, you are closer to the green, where you can finally focus on getting the ball into the hole. It’s the ultimate balance of short-term and long-term.

Strike a Balance on Agile Projects

In the final analysis, managing an Agile project is a process. You need to come to grips with what you do and don’t know, and create a system for filling in the blanks as the project unfolds. You assemble the team, develop an ecosystem and manage in chunks of short duration while you figure out the rest.

In the process, you deliver early and often.

The one constant across all methodologies is the use of good tools designed to get the job you’re working on done right. is a collaborative online suite of software solutions made with the project leader in mind. To see how it can help you plan, monitor and report in real time, check out this free 30-day trial.

Related Posts

Deliver Your Projects
On Time and Under Budget

Start planning your projects.

Start 30-Day Free Trial