| I've never been a Project Manager before
|
|
25 Sep 04 |
|
[print
link
all
] |
|
Check out the excellent Dilbert
|
| Introducing agile methods if the customer is obsessed by dead trees
|
|
25 Sep 04 |
|
[print
link
all
] |
|
(Source: posting to agile-testing@yahoogroups.com by John Goodsen) I think
a big mistake many of us make trying to introduce Agile development
practices, is we fall into the trap of agreeing that we are not providing
documentation. If your organization wants to see documents along the way,
don’t tell them they can’t have it! Tell them they will have
the most up to date documentation that they have ever seen, because you are
going to generate it directly from the code. Our teams use an XP process.
It doesn’t take much to tie in a tool to auto-gen design specs from
the code and if you are automating customer tests, you can put description
in the headers of tests methods and use a javadoc based generation of a
"requirements specification"… so rather than view your
organization as an enemy that requires an "undergound attack",
listen very carefully to what people are asking for and figure out how
Agile approaches can deliver it. We are not the enemy. We are the
liberator. We have exactly what they want, but we often fail to match up
our Agile solution with what the stakeholder is asking for.
When an organization wants more than the Agile process requires, it is easy
to show the additional cost each iteration, and as the team builds
credibility the customer/stakeholder(s) might be less inclined to want to
spend money each iteration producing documentation.
So have some courage, tell your stakeholders that they can have it
(whatever "it" is) if they want it and then make sure you follow
up with giving them a good picture of the cost and value they get from
"it". It’s their money - let them blow it if they want to.
Let them slow the velocity by asking for non-code related items. All you
can do is make it visible and help them down the path of figuring it out.
The sooner you start delivering some working code, the sooner you’ll
have the credibility to address their real process issues. "It"
will become less important the more iterations you deliver working tested
code.
The hard part is getting code started, right? Maybe you can disguise the
first few iterations as "prototyping" and use TDD as the process
for your prototyping? :-)
|
| Simple things ..
|
|
25 Sep 04 |
|
[print
link
all
] |
I was just now doing some research on bus ticket clearing houses and I came
across his post in rec.travel.europe from 2001 by Michael Forrest.
>Reciprocity is not guaranteed on airlines (or toll bridges - it
>has always amused me that the toll on the Severn Bridge between
>England and Wales is GBP 4.20 for a car to enter Wales but there
>is no toll the other way, ie entering England). (Maybe it shows
>how the two countries value themselves?)
All of the bridges in the San Francisco Bay area only charge toll in one
direction. Some genius realized that, on the average, just about as many
cars went each way for the obvious reason that most trips across the
bridges are round trips. So they doubled the toll and took down the toll
booths going one way (except for the Golden Gate Bridge where the toll
booths remain, unattended). There has been considerable saving in toll
collection costs and the toll booth traffic jams in one direction are gone.
Is it possible the Severn Bridge does similarly?
|
| XP style process and battle-fields
|
|
25 Sep 04 |
|
[print
link
all
] |
|
Not that I want to promote war in any way, but these posts in the
extremeprogramming-ML made me smile:
Phlip:
During the planning game, you review last week's
finished stories, and they inspire you to write some
new cards, to edit some cards, and to toss some cards.
Then you (the Onsite Customer) re-sort all the cards,
and draw off the top batch for the next week.
But another input into this system that affects the
planning game - the competition.
The USA occupied Iraq using an effective new battle
technique. In traditional advances, you send a
diversionary force against one of your enemies flanks,
draw them that way, then send your main force against
their other flank.
Modern soldiers, with cell-phones and such, follow a
more agile approach. You simply send two forks of your
forces, probing towards both flanks. You use sensitive
algorithms to detect the defending commander's
decision which flank to defend. If you can rapidly
turn one advance into the diversion, and the other
into the main attack, you will soon collapse the
opposition's ability to effectively make decisions.
Agile onsite customers can play this card too. If you
detect your competition's marching orders, in
real-time (using either sensitive algorithms,
good-old-fashioned industrial espionage, or just
reading their self-congratulatory Web site), you can
then request iteration features which provide the
minimum amount of code needed to start your project
towards blocking the competition's advance. This
technique will, again, collapse the competition's
ability to make decisions.
Or convince them to hire an XP coach or three. So
either way it's a win-win-win for us! ;-)
Steven’s reply: :-)
Or you could follow the agile strategy that Microsoft
pioneered - announcing products with your competitions'
features before you even start implementing them.
|
| Case stories
|
|
25 Sep 04 |
|
[print
link
all
] |
|
Been skimming the XP-ML this morning.
About the $200M Oracle-Ford Desaster: the management did not give them
enough power to go fully agile
Chet Hendrickson:
It was a very frustrating situation. The team asked Don and me
to help with preventing the Oracle consutants from making changes
directly to the production system. This was about $150 million into the project.
We tried to sell them on a more agile approach (as you might imagine), but by
this time they were pretty far gone.
It was unfortunante that we were not operating at a level in the organization
that would have allowed us to get the plug pulled sooner.
chet
Georg Tuparev has a nice case story, too: speak out if you are put on a
death march.
Few years ago I was called to lead a huge team stuck in one and half
year design phase. The team was supposed to build a control software
for a network of telecom satellites. Cannot disclosed names and
resources, but one could imagine ...
Three days in the project I had a phone conference with the CxO's of
both companies involved. Told them that the way it is going no
satellite will ever fly and that I know a better way. After getting
green line, the design document was burned with a small celebration at
a BBQ, and 85% of the initial team members were sent to an indefinitely
long vacation. With the rest (15%) of the team we had the first
functioning version 2 months ahead of the schedule and 50% lower then
expected expenses.
So the lessons:
- it is never late to change direction of a project in order to save it.
- I do not agree with Kent that this is a sad story. If you are a good
programmer put on a death march project you should speak out! If no one
listens - walk away. There is just one very precious life in front of
us - do not waste it! And if these folks wasted 2 years of their lives,
well, it is their business ... but they should not expect my
sympathies.
BTW, Philip is right - the project I was telling about had a 9 months x
40 people "Big Requirements Up Front"!!! Then the design started...
Just my 0.02
Georg Tuparev
|
| CIO magazine current issue all about agile... (IT oriented, but)
|
|
25 Sep 04 |
|
[print
link
all
] |
Denis Haskin posted this to the XP-ML. lnik
I assume this popped up on everyone else's RSS aggregator as well, but...
From Darrell Norton's blog [1] and Artima developer forum [2]: the
current issue of CIO magazine is all about agility:
http://www.cio.com/archive/081504/index.html
|
| What's the Second Directive?
|
|
25 Sep 04 |
|
[print
link
all
] |
|
(Source: Ron Jeffries, aka Mr. XP) I’m been struggling for years with
notions like having empathy with our mistakes, Kerth’s Prime
Directive, and the like. Springing from a couple of notes on the
extremeprogramming group, and a blog entry from Dale Emery, here’s my
latest rant. xprogramming.com/xpmag/jatPrimeThis.htm
|
| Increasing Software Development Productivity
|
|
25 Sep 04 |
|
[print
link
all
] |
|
(Source: Mary Poppendieck) Income growth of workers in any economic sector
is directly related to productivity growth. In the past, the productivity
of the technology sector grew not because technical workers were becoming
more productive, but because technical capability was growing so fast.
Unfortunately for the incomes of software development professionals, this
is no longer the case. Future income growth will be related to our ability
to increase software development productivity.
How can software development productivity be increased? Through the same
approaches used in operations: a focus on customer value, a short,
effective supply chain, healthy discipline, and innovation. Mary will
discuss techniques that businesses have used for decades to jump-start an
increase productivity, and show how they can be used to increase software
development productivity. pdf
|
| Is Tableau the Next Google?
|
|
25 Sep 04 |
|
[print
link
all
] |
|
link
example graphs
Will this company be successful and become another Google?
First, graphical data mining has never been a big hit. And second,
there are lots of competitors in the business intelligence sector,
including at least Business Objects, Cognos, Hyperion and MicroStrategy.
So make your bets and wait for the next multibillion-dollar IPO.
|
| Skolelinux: V1.0 with codename Venus is out! |
|
25 Sep 04 |
|
[print
link
all
] |
Skolelinux is made as free (as in speech) software, and is an overall computer solution based on school's resources and needs. It is based on Debian and runs very well on older hardware, too.
- Skolelinux is a network architecture tailored for use in schools.
- Skolelinux is designed to be easy and cheap to maintain.
- Skolelinux gives the students their own usernames, home directories and services.
- Skolelinux includes OpenOffice.org
link
|
|
|