The Latest

Agile Coaches have a big job.

"Support the team but not too much and not too little."

"Be available but don't be overbearing."

"Offer ideas but don't get too involved."

"Coach, don't manage."

All this advice can be confusing, even contradictory. No wonder Agile Coaches fall into less-than-desirable behaviors as they try out new things to help teams. The problem is that these behaviors can subtly undermine a team's ability to organize, improve and, eventually, reach high-performance. That's why they are called failure modes.

Following an "I-click-therefore-I-Program" methodology does not lead to quality software. Good code can and should evolve from clear, up-front descriptions of the solution to the problem at hand.

If a customer asked you to demonstrate to him, within an hour, that your newest software is ready for use, what tests would you run? Are these the same tests that you are now performing in your first hour of regression testing? They should be.

Excellent testing starts by questioning the mission. So, the first step when we are seeking to evaluate or enhance the quality of our test coverage is to determine for whom or what we're determining coverage.

Quality attributes--performance, scalability, availability, maintainability, etc.-are often referred to as the non-functional requirements.

Service Oriented Architecture (SOA) has many security challenges. To address these challenges, it is not enough to set up a secure operational infrastructure.

Test-driven analysis (TDA) focuses on the system at the user interface level.