(This is a snapshot of my old weblog. New posts and selected republished essays can be found at raganwald.com.)
Tuesday, August 24, 2004
Quiz Answers, plus "Instilling Responsibility"
In Surprise Quiz!, I asked:
In The Talent Myth, Malcolm Gladwell reported "how well people do on a test like this predicts how well they will do in the workplace: good managers pick (2) and (5); bad managers tend to pick (3)".
What I find interesting about this snippet is the relationship between the answers and Agile values: Frequent reporting and personal responsibility are key elements of Scrum, for example. I may be stretching here, but in my experience, one of the most valuable benefits of incremental delivery is the responsibility ethos it creates.
Yes, I know that I wrote an article where I described the benefit of incremental deliver in risk management terms. However, explaining things in dry terms "sells" better than explaining the effect on people, especially to management types. (Managers are often the least people-oriented people in the company.)
Back to incremental development. When a developer has a task, and you explain that they are on the critical path, and you show them a GANTT chart the size of the conference room wall, they're going to shrug their shoulders. Likewise, if you show them a huge baroque architecture and explain their component's place, they're again going to shrug their shoulders.
The twin problems facing us are that any task in a long, architecturally complex project suffers from a lack of urgency and a lack of importance, because over the remaining time in the project lots of things can change.
There's so much uncertainty in any project more than a month long that there's absolutely no way to instill a sense of urgency until about four weeks away from a milestone. And likewise there's absolutely no importance attached to any task until people can see that deliverable functions are going to break if the task isn't completed.
When you have milestones a month or so apart, there's a constant sense of urgency around the dates. Now what about responsibility? Well, if a developer's work is due by the milestone but it's hidden away in some dusty recess of the framework, there's urgency but no importance.
To instill responsibility, you need urgency AND importance. You add the importance by tying the work as closely as possible to functionality in the finished software. When a developer can see that her work must be done in the next four weeks otherwise some function that stakeholders/users/customers want will break, she's motivated. She can take responsibility.
Thus, incremental development. When you identify increments of the finished product to be delivered on a monthly basis, you are making urgency and importance plain and visible. And oh yeas, that buys you "frequent reporting."
Maybe Agile is, at the end of the day, just good management practice.
In Surprise Quiz!, I asked:
You have just been promoted to head of an important department in your organization. The previous head has been transferred to an equivalent position in a less important department. Your understanding of the reason for the move is that the performance of the department as a whole has been mediocre. There have not been any glaring deficiencies, just a perception of the department as so-so rather than very good. Your charge is to shape up the department. Results are expected quickly. Rate the quality of the following strategies for succeeding at your new position.
- Always delegate to the most junior person who can be trusted with the task.
- Give your superiors frequent progress reports.
- Announce a major reorganization of the department that includes getting rid of whomever you believe to be "dead wood."
- Concentrate more on your people than on the tasks to be done.
- Make people feel completely responsible for their work.
In The Talent Myth, Malcolm Gladwell reported "how well people do on a test like this predicts how well they will do in the workplace: good managers pick (2) and (5); bad managers tend to pick (3)".
What I find interesting about this snippet is the relationship between the answers and Agile values: Frequent reporting and personal responsibility are key elements of Scrum, for example. I may be stretching here, but in my experience, one of the most valuable benefits of incremental delivery is the responsibility ethos it creates.
Yes, I know that I wrote an article where I described the benefit of incremental deliver in risk management terms. However, explaining things in dry terms "sells" better than explaining the effect on people, especially to management types. (Managers are often the least people-oriented people in the company.)
Back to incremental development. When a developer has a task, and you explain that they are on the critical path, and you show them a GANTT chart the size of the conference room wall, they're going to shrug their shoulders. Likewise, if you show them a huge baroque architecture and explain their component's place, they're again going to shrug their shoulders.
The twin problems facing us are that any task in a long, architecturally complex project suffers from a lack of urgency and a lack of importance, because over the remaining time in the project lots of things can change.
There's so much uncertainty in any project more than a month long that there's absolutely no way to instill a sense of urgency until about four weeks away from a milestone. And likewise there's absolutely no importance attached to any task until people can see that deliverable functions are going to break if the task isn't completed.
When you have milestones a month or so apart, there's a constant sense of urgency around the dates. Now what about responsibility? Well, if a developer's work is due by the milestone but it's hidden away in some dusty recess of the framework, there's urgency but no importance.
To instill responsibility, you need urgency AND importance. You add the importance by tying the work as closely as possible to functionality in the finished software. When a developer can see that her work must be done in the next four weeks otherwise some function that stakeholders/users/customers want will break, she's motivated. She can take responsibility.
Thus, incremental development. When you identify increments of the finished product to be delivered on a monthly basis, you are making urgency and importance plain and visible. And oh yeas, that buys you "frequent reporting."
Maybe Agile is, at the end of the day, just good management practice.
Labels: agile
