As long as we’re talking about Scrum it is good perspective. You don’t need to have huge experience with you to try Scrum. What you need is determination and enthusiasm in the team and both can be built to some point.

When I try to look at Kanban this way I see less chance to succeed exactly because arguments you give – without fine-tuning Kanban will suck almost for sure while Scrum can work pretty well.

On the other hand you often have to face some kind of top-down approach to organization, let it be team organization (vide cross-functional teams or lack of them) or project management methodology (waterfallish techniqes) or other formalized process (quality control, ISO-like certifications etc). Either way you have to follow them no matter what’s your approach on team-level.

You can of course build Scrum oasis and translate Scrum into the process of the rest of the company back and forth. But you may accept top-down process and just add some Kanban there. In this case you don’t need much knowledge how process should look like because it is already defined in a number of ways (it is arguable if these are the best ways, but that’s not the point). You can treat Kanban as an addition to whatever currently exists and chances are good it would work.

And I think that what Szymon is saying is in line with it as well.

By focusing on people, Szymon realized that in a particular team (most of them, according to him), people needed strong guidance, so he decided to use Scrum. If the team was different, you would have decided differently. He didn’t “pre-selected” a method and forced it the team, whoever is part of it. He (with the team) selected a method based on the members of the team.

The resulting method can be anything, and this is totally fine. But it will be what best suit you, your team, and your project.

This is agile.

My point was that if you take one of the more rigid ones you better have very good understanding of its inner workings if you want to tune it.

Your last sentence is very important. I agree with you that good leaders are critical to success of any organization. But, on the other hand, not every team leader in the world is a ‘good’ one. Some of them are and they would probably fine-tune their processes with a kind of kanban. The rest need a strong guidance, like the one that Scrum comes with.

You can do agile. Language changes. It is adjusted to the way people use it. Language development is an agile process after all – it embraces change.

I wouldn’t split different agile approaches as you do. I try to avoid looking at any method from the perspective of who they are targeted at. I look rather at what do they give to you.

Scrum organizes team work in the first place. Then it helps you a bit with engineering and a bit with project management (old-school understanding of project management).

Kanban basically organizes workflow and helps to spread information.

XP focuses on engineering techniques in the first place and don’t tell much, if anything, about project management side.

If you take our company you’ll see that what we really discuss talking about agile is team organization and software development. We don’t really touch project management since it is already somehow organized and it doesn’t really suck.

But yes, I agree with you that Kanban works in our case because of people, although other teams might have tried it too. I agree that implementing XP would be really hard and long process even if there was agreement we should do it (which won’t happen by the way).

I think we should focus on people not on methods. Once there are good leaders in place good methods will follow.

And there are really (I mean really) smart people out there who design these methodologies to be used by others who find them useful. And these methodologies very with respect to experience of people they are targeted to.

I understand agile this way: Scrum is good if you don’t want to experiment much. Just take it as is and try. There is a good chance it will work for you. But this has same downsides: if you remove some essential elements of scum, it won’t work at all.

Kanban/Lean is totally different. It encourages experienced and skillful people to mix-and-match practices to create their own agile methodology.

And last but not least, XP is for really really good engineers. For example, it prescribes practices that can be followed by less then 5 percent of engineers in my company, so switching to XP is not a choice to be made lightly.

For me, being agile (you can’t do agile, it is an adjective — Kevlin Henney) is about responding to changes rather then creating an artificial world where no changes happen. Anything beyond this definition is, at least for me, an irrelevant detail.

When you lose sight of your goal, whatever you are doing, you are getting lost.

The question is where is the value. For me it isn’t in being 100% agile or 100% Scrum or 100% Kanban. The value is in building set of principles and practices which resonate well with your team and allow you to build good software.

Personally I don’t feel the urge to follow agile even if I think Agile Manifesto in general is good. The same as I don’t treat Kanban as panacea just because it suits perfectly my current team.

If someone sets goals to become purely agile or follow Scrum by the book these goals are flawed. We don’t get paid for being agile but for delivering (hopefully) good software.

But I think that it is also important to use the correct terminology to describe what you want to describe. We must not forget that Scrum != agile, even if some people often use one term for the other. So, you can use only some of Scrum’s recommendation and be agile. You can even do nothing of Scrum and be agile. But, if you are not doing 100% Scrum, it is totally fair to say that you aren’t doing Scrum. You may still be agile, but it’s no longer Scrum. I don’t like the term ScrumBut, since its meaning isn’t clear. How much of Scrum can you discard and still call it ScrumBut? It reminds me of an old joke about somebody asking for a rum & coke, without coke…!

For me, as long as you value the 4 Agile Manifesto values, and you follow its 12 principles, you may claim that your are (100%) agile. If claiming such a thing is important to you…

I’m glad to see your comment about TDD. Along with Marek’s comment below one of previous posts it exactly presents the case I wanted to point.

While for Marek TDD is one of must-haves and crucial technique in his approach you call it completely irrelevant. And you both are right. Each of you has his own subset of practices which works in your environment. And I guess neither of you could be called fully agile by one of these agile orthodox, but that’s exactly how things look like in the real life. Real life isn’t about following the book, it’s about finding your own way of doing things.