> Agile teams find their ways within clear, yet very general rules. And reiterate on those rules. We implemented Scrum at the company I work for. It could ha

> Agile teams find their ways within clear, yet very general rules. And reiterate on those rules. We implemented Scrum at the company I work for. It could have just as easily been any other sort of development methodology---Kanban was under consideration for less structure, for example. What we were looking for was something that works for us, and that would get us out of the huge mess that we were in. Scrum addressed many of the issues (especially management) we were having, so we figured we'll give it a shot and slowly start implementing it. We don't stick to the books. The core concepts of Scrum are implemented, but are guiding. We constantly iterate on the process itself---every sprint we review how we did, identify problems, and put something in each sprint to improve upon them. We introduce concepts gently. If we find that something doesn't work, it gets adjusted or replaced. If it works, we apply it even more stringently. If making it more stringent introduces problems, relax it. We do nothing because we "have" to under Scrum. Everything we do is analyzed, rationalized, and adjusted. And it has been wonderful---it saved a department that was falling apart. Are there problems? Sure. But we've identified them, and they're being addressed. Concepts like TDD and pair programming---those aren't things that can be forced. The team needs to be on board, and if it's not working, then changes need to be made to hear and address their concerns, or get them to understand why we do things the way that we do. At a higher management level, how projects were managed couldn't be forced. It was a gradual change, and it took a couple years to completely change how the entire company approached projects.