Get certified - Transform your world of work today


An Introduction to Agile Project Intake, Part 2

Challenges, learnings, and best practices

2 March 2016

Gaurav Mehra

Eric Aker

This article series is the outcome of our experience and challenges in software development, though most of the concepts presented throughout can be applied to any industry that practices Agile methods.

If you are reading this article, chances are you spend part of your day in an environment that is in some state of agility. If this is true, there's a high probability that there are challenges and room for improvement! We bring you good news: We are here to help with one of the most fundamental issues that plagues Agile transformations. So read on!

For any of you who haven't read the first article of this series, in Introduction to Agile Project Intake, Part 1, we touched on why we need a different approach for project intake analysis when Agile is not the only software development method available to choose from. By the end of this series, our hope is to give you a simple framework that will guide you through the project intake assessment in a mixed-portfolio model.

Before we jump right into the framework, we would like to provide you with some additional context around the challenges of project intake models. The feedback we received from the first article was immensely insightful into how we decided to convey our complete message. It is important to share what we think are situations in which organizations find themselves when deciding to adopt Agile methods. Though our experiences will not cover every scenario, or every industry, we feel these examples had the most impact to those around us while coaching and researching with Scrum teams.

In this second article, we will discuss issues and challenges found in several organizational contexts and then present a "lightweight" intake assessment that you can introduce in your organization right away. Remember, an Agile framework is not meant to be "easy," but when done with care and insight, it can be a great way to synchronize your organization toward a shared vision.

Agile adaptation stages: Where do we stand?

First, we have witnessed that Agile transformations that are in one the following three states can exhibit unhealthy behavior for a project intake model. Consider the following three interim organizational states:


A quick look at the above three states tells us that the first one appears to be the most clear but can eventually lead toward states two or three. State two is probably the most interesting and complex organizational state due to the misalignment of what individuals both expect and experience. It often ends with a disconnect between the top-down and bottom-up movements or even within the same horizontal slice of a company, leading to a contentious culture. We advise that state two go see an organizational therapist immediately!

Wrong reasons for Agile adaptation: Why are we here?

In the above three states, organizations in transition to Agile oftentimes decide to execute projects in Agile for the wrong reasons, some of which include:

The icons included in this image were used under the Creative Commons License

Phew! That was a mouthful. But there are many reasons behind mixed-portfolio programs that choose their delivery method as Agile at the decision gate. Some of these may not be easy to assess this far upstream, but if there's a way for you to keep these warnings near and dear to your heart while the project moves down the funnel, then there's always a chance to make assessments and to mitigate risk later on.

Consequences: What more can go wrong?

Next you may wonder, what happens if an organization decides to force a project to be delivered in an Agile fashion despite all of these warnings? Well, here are some risks and their manifestations into issues that we have observed when Agile adoption is forced.

If the organization recognizes and accepts that it is in a transitionary state because multi-application project schedules are out of sync, it may decide to hedge its risks by deploying code to production in an "off-mode." This decision is best made prior to solution design, as it typically increases design, development, and test costs as well as the overall duration. That said, implementing feature toggles in production is inherently risky for many reasons:

The icons included in this image were used under the Creative Commons License

On the other hand, if the organization is unable to proactively identify these warnings and mitigate risk by using these techniques, such as "on-/ off-modes" for code in production, then the above risks can manifest into the following issues:

The icons included in this image were used under the Creative Commons License

What can I do? Review the intake checklist

If you accept that these behaviors are undesirable for an organization and that each project should be consciously assessed during the intake process for fitness to the software development method, then as a preview to the framework in the upcoming articles, here is a short list of questions to consider for your next project intake:

The icons included in this image were used under the Creative Commons License

Now that we have introduced you to the warning signs and issues faced by organizations who do not heed those warnings, we hope that we have empowered you to perform a preliminary assessment of your projects to the adequate software development method.

In our next article, we will develop on this fitness assessment and introduce a framework for effective intake of Agile projects.

Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.

Article Rating

Current rating: 5 (28 ratings)


Terri Vail, CSM, 3/3/2017 11:51:43 AM
Have you published the next article? I am not seeing it when I do a query.
Shawn Cline, CSM, 9/25/2017 1:24:27 PM
I am unable to locate your next article. Has it been published? I could really use it about now:)

You must Login or Signup to comment.

The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.


Newsletter Sign-Up