Friday, June 23, 2006
Evolution
The usual first problem with change is the question of "what happens to the old one?" Whether it's a process, a technology, a solution, a religion, a name, a pet, or anything. Comfort and familiarity with an existing entitiy or concept is something that prevents a lot of people and companies from change. Another thing that really prohibits change or jumping into change is cost and risk.
Cost is the amount of resources and effort required to perform or obtain a task or resource. It is usually monetary, but most usually it is more time than anything else.
Risk the likelyhood of loss or failure in acquiring a resource, investing time/money, and even emotional capital.
How do you introduce change so that it's 1) not so costly 2) not too risky or 3) more appropriate for what you need?
You evolve. For the next few posts, I will propose some ways of evolving your current processes, practices, and approaches so that becoming Agile is not as costly nor Risky as it sounds.
The only constant in the world is change.
Cost is the amount of resources and effort required to perform or obtain a task or resource. It is usually monetary, but most usually it is more time than anything else.
Risk the likelyhood of loss or failure in acquiring a resource, investing time/money, and even emotional capital.
How do you introduce change so that it's 1) not so costly 2) not too risky or 3) more appropriate for what you need?
You evolve. For the next few posts, I will propose some ways of evolving your current processes, practices, and approaches so that becoming Agile is not as costly nor Risky as it sounds.
The only constant in the world is change.
Monday, June 05, 2006
Management
Do you notice that management gets in the way of actually being able to effectively deliver a product? In traditional business models, managers tends to "over-manage" the resources: Gantt Charts, Planning Sessions, Status Meetings, Team Building, Status Reports, and all the management initiated activities tend to get in the way of delivering. Of course, there has to be a point to management, otherwise what is the need for a manager?
Here's an idea: let management do the work that needs to be done. What do I mean by "work that needs to be done"? It's really simple: make sure that there is progress, and then get back to doing something actually contributory to the project.
When I write "something actually contributory to the project", then that means something *tangible* or something (an action, or set of actions) directly contributory to a project's value creation model. And in software development, that's only one of two things: code or documentation.
When managers need to write code, then that means there are not enough developers writing the code that needs to be written. When managers need to write documentation, then that means that the developers aren't writing the documentation that's necessary in the project. These are cues to the manager, that there has to be something done about it. And if a manager has to write code to deliver a product on time, that means the developers aren't capable, aren't working, or aren't worthy of the pay they're getting; or of course the manager himself over-estimated the capabilities of the team, or undercalculated the risks of a tight timeline.
If there are other things that need to be done by a manager, that's budgeting the time spent on a project, and the available resources at his disposal.
Did you ever notice that the successful software development firms have competent managers who can do what the subordinates do, as well as do very little management as much as possible? Here's a hint:
The role of a manager is to make sure that there's little work for him to do and enough time for him to spend on more imporatant things by doing the things that need to be done so that things get done on their own.
This means getting the right people, getting the right tools, setting the right timeline, and keeping the resources utilized effectively to provide a high level of productivity. Here's a simple goal for a manager: do everything that needs to be done so that you don't need to do it yourself. Seems like a paradox? The point is getting others to do the work that you don't have to do yourself, but need to do otherwise.
Sounds shrewd? Not really... It's really more an advantage to the project and the firm if the manager continues to do only the necessary actions that a manager needs to do: like tracking the progress of a project and keeping the resources busy. That way, a developer can concentrate on developing, a manager concentrates on keeping the developers developing, and the firm can concentrate on delivering its products.
The more you manage, the less things get done.
Here's an idea: let management do the work that needs to be done. What do I mean by "work that needs to be done"? It's really simple: make sure that there is progress, and then get back to doing something actually contributory to the project.
When I write "something actually contributory to the project", then that means something *tangible* or something (an action, or set of actions) directly contributory to a project's value creation model. And in software development, that's only one of two things: code or documentation.
When managers need to write code, then that means there are not enough developers writing the code that needs to be written. When managers need to write documentation, then that means that the developers aren't writing the documentation that's necessary in the project. These are cues to the manager, that there has to be something done about it. And if a manager has to write code to deliver a product on time, that means the developers aren't capable, aren't working, or aren't worthy of the pay they're getting; or of course the manager himself over-estimated the capabilities of the team, or undercalculated the risks of a tight timeline.
If there are other things that need to be done by a manager, that's budgeting the time spent on a project, and the available resources at his disposal.
Did you ever notice that the successful software development firms have competent managers who can do what the subordinates do, as well as do very little management as much as possible? Here's a hint:
The role of a manager is to make sure that there's little work for him to do and enough time for him to spend on more imporatant things by doing the things that need to be done so that things get done on their own.
This means getting the right people, getting the right tools, setting the right timeline, and keeping the resources utilized effectively to provide a high level of productivity. Here's a simple goal for a manager: do everything that needs to be done so that you don't need to do it yourself. Seems like a paradox? The point is getting others to do the work that you don't have to do yourself, but need to do otherwise.
Sounds shrewd? Not really... It's really more an advantage to the project and the firm if the manager continues to do only the necessary actions that a manager needs to do: like tracking the progress of a project and keeping the resources busy. That way, a developer can concentrate on developing, a manager concentrates on keeping the developers developing, and the firm can concentrate on delivering its products.
The more you manage, the less things get done.
