Thinking about Quality

In a traditional hierarchical organization, managers serve to implement the commands they receive from their superiors by issuing instructions to their own direct reports, monitoring the status of the resulting work, and then reporting on the results. In this world no one really does anything without getting orders from above. Railroads are the classical example of this kind of organization, developed in the 19th century, where everything works according to the rulebook, and all power flows strictly up and down.
Engineers like hierarchies so much that engineering organizations often seem to be work the same way. Watching in our own company as we've gone agile one can see an entirely different way of organizing work. If every engineer is caused to own their own tasks and be responsible for managing themselves, a manger's role is redefined to just a) hiring staff, b) making sure the staff is trained, c) resolving any problems that come up, and d) doing performance management. All of this is a lot less effort than micromanaging every direct report. It really suggests a much flatter organization with managers acting more as coaches than as supervisors. This means one can have more workers per manager, or more interestingly, less managers per worker. Since managers tend to have high salaries, this offers one way of driving cost out of the business, by simply having less managers.
If one then goes further and thinks about a distributed agile organization, with both on-shore and off-shore components, one gets a slightly more complex model. In this case there are some managers who preside over fairly large local teams. There are other managers who only act as liaisons for remote teams. Those remote teams of course obey the same principle of flatness. In any case the local managers either wind up with a lot of reports or practically none locally at all, depending on where their team is.

Do agile software development techniques at all go together with offshore development ? At first glance it seems a contradiction in terms. Offshore is about using low cost labor to decrease the cost of development, whereas agile is about doing the most important things first, thus saving money by not doing the inessential. The contradiction comes from the need for face to face time in agile; it doesn't seem so clear how you do agile if part of the team is far away.
The answer seems to be that offshore teams need to be self-contained, simple cognates to their local counterparts. If they are self-contained, agile processes can be applied to them just as to the local teams. In fact this has been studied at some length. Here are some good references:

• Internationally Agile
• Using an Agile Software Process with Offshore Development
• Agile Offshore

Every day we have a choice about what we do: We could stay in bed and do nothing, we could change the universe, or anything in between. It's really up to us and our choices. One thing we have no choice over is that at the end of the day, that day is gone and will never come back. It's one of the basic facts of our life: time is a precious resource that cannot be increased and that only decreases. Only in the realm of action do we have any control.
The same principle applies in business. For a business facing competition time is just as much an inexorable constraint. If you use a day without doing something, perhaps your competitors did that thing today. Every day gone by is one set of opportunities missed. Unless of course, you grasped for those opportunities.
While much of agile software development can have a slightly obvious appearance to it, the treatment of time is one of its great originalities and deepest strengths. The notion that all development occurs on a fixed schedule of iterations makes the development process acknowledge the tyranny of time. It makes us ask what do we do in this time ? It says you can't be late for an iteration, because if you didn't do something this month, doing it next month doesn't repair this month. Progress is made today, not tomorrow. Therefore we need to ask what is most important today. Acknowledging the preciousness of time forces us to prioritize and do what really counts. Thus iterative development aligns software project management with the philosophical reality that action is variable and controllable, but time is constant and beyond our reach.

It's always good to get meetings to finish on time. But when trying to make a decision, it is important to finish a conversation rather than to stop it. If a meeting is too rushed it is too easy to bounce off of the topics under discussion, and talk about them, rather than actually understanding the issues and resolving them. There is always a fine balance in running a meeting between keeping things rolling, and making sure that things get decided. This is especially true with consensus decision making, where it's really important to get everyone on the same page. This means having both a strong desire to really reach a good closure on each topic, balanced against an reasonable sense of urgency to want to close on each issue. Maintaining this balance also requires paying attention to time. Meetings that take too long can be a sign of a failure to push to close. Yet, if the clock is watched too much, one may simply turn out to be visiting the issues rather than closing them. If the issues are important enough it's vital to spend the time to finish the job, and take the items of the agenda, never to return.
As you can tell I've been in too many meetings where too many issues were bounced off of.