S
Scott Ellsworth
[...]
I have joined very few software teams whose programmers had a good grasp
of time, or progress towards the goal.
After one dreadful experience, I started to make 'what is the goal, and
how are we doing on getting there' a part of my toolkit. Not because I
love project management or project planning - I prefer writing code -
but because I saw teammates get their teeth into an interesting problem,
then burn cycles trying to optimize something only done once in a blue
moon.
The whole 'story points' or other agile bushwah at least gets the
programmers committed to shipping software that does something somebody
wants. Sure, that is what management is supposed to do, but a lot of
those managers have never been taught how to manage. Thus, a wise
developer finds ways to manage their own time, and ways to be clear
about what they need their manager to do to get the job done.
Story points is just one of many ways, and it works or it fails
depending on who does it, and how much their own management is listening.
[...]
Yep. I have used Agile and XP methodologies, along with waterfall, seat
of the pants, low hanging fruit, and hardest problem in sight. Each one
worked or failed depending on the team, the project, and the management.
I sense bitterness.
Look, better, faster, cheaper, and useful all depend on the next word -
better than _what_. If an agile methodology means that your team
figures out that they have six months of work, and three months of
schedule sometime in month one, rather than in the last week of month
three, then it did its job. If it then lets you prove it to whoever is
setting the schedule, then you had a big win.
If it is just a set of buzzwords a manager uses, and that the team could
care less about, it is a waste of time. Like any other methodology.
It is not magic, it is not a mind control laser that will make your
management get clue it has lacked. It may, though, have the buzzwords
needed to get someone to listen. Very often, getting a dramatic change
requires evidence that someone else tried a similar change, and is still
employed.
Scott
Ahh, there we are. A story points chart, doesn't that sound
lovely? Well guess what. It's a dated to do list, although
when created by people that buy into lingo instead of action,
it's probably not as informative.
I have joined very few software teams whose programmers had a good grasp
of time, or progress towards the goal.
After one dreadful experience, I started to make 'what is the goal, and
how are we doing on getting there' a part of my toolkit. Not because I
love project management or project planning - I prefer writing code -
but because I saw teammates get their teeth into an interesting problem,
then burn cycles trying to optimize something only done once in a blue
moon.
The whole 'story points' or other agile bushwah at least gets the
programmers committed to shipping software that does something somebody
wants. Sure, that is what management is supposed to do, but a lot of
those managers have never been taught how to manage. Thus, a wise
developer finds ways to manage their own time, and ways to be clear
about what they need their manager to do to get the job done.
Story points is just one of many ways, and it works or it fails
depending on who does it, and how much their own management is listening.
[...]
"Well, here¹s the bottom line: Agile methods are merely a
technique for managing software projects. Their purpose is to
provide managers with the data they need to make timely
management decisions. And this should be good news for those
project managers who know that managing a software project often
involves more prayer than science."
Yep. I have used Agile and XP methodologies, along with waterfall, seat
of the pants, low hanging fruit, and hardest problem in sight. Each one
worked or failed depending on the team, the project, and the management.
So there is the smoking gun, it is to make managers happy. Note
that it doesn't say anything about better, faster, cheaper, or
anything that might actually be useful, but gives them better
charts for their powerpoint presentations to the next layer of
morons in the meeting next Tuesday.
I sense bitterness.
Look, better, faster, cheaper, and useful all depend on the next word -
better than _what_. If an agile methodology means that your team
figures out that they have six months of work, and three months of
schedule sometime in month one, rather than in the last week of month
three, then it did its job. If it then lets you prove it to whoever is
setting the schedule, then you had a big win.
If it is just a set of buzzwords a manager uses, and that the team could
care less about, it is a waste of time. Like any other methodology.
It is not magic, it is not a mind control laser that will make your
management get clue it has lacked. It may, though, have the buzzwords
needed to get someone to listen. Very often, getting a dramatic change
requires evidence that someone else tried a similar change, and is still
employed.
Scott