I had both sides of the story in my carreer, and personally found the landscape thing literally hell. Even the constant movement of other people distracts me, let alone the humming noise of talking, phones that go off, meetings right next to your desk, and the fact that you lack enough daylight and fresh air when sitting in the middle. I like a rather fresh temperature, makes me think better. Not everybody agrees though.
Currently we're three in one office. It's still not perfect, but it does help that my colleague and I can discuss server-related issues while we're working on it. And it saves office space. But honestly, more than three I hope I never have to experience again.
So in summary, I think it's important to look at :
- modest interruption
- enough light and air
- putting closely collaborating people together, but not more than that
YMMV.
You're making a number of mistakes here.
The first one is assuming that a Scrum Master is a manager. They're not. They're basically an administrator-cum-facilitator. They make sure things happen on the Scrum schedule, but they don't have to tell you how to, if you're a fully-mature Agile team. It mostly just happens.
But they don't monitor the quality of your work or sign your holidays off or anything like that. Nor do they manage the product or project; that's done by other people.
The bigger mistake you're making is assuming that you can go from the situation you've described in other questions ("Developers are far from capable of doing agile programming practices at the moment. No unit tests, no pair programmings, no CI (huh? what is it?) ... you get the idea.") to "fully-mature Agile team" overnight. That's simply not possible. Forget it. Don't even try.
If overnight results is what you want, look to more structured project-management approaches. And hire some managers.
If the business wants you to be Agile, it takes time, it takes culture change. And yes, at first, when you're in the Chaotic Stage of improvement, it's going to require management. Whether that be an individual or a group, someone's going to have to make some decisions.
You need a person or group to be responsible for taking a look at the bigger picture, explaining the current situation to both the developers and the business, and explaining the options you have for improvement, figuring out what the business needs and then guiding people through it.
It's going to be a long time before you can call yourselves a fully-mature Agile team and self-manage. Most teams never get there.
Best Answer
This shouldn't be your problem.
Capitalisation of costs is your company CFO and/or accountant's problem. The rules vary in different jurisdictions. The accounting guys are the experts and should be capitalising costs according to the relevant accounting rules.
At most, they may need to ask you for some supporting information (e.g. of the 5,000 developer hours worked this quarter, can you estimate what % was on new software development or enhancement of existing software assets?). But it's up to them to ask you the right question.
If you are doing mostly new software development in a product that your company sells or intends to sell (i.e. the product counts as an intangible asset which returns future economic benefits) then it's perfectly possible to capitalise 100% of development costs. Also some countries have special incentives for R&D investment which is possible your software development work may qualify for.
The software development methodology you use is irrelevant, the only thing that is likely to matter is having some way of categorising which costs were spent on capitalizable projects or assets. But the same problem applies to waterfall development!
But for goodness sake, let the accountants sort this all out. You don't expect the CFO to write code, do you?