Is there a good model for choosing an agile approach?

Question

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.

Answer 1

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.

Answer 2

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

Repeat

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 ;)

Answer 3

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)

Answer 4

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.

Answer 5

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 :)