Barry Boehm on the CRACK Customer
Dr. Barry Boehm, a noted software methodologist with a long and illustrative career at TRW, DARPA, and USC, and author of the COCOMO model and Sprial methodology, writes about the ideal customer for agile projects. They are:
-- Collaborative: they will engage with their customer peers and with the development team
-- Representative: they know the product or system requirements and can represent their constituents accurately
-- Authorized: they can make the decisions needed to keep velocity up, and their decisions stick!
-- Committed: they take their job seriously and make every effort to advance project success
-- Knowledgeable: they can understand what the developers are telling them in the context of the business or market situation.
Take a look at other Boehm'isms on agile in his book, with Richard Turner, "Balancing Agility and Discipline: a guide for the perplexed", published by Addison-Wesley in 2004
Are you networked on LinkedIn? If so, share this article with your network by clicking on the link.
Sunday, June 14, 2009
Monday, June 8, 2009
Quotations worth a moment
I enjoy a bit of wit and humor. Here are a few of my favorite quotes:
Instead of trying to make the trains run on time, it might be better to do away with the trains!Anonymous
There is no undo button for our oceans of time.
Tom Pike
Brooks Law Adding manpower to a late software project will make it later!
Fred P. Brooks
About sequencing:
Nine women can't have a baby in one month
Anonymous
Nine women can't have a baby in one month
Anonymous
Somebody's sitting in the shade today because someone planted a tree a long time ago
Warren Buffett
Lies, damn lies, and statistics!
Benjamin Disraeli
There are no facts about the future
David Hulett
Value increases when the satisfaction of the customer augments and the expenditure of resources diminshes
Robert Tassinari
We always overestimate the change that will occur in the next two years and underestimate the change that will occur in the next ten.
Bill Gates
If the customer is not satisfied, he may not want to pay for our efforts. If the customer is not successful, he may not be able to pay. If he is not more successful than he already was, why should he pay?
Niels Malotaux
It is very difficult to make a vigorous, plausible, job-risking defense of an estimate that is derived by no quantitative method, supported by little data, and certified chiefly by the hunches of the managers
Fred P. Brooks
A requirements paradox:
Requirements must be stable for predictable results
However, the requirements always changeNiels Malotaux
Requirements must be stable for predictable results
However, the requirements always changeNiels Malotaux
Saturday, June 6, 2009
Agile Virtual Teams
Somebody asked: can a virtual team do Agile? Of course, with some adjustments. Here are my thoughts on this.
The communications channel:
Virtual teams often begin by emulating the behavior and circumstances of real teams. The first thought is communications. Real teams can handle a much greater N2 communication intensity because much of person-to-person communication is non-verbal.
What is N2? It's really N-squared. It's the approximate number of ways objects can communicate. The real formula is N(N-1). There are 5*4 ways 5 people can talk among themselves.
Non-verbal is a very high bandwidth channel, capable of communicating a large information message instantly, although the messages are often highly encoded and subject to inaccurate decoding. It's much easier to sort out the cacophony of discussion if you can put face and voice and context together.
Consequently, when planning for virtual teams, bear in mind that virtual teams don't have the luxury of infinite bandwidth
Velocity impacts:
Some teams relish the hub-bub of real time communications, and others do not. Good practice is to benchmark the virutal velocity before beginning the first iteration.
Assigning team work:
Assigning work to virtual teams should follow this simple rule: partition work according to its natural boundaries that minimize and simplify interfaces. Albert Einstein has been quoted to the effect: "Make everything as simple as possible, but not too simple". But over simplification is hazardous also. The solution can lose cohesion and the bigger picture becomes so obscured that effective solutions are not possible to build from the too-small parts.
Iteration Planning and tracking:
The iteration planning meeting is the agile mechanism for assigning work. All the team's complement attends. The same applies to a virtual team.
Tracking progress and identifying problems:
Only the daily stand-up meeting is affected by the communications unique to virtual teams. The less efficient electronic channels may have to be compensated by extending the time-box of the daily stand-up.
The burn-down and trending data is part of the team scorecard posted electronically as opposed to marking a whiteboard in a team space.
Are you networked on LinkedIn? If so, share this article with your network by clicking on the link.
The communications channel:
Virtual teams often begin by emulating the behavior and circumstances of real teams. The first thought is communications. Real teams can handle a much greater N2 communication intensity because much of person-to-person communication is non-verbal.
What is N2? It's really N-squared. It's the approximate number of ways objects can communicate. The real formula is N(N-1). There are 5*4 ways 5 people can talk among themselves.
Non-verbal is a very high bandwidth channel, capable of communicating a large information message instantly, although the messages are often highly encoded and subject to inaccurate decoding. It's much easier to sort out the cacophony of discussion if you can put face and voice and context together.
Consequently, when planning for virtual teams, bear in mind that virtual teams don't have the luxury of infinite bandwidth
Velocity impacts:
Some teams relish the hub-bub of real time communications, and others do not. Good practice is to benchmark the virutal velocity before beginning the first iteration.
Assigning team work:
Assigning work to virtual teams should follow this simple rule: partition work according to its natural boundaries that minimize and simplify interfaces. Albert Einstein has been quoted to the effect: "Make everything as simple as possible, but not too simple". But over simplification is hazardous also. The solution can lose cohesion and the bigger picture becomes so obscured that effective solutions are not possible to build from the too-small parts.
Iteration Planning and tracking:
The iteration planning meeting is the agile mechanism for assigning work. All the team's complement attends. The same applies to a virtual team.
Tracking progress and identifying problems:
Only the daily stand-up meeting is affected by the communications unique to virtual teams. The less efficient electronic channels may have to be compensated by extending the time-box of the daily stand-up.
The burn-down and trending data is part of the team scorecard posted electronically as opposed to marking a whiteboard in a team space.
Are you networked on LinkedIn? If so, share this article with your network by clicking on the link.
Subscribe to:
Posts (Atom)