[mwilliamson]

I think the value I get out of Scrum, or XP, or any other methodology, is two-fold.

Firstly, it gives you a set of tools to use -- sprints, TDD, product owners, and so on -- that should work well together. To use them well, I think you both need an understanding of how each of those tools supports some idea or principle that the methodology promotes, and whether or not you think that principle is important for your team.

Secondly, a methodology gives you a starting point of how to run a development team. It's easier, although not necessarily better, to start from a pre-existing cohesive set of practices than to build a process from scratch. Especially if a team isn't experienced with many of the ideas, this is not an unreasonable place to start.

I think the key is:

1) knowing what principles your team thinks is important (low defect rate? frequency of releases? developer happiness? empowerment?). This is often hard to articulate. As time goes by, you might discover principles that were previously implicit, or you might find that the principles that are important to you change.

2) knowing how each part of your process maps back to one or more of those principles

3) having a mechanism that allows you to tweak your process over time (for instance, retrospectives), whether that's adding, changing or removing parts of your process

Scrum can be a sensible starting point so long as you're willing to introspect and consider which bits are and aren't working for you, and you're empowered to do something about it.

[knoq]

Not disagreeing (though not a fan of Scrum or Kanban), but can you elaborate why TDD is part of the "agile toolset"?

I've seen this claim multiple times and it's never made sense to me. I do TDD on side projects where there's not even a hint of "agile."

[mwilliamson]

Rapid feedback and short iteration cycles are often considered to be an important part of agile development. TDD suggests that you write a test first, and try to make that test the smallest increment that moves you forward. It feels to me that TDD is an application of the principles of rapid feedback and short iteration cycles on the level of code.

If you think using TDD improves the quality of your code, then it's also important for maintaining high code quality, since that enables some of the other agile practices, such as frequent releases.

I don't worry too much about whether a particular practice is agile or not. If you find TDD useful, then great! It's often included in conversations about agile development, but that doesn't mean you have to be doing agile development in order to use it.

[knoq]

Makes sense. I just see them grouped a lot as if they are a "required dependency" for lack of a better phrase. Thanks

[srtjstjsj]

Agile -> YAGNI -> TDD

Agile warns against building stuff you don't need. TDD means that test provide the justification for feature work. If your feature work isn't making a failing test past, you don't need that feature work. Obviously this assumes that your tests are justified (ideally there is a stack of tests leading all the way to the end user experiment), but that's much easier to get right than justifying untested feature work.