There are people who will use "being agile" to justify software engineering practices that could be perceived as lazy or even bad. The specifications are going to change, they say, so it would be a waste to engineer more to begin with than the minimum viable product. What's expediency and what's just poor practice?

When you replace or significantly modify components of a larger system, too frequently we focus on whether the code we are building functions correctly. This is important, but it’s also short-sighted. It’s easy to introduce errors because we are changing interactions. Coding bugs are only one quality problem.

In traditional agile approaches, retrospectives are valuable to team improvement. However, when teams encounter organizational issues beyond their control, such as project structure, interorganizational communication, or resources, it's more difficult. Here's how to expand continuous improvement to the whole company.