How Agile Development Can Affect Software Development Best Practices?

We all know great characteristics of the object oriented programming such as encapsulation, polymorphism, and etc. Also there are "best practices and guidelines" for software development. I believe these are really awesome features that we can benefit from in many aspects, especially making the design more simple, understandable, and easier to maintain. However, many factors can affect how we use these models and practices. One that I came across a lot within past year is the software development processes, especially Agile Development.

Let me give you an example: when practicing agility, one concept that you may use often is to have different phases of developing a class overlaped with those of other classes. For instance, Bob is designing a customer class while the order class is binged implemented and product class is binged tested. This is because at each sprint, a set of work items binged worked on to deliver a feature to the customer. This is really great and I am totally in favor of what this practice accomplishes. However, this could affect how we use object oriented concepts. I can imagine that when Bob is designing the customer class, he looks back to the product implementation and makes some assumptions. This possibly makes his customer design easier because he knows what exactly is going on within products. Also the detail implementation of the order could be a bit different because of that knowledge. This leads to a design and implementation based on assumptions over other objects internal behavior which violates the best practice that changing internal implementation of an object should not affect the operation of other objects. This is especially dangerous in agile development since everything is easily subject to change and dependencies should be reduced as much as possible. Obviously, we cannot hide the internal behavior of the product from Bob, but he should know that his practice will cause bugs and more maintenance down the road. I strongly recommend that Bob does not design customer if he has implemented product because he may use those information to make his life simpler now and put the product at risk.

Some may argue that this problem also exists with traditional software development such as waterfall. That is true, if some implementation details tempting people to change designs and implementations, they can go and change it but it normally is costly and most project managers do not agree with it in later phases.

This was just one example of an specific software development process on the development quality. We should always be thinking "How I improve the quality" no matter what process/practices we use.