I'm a project manager in an extremely bureaucratic, waterfall-oriented organization, but have the opportunity to pilot an agile approach with a new project I'm spinning up.

I have experience with scrum and kanban, but intend to take a comprehensive look at the major agile methodologies and determine the best fit for the project and organization.

Is there a good model or tool to help determine the appropriate agile methodology for the situation?

In the absence of a good model, what do you believe are the key criteria for choosing a specific agile methodology? And if you want to really want to go overboard, what weight (as a percentage of total) would you apply to your criteria?

Robert Wysocki's book suggests some broad approaches based on whether or not the project goal is clear, requirements are complete, schedule is tight and whether scope changes are expected. But there may be other resources out there worth reviewing.

  • 1
    A good read to prepare yourself against those trying to warp and destroy agile to fit the "context" of the organisation.
    – Nathan
    Commented Aug 26, 2015 at 14:52
  • @NathanCooper Thanks. One of my favorite quotes for that blog post: "The only way to succeed – other perhaps than catching a really lucky break – is to build a team who work well together and who get things done. XP and Scrum are the best ways we know to work well together."
    – Alex Yost
    Commented Aug 26, 2015 at 20:12
  • I would highly recommend focusing more on the team's readiness/ability to embrace an agile mindset and goals vs. process. You should also involve them in evaluating process starting points. Will that slow down the kickoff? Most definitely. However, choosing a process for a team in isolation and then training them on it can hamstring many pilot projects; get "everyone in the boat" so to speak. Commented Sep 11, 2015 at 21:39
  • In retrospective: http://izlooite.blogspot.ae/2010/09/kanban-vs-scrum.html
    – KMån
    Commented Sep 25, 2015 at 15:20
  • The book link is expired you can find the archived version at web.archive.org/web/20091214011345/http://www.wysockiepm.com Commented Jun 3, 2020 at 6:33

5 Answers 5


I don't know much about how to select methodologies (I always used Scrum as a base, and tailored it to the specific needs of the project and organization), but please be aware that agile is more like a mindset than a project.

If you'd like to introduce agile methodology in a new organization, the key points are:

  • Team members must be empowered and held responsible for the output (there's no need to sign-off from higher authorities in most of the cases - for example, PO must be able to change scope without involving sponsor)
  • Dedication is required from the whole organization in order to enable even a single team to be agile (an example, we couldn't start our first sprint because security department didn't authorized team members to get keys for the dev room for 2 weeks)
  • It is not a marathon, it is a sprint - you'll need to continuously put energy in, there will be no slower periods (no time for your other responsibilities - if you're 100% on the project, no other work will fit into your schedule)
  • Embrace change - expect that agreements made yesterday will be revisited and possible undone tomorrow, make no fuss about it
  • Be flexible about the outcome - what you have in your mind is possibly not what you're going to get after a few changes
  • And, most important: trust the other team members - you should not play enterprise politics or power games, you're rowing in the same boat

If you're lucky enough to get those points accepted (and supported by your organization), concrete methodology is actually quite irrelevant.

  • 1
    I disagree on the sprint concept, the transition towards agility is more likely to be a marathon than a sprint. Having a sustainable pace is key, not doing things at fast pace 100% of the time... chances are that during the first attempts pace and productivity will actually slow down. Last but not least, having no other work fitting the schedule as a prerequisite can be a quite dangerous one.
    – mamoo
    Commented Aug 26, 2015 at 16:33
  • Agreed, I'd love to see a team get everything write during their first Scrum/Agile project. There's a reason why the Scrum guide advises to keep teams together; not only do they gain knowledge on one another's skill sets, but they also become more effective as a Scrum team.
    – tombraider
    Commented Aug 27, 2015 at 8:27
  • "it's not a sprint, it's a marathon, we should not try to win it in the first 100 meters" was an actual quote from our customer during an agile introduction project, which we had to respectfully decline (the context was that they'd prefer not to push it during the first sprint, since there will be lot of time for getting into momentum later). Commented Aug 27, 2015 at 9:03

If, as you say your organisation is extremely bureaucratic and waterfall-oriented, I'd not "waste" too much time thinking about what to do and instead start doing something:

  1. Find a problem to solve
  2. Figure out how to solve it
  3. Apply your solution
  4. Inspect and adapt

Or, as Dave Thomas suggests:

Here is how to do something in an agile fashion:

What to do:

Find out where you are

Take a small step towards your goal

Adjust your understanding based on what you learned


How to do it:

When faced with two or more alternatives that deliver roughly the same value, take the path that makes future change easier.

Do this together with your team, let the methodology grow hand in hand with people engagement, especially if you want results that last.

Oh, and good luck ;)


Not really an answer so to speak, but I'd suggest you watch this very interesting talk by Yuval Yeret : "Good and bad ways to kickstart agile the Kanban way". He presents how to drive Agile adoption using Kanban, considering every small change as options, and gives some good advise on change management, the Kanban way.

In addition you can also read an interview of Yuval Yeret by Ben Linders on the same topic.

(sources : infoq.com)


First - Agile Software Development is about changing your process to fit your needs. Scrum is not agile, Kanban (JIT) is not agile. It's your team changing processes or coming up with your own processes that suit your situation - that's what being agile means.

These days among the methodologies there's a clear understanding what's faster and resolves in better quality. It will depend on your qualification, team and organization what you can actually apply:

  1. Continuous Delivery is choice #1 today. You can release to PRD even if features are not ready (there're techniques that allow to hide those changes). But you'd need someone who's experienced in it to make it work. And it may result in poorer quality than the next choice if you have a weak dev team.
  2. Just-in-time, Theory of Constraints - with these you release every task (or group them in small batches). If you're not strong in CD - this is the best option to start with. It's a bit slower than CD and faster than Scrum, and it results in very good quality.
  3. Scrum - it's iteration based and has a lot of extra activities. So it results in lower quality and slower (a lot slower) development. But it's still much better than Waterfall.

These are not always mutually exclusive. Again - your situation will most likely need something modified. And processes don't have to be static - you may change them back-and-forth depending on current moods in the team.


I would suggest you keep it simple and follow these steps :)

  1. put together a team
  2. create a product backlog
  3. estimate your backlog
  4. kick of a sprint or iteration

then inspect, adapt and repeat!

Good luck :)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.