This paper is about TDD, how convenient it can be in development cycle, Here we can see how TDD is not a technology instead of that this is a culture and good practice (discipline) that must to be encouraged for the project sponsors and the management people. Other important thing is how testability can contort the code because the code must to be tested and could be worse if you work with high code coverage.
Attention point of development performance, Usually with TDD it could be less than usual.
Very good point of view by Pete Preston. You can read all this paper here.
Daily meetings is one of the common practices of scrum methodology in Agile initiatives. This practice consists in separating 15 minutes everyday to have a meeting with your team and the scrum master. You are going talk about what happened in the previous day, what you did, and if you had any problems what knowledge you learned to prevent new ones. This meeting happens in the beginning of the day, so you can talk about what you will do today and the issues that might be in your way for doing a good job.
In theory, this meeting should work like this, being good for both the team and the project itself. But in practice I see two basic problems, that happen most of the times because our focus is not on the daily meeting best practices, but on the issues on the table.
The first problem I see is that people in this meeting forget that it is supposed to be a quick meeting. We do not solve problems in this moment, we just communicate the team relevant and short information. If a discussion is required, feel free to schedule a time after the meeting. We must be efficient.
The second problem in my opinion is when a participant is not clear or honest. Sometimes participants are afraid because they spent to much time solving some simple issue or they had to learn a new technology or a new framework. If the participants are not clear and honest, the meeting doesn’t need to exist because people will work based on unreal information.