One way to summarize my position on software architecture is that I see software architecture as organic. This position informs a host of management practices, including such things as spending time in each release caring for and feeding the architecture. What is your position on software architecture? How does this position affect your management practices?
Here is an exercise that I've found especially helpful when working with troubled development teams , because it helps me identify potential sources of confusion and/or conflict. Ask members of your team to take a plain sheet of paper and draw the architecture of the system. They have to draw it, meaning that they can't just fish out some diagram and print it. The drawing must be done individually, with no talking between team members. When finished, tape each of the drawings to a wall to create an "architecture gallery." What occurs to you, and each member of your team, as you review these diagrams? Do you find congruence ? If not, why not?
Do you have a visual representation of your architecture posted in an easily viewed space? If not, why not? If yes, when was the last time it was updated?
Can you enumerate the capabilities of your current architecture?
Check out the definitions of software architecture posted at http://www.sei.cmu.edu/. Which of the posted definitions work best for you? Why?
What are the specific artifacts, or views, that you have created to describe your architecture? Why have you created them?