People are not the only resources in your project!
There's a type of resource that is often neglected when we talk about agile, self-organizing teams, and getting things done.
I am referring to TOOLS.
We use tools to increase our productivity, quality, and efficiency. But for highly productive self-organizing teams, tools have to be more than that. The best tools are fellow team members,pointing out your errors, notifying you of potential problems, and coaching you into delivering work of higher quality. They differ from your human team mates only because they're not required to stand up during the 15-minute daily scrum.
Tools can play an important role in increasing discipline in an organization. Practitioners of lean software development talk about configuring tools in such a way that they make processes mistake-proof (also called "poka yoke"), meaning that they make it harder for people to deliver crappy products. Poka yoke can be seen as the technical variant of the human coach,who guides you in achieving higher levels of discipline.
Let me give you some examples of how the project tool in our own organization tries to assist people in our projects:
A) Quality assurance checks (through daily notifications) on all new project data; B) Automatic alerts on specific overrun levels; C) Acquire project ratings from team members after project deactivation; D) Have all time registration data verified by project manager through daily notifications.
Notify managers of a potential problem: employees that have left the organization but are still assigned to one or more active projects in the system.
Notify people of inconsistent data: hours in the time registration system that don't seem to add up correctly.
Proactively check with people: ask project managers via email if their list of active projects is still up-to-date.
People and processes are at the center of your business, and tools are no exception to that. This means that, just like people and processes, your tools must be carefully selected and adaptedto properly match your business. You should never change your business to match your tools.
"If it's a core business function — do it yourself, no matter what."
I would almost suggest that you extend this principle to your tools:
"If your tool is a core business function — make it yourself, no matter what."
Don't get me wrong. I would never suggest that everybody should build their own Visual Studio or Eclipse. But you should buy tools that have the same potential for adaptability as Visual Studio and Eclipse have. Don't select tools that are only customizable. Customizable means that you can change some standard list items, rearrange the menus, and select your favorite colors. But that is not what I mean with adaptable. Likewise, don't think that you're safe with tools that call themselves agile tools. The term "agile" reflects their marketing, not their architecture. I've seen "agile" tools that were less flexible than George W. Bush stuck in a glacier.
To make your tools work with you, and not against you, tools must be able to change with your business and your people. And to help you in making your processes mistake-proof, or poka yoke, they should check for inconsistencies, block incorrect data, send alerts, proactively verify crucial information, etc. If you're not making your tools yourself, then at least make sure that you can access your tool's database, its API, that it can be scripted, extended with plug-ins, and augmented with your own notifications and reports.
You want your tools not agile, not customizable, but adaptable.
Note: Please don't ask me for advice about which tools to buy. I cannot answer that question because I don't know your business. And besides, I tend to be too busy making a mess of our own tools.
And another note: I would advise not to use our tool, because I am the one who built most of it. This means it has a technical debt comparable to the debt that Bush left behind. But hey… it's adaptable!