of granularity and frequency. It is important to communicate
within
the proper granularity. Don't waste bandwidth by getting too detailed
in front of the wrong audience.
If you find yourself explaining details at the
higher
level ask yourself why? If you feel the need to explain you may be
trying to justify your actions, so don't.
Honest
plans
accept honest mistakes, learn from the mistake, make a new plan, then
move on. Remove blame from your project so that everyone speaks freely
and openly. You don't need an excuse for making a mistake you just need
to
learn from it.
One
important communication channel omitted from the flow chart are the
walls that surround your project space. Post large charts that can be
read from a distance to encourage change without bullying. Post designs
as Agile
models on white
boards or Agile
documents. The walls of your projects space can communicate honestly
and neutrally if you use them well.
Count
how
many people are on the project, now communicate like a group
that size. Even a project in a huge company can communicate like a
small start up among themselves. Communication efficiency drops off
rapidly with increasing distance so get everyone together. Being able
to see meetings and gatherings occur and eavesdrop as needed boosts
communication. Hermits
don’t share, communities are based on sharing and being near each other.
There
is
more to owning software than just paying for it. Intellectual property
is only valuable if you understand it, can modify it, or reproduce it
as needed. People are not disposable, they are needed to continue
owning the intellectual property you are investing in. Allow everyone
to talk to everyone else to avoid loosing your competitive edge.
Keeping people isolated doesn't just slow down your development
process, it throws your intellectual property away.
"The
customer didn't know what he wanted" is a common excuse for
project failure and it is invalid. The customer knows exactly what he
wants; a solution to the problem at hand. If the project fails because
the wrong software was built it isn't the customers who are at fault it
is the developers. Developers are responsible for asking the right
questions until a clear picture of the problem and a good solution is
found