Tomas, you asked a really good question that gets to the heart of what agile is all about. Actually, Mike Cohn does a fantastic job of summarizing it in the forward he wrote for us in
Learning Agile -- and I think it's very relevant to what you're asking about:
Early agilists agreed on a set of principles enshrined in the Agile Manifesto, and many practices were shared across multiple agile approaches. However, there was fierce debate about whether a team should start by understanding the principles of agile software development or whether they should begin by performing the practices even before developing a deep understanding of why.
Proponents of starting with practices took a wax-on/wax-off view of the world. If a team were to act agile, they would be agile. By going through the motions of being agile—pair programming, automating tests and builds, using iterations, working closely with a key stakeholder, and so on—a team would gradually develop an understanding of the principles of agile.
Proponents of starting with principles, on the other hand, contended that practices without principles were hollow. Going through the motions without understanding why did not lead to agility. Agility was (and still is) a focus on continuous improvement. The argument went that a team could not improve continuously if they didn’t understand why they were doing the things they were doing.
In Learning Agile, Andrew Stellman and Jennifer Greene do the best job I’ve encountered of stressing the principles of agile without de-emphasizing its practices. They point out that following practices without knowing why is likely to lead only to what they call a “better-than-not-doing-it” level of success. That is, implementing practices alone is helpful, but it falls far short of the true promise of what becoming agile can truly deliver.
I worry that you're falling into the trap of trying to adhere to the agile principles without really adopting the practices. And the problem is that the devil is in the details. It's easy to feel like you've valued working software over comprehensive documentation, or that you put customer collaboration over contract negotiation. But it's very difficult to gauge just how much those values are reflected in your work without the practices, because the practices are where you actually discover real-world clashes between the values and the work you have to do every day.
And the second question you asked can actually shed some light here:
The second question is, how to find the right extent of following agile principles? For example, it's surely true that working software has greater value than rigorous documentation, but I can't imagine omitting it at all (especially in enviroments similar to mine, where there is no substitution of developers).
The agile manifesto doesn't say that
you should omit rigorous documentation. It says that we value customer collaboration over contract negotiation. But it also says: "That is, while there is value in the items on the right, we value the items on the left more." There's value in documentation, even comprehensive documentation. I talked a bit in other posts about where you might want comprehensive documentation -- like in a company where publicly making a mistake can end your career.
So how do you know whether you're working at a company or on a team where you may actually need to place a little extra value on documentation? Trying to adopt agile practices -- and especially a complete agile methodology like Scrum -- is a very effective way to do so. If you try to establish a Scrum backlog and do sprint planning, you may very quickly discover that your company has a contract negotiation attitude: if they don't trust you to deliver value even if the specific features are not decided until sprint planning, they'll demand detailed long-term plans up front. This is the sort of value clash that you will have a hard time discovering without the practices.
That's why we teach the practices in Learning Agile, but also give many real-world examples of how those practices only get better-than-not-doing-it results when the team and company culture don't match the principles. But we still spend a lot of time actually teaching how to use those practices on a real team in the real world, because that's how to make positive change.
