It depends a lot on the concrete situation. Let's assume the new property you added is mandatory, i.e. it has to be set always. Then you must search through the code yourself and update it everywhere a
companyObj is created, to ensure that it is constructed properly (including setting the new property). I assume PHP has constructors, in which case you only need to add a new constructor parameter and the compiler will automatically mark every constructor call without the extra parameter as a compilation error. This will also ensure that teammates learn about the new property as soon as they use a
If the new property is optional, however, things are less clear. You may or may not have a suitable default value for it. In the latter case, I would still suggest you update all instance creations to set the new property whenever appropriate. This is to ensure that the code is kept in a consistent state at all times.
Communicating the change to your teammates is another, distant step here. Agile teams prefer face to face communication, and, IMHO for a good reason. Relying on documents is a very slow and ineffective means of spreading information around a team. A Wiki is somewhat better, but still, documenting every single class attribute is IMHO overkill. It is only going to become a huge burden on the team, and is quickly bound to become unreliable and useless anyway, as we are humans so we are bound to forget the update sometimes, moreover I bet that not many team members are going to regularly check the documentation (be it in whatever form) to get informed of the latest code changes.
The latter is also true to automatically generated documentation via e.g. Javadoc or Doxygen. Although they can be configured into an automatic build to keep the generated documentation up to date at all times, I have never seen a development team with members regularly browsing through the documentation to get informed about the latest code changes. And if you are using any source control system, the first place to notice the changes is when you update your local copy of the code anyway - then you can check for changes in familiar classes and see precisely what and how has changed (along with a brief explanation and/or reference to a task ID, if your team is accustomed to add meaningful checkin comments - which is going to be missing from automatically generated docs).
Communication is one prime reason why Extreme Programing teams do pair programming. If you make the changes together with a teammate, there are two of you right away who know about each change, and next time each of you are going to pair up with someone else, so useful information spreads quite quickly. It is not always applicable though, for various reasons. Barring that, you may simply talk to your neighbours about the change in an appropriate moment (e.g. during lunch, if you happen to lunch together), or send a mail around if it is a bigger, more important or more complicated change.
In the latter case, there may be a good reason to document it properly. IMHO design documents are best when they offer a coarse grained, high level overview of the system, while the implementation details are in the code (adhering to the DRY principle).