One of the thoughts that I had today while talking to a coworker was "who needs process when communication works better." Of course no one wants to hear that. Especially those on the management side of the house.
I am reading about how to have difficult conversations and I ran into this nifty little quote about successful companies:
One study of five hundred stunningly productive organizations revealed that peak performance had absolultely nothing to do with forms, procedures and policies that drive performance management. In fact, half of the highflyers had almost NO formal performance management processes.
What's behind their success? GOOD COMMUNICATION.
They go on to talk about how the good companies hold everyone accountable for their actions, regardless of level or position. If there is a problem, coworkers step up and discuss what went wrong or what is going wrong.
I think my team is on the right track. We have to continue to communicate and be open and not let the documents get in the way (I am seriously afraid of that). All inter-team communication needs to move away from the email and towards the blog. We should turn notifications on for our blog and really start to use it to document what is going on and depend less on email. The agile process means (to me) that we act like we all live across the country from each other, which forces communication and documentation of the nature that adds value and makes sense.
It frustrates me that people say "we must have business analysts to write the documentation" when most successful projects and companies DON'T have people that are dedicated to writing docs. The smart developers are going to provide the documentation needed. Smart developers are going to provide working software instead of mounds of documentation. Smart developers are going to talk to each other instead of relying on tools. Smart developers will seek out their customers to ensure they are meeting their requirements. Smart developers are going to respond to issues instead of saying, "this wasn't planned."
*Note* Quote was summarized and slightly altered. It comes from Crucial Conversations, also I was inspired by the Agile Manifesto for the last paragraph.
Posted by carl at August 30, 2004 11:10 PM
I think the book to which Carl refers was more focused on business in general, rather than on software in particular. That is why there were more effective organizations out there.
We do have to deal with communication problems here. There is a pervasive attitude in our work environment where there is a dependence on poorly written documentation over what you know the customer has communicated to you. In addition, there is a tendency to privatize conversation as a power grabbing manuever, rather than to speak openly. In short, they prefer email or ephemeral instant messages over blogging and public communication. They prefer their poor documentation over what everyone knows to be true.
Demarco and Lister speak of the difficulty in being the first one in an organization to do risk management in a public sense. If you are the only one making your risks public, and giving an honest assessment of your status, you are providing ammunition for your critics and competitors. In this sort of organization, they suggest keeping your risks to yourself. I suggest changing the organization (so easy, hah). Agile communication is often represented by keeping the team in a room together. It's also about the developers speaking directly with the customers to avoid "translation" issues.
Making a change toward open, productive communication is one part of the change. The other part is reducing the documentation level to a maintainable state. Producing documentation in quantity such that you can't keep it up to date creates problems. Agile documentation is key to solving that problem by producing "requirements" documents that can be read by customers and developers and design documentations only where there is a need.
I disagree about the importance of process. I think process is extremely important. However, it is key that these processes be lean, agile processes. Processes that have been analyzed to remove constraints and bottlenecks, that produce the minimum that is needed, and that are tuned for success.
Posted by: mcknight at August 31, 2004 09:14 AM
Comments