Cell Phone Software Forum
| View previous topic :: View next topic |
| Author |
Message |
surf
Guest
|
 Posted: Fri May 25, 2007 7:19 am Post subject: Agile Manifesto |
 |
|
Here is part of the Agile Manifesto:
"Welcome changing requirements, even late in
development. Agile processes harness change for
the customer's competitive advantage."
Why shouldn't you try to encourage business owners to try to figure
out what they want in the long term ? In some cases you are not going
to be able to backtrack because you made a critical decision about
something at some point and if that changes it will adversly effect
what you end up with. It seems like in agile, you can argue planning
is problematic, but that doesn't mean you shouldn't encourage people
to try to make long term plans.
" The most efficient and effective method of
conveying information to and within a development
team is face-to-face conversation."
Where I work, people often feel they can no longer work from home or
telecommute as easily as they did before scrum meetings became the
norm. This effects working mothers, musicians, and frustration with
traffic jams etc.
Whatever happened to the idea that technology would make people's
lives easier ? At one time, people used to say the 4 day work week was
coming, but it seems alot of people work more than ever. |
|
| Back to top |
|
 |
| |
Ads |
Advertising
Sponsor
|
|
Gabriel Claramunt
Guest
|
| Posted: Fri May 25, 2007 8:23 am Post subject: Re: Agile Manifesto |
|
|
"surf" <surfunbear@yahoo.com> wrote in message
news:1180063165.553740.59530@o5g2000hsb.googlegroups.com...
....
| Quote: |
Why shouldn't you try to encourage business owners to try to figure
out what they want in the long term ?
..... |
IMHO we should do more than encourage... we should help them to figure what
they need (could be something quite different from what they want) . :-)
| Quote: |
" The most efficient and effective method of
conveying information to and within a development
team is face-to-face conversation."
Where I work, people often feel they can no longer work from home or
telecommute as easily as they did before scrum meetings became the
norm. This effects working mothers, musicians, and frustration with
traffic jams etc.
Whatever happened to the idea that technology would make people's
lives easier ? At one time, people used to say the 4 day work week was
coming, but it seems alot of people work more than ever.
|
Any process should be adapted to the team's culture and project
characteristics, doing something just because is mandated, is always
dangerous. Some high discipline "agile" process are not that easy to adapt,
because the interdependency of the process's practices.
Following a process is not an excuse to leave out the common sense ;-)
--
Gabriel Claramunt
http://gabrielsw.blogspot.com |
|
| Back to top |
|
|
| |
Ads |
Advertising
Sponsor
|
|
Phlip
Guest
|
| Posted: Fri May 25, 2007 9:51 am Post subject: Re: Agile Manifesto |
|
|
surf wrote:
| Quote: |
Here is part of the Agile Manifesto:
"Welcome changing requirements, even late in
development. Agile processes harness change for
the customer's competitive advantage."
Why shouldn't you try to encourage business owners to try to figure
out what they want in the long term ?
|
Because that burdens a project with its most important decisions made with
the least data.
Here's a hardware metaphor. Dell builds computers with only some small
number of parts in inventory. I think only 2 days worth. That means, each
time you order a computer with a Gizmo from Dell, a worker pulls 1 Gizmo
from the shelf, bolts it into your computer, and immediately orders 1 or 2
more Gizmos from a supplier. Dell does not work with a week or month of
inventory sitting on its shelves. They practice "Just in Time
Manufacturing".
Keeping a lot of requirements decisions on the shelf is just like inventory
on the shelf - the longer it sits the more obsolete it gets. Software teams
should practice "Just in Time Requirements".
| Quote: |
In some cases you are not going
to be able to backtrack because you made a critical decision about
something at some point and if that changes it will adversly effect
what you end up with. It seems like in agile, you can argue planning
is problematic, but that doesn't mean you shouldn't encourage people
to try to make long term plans.
|
Long term plans should be goals and directions, not line-item details.
All Agile projects do small features in order of business priority. The most
important thing, to the marketing department and end-users, must perforce be
the thing easiest to specify. This reduces the odds of backtracking.
If you need to backtrack your design, you should have unit tests to support
the refactoring.
| Quote: |
" The most efficient and effective method of
conveying information to and within a development
team is face-to-face conversation."
Where I work, people often feel they can no longer work from home or
telecommute as easily as they did before scrum meetings became the
norm. This effects working mothers, musicians, and frustration with
traffic jams etc.
|
I cover that by practicing a musical instrument during my commute. There's
always a way.
| Quote: |
Whatever happened to the idea that technology would make people's
lives easier ? At one time, people used to say the 4 day work week was
coming, but it seems alot of people work more than ever.
|
Ideally, we would teleconference inside holodecks. Most of that technology
is available, and of course it's absurdly expensive.
The more high-bandwidth your communication, the faster and leaner you can
work. Twenty misdirected emails could have been prevented by one raised
eyebrow.
As the Oil War continues this is going to be quite a hot topic, and another
interrim solution is less pair programming. If a team understands the cost,
and pairs most of the time, a little telecommuting would be quite humane.
--
Phlip
http://flea.sourceforge.net/PiglegToo_1.html |
|
| Back to top |
|
|
| |
Ads |
Advertising
Sponsor
|
|
surf
Guest
|
| Posted: Fri May 25, 2007 3:26 pm Post subject: Re: Agile Manifesto |
|
|
| Quote: |
Why shouldn't you try to encourage business owners to try to figure
out what they want in the long term ?
Because that burdens a project with its most important decisions made with
the least data.
|
Is it because the business people don't really want to think it
through ? Why does it seem I often hear that developers need to
understand the business, but I rarely hear that the business people
need to understand the technology ? If it is imbalanced like that, it
makes it sound like the business side is superior (though I find it
more dull and political, and then what would business be without the
technology ?). When managers subtly or subconsciously imply that the
business side is superior (some think that way and will bully and look
down on programmers when under pressure themselves from upper
management) it may cause you to have self esteem issues. My Uncle told
me being a manager after many years as a developer, life was easier,
he had to do less work, although another guy said he never wanted to
be a manager after they had him perform the duty of firing someone one
time.
At any rate, one of the big criticisms I have heard about american
companies is that they are too focuses on the short term, quarterly
earnings that stock brockers and stock owners pressure them to focus
on. I know myself that at times I can write psuedo code and try to
figure out what I want to write for an app, plan it through in detail
and think about it. This takes time, and is not allways done best in a
meeting.
| Quote: |
In some cases you are not going
to be able to backtrack because you made a critical decision about
something at some point and if that changes it will adversly effect
what you end up with. It seems like in agile, you can argue planning
is problematic, but that doesn't mean you shouldn't encourage people
to try to make long term plans.
Long term plans should be goals and directions, not line-item details.
All Agile projects do small features in order of business priority. The most
important thing, to the marketing department and end-users, must perforce be
the thing easiest to specify. This reduces the odds of backtracking.
If you need to backtrack your design, you should have unit tests to support
the refactoring.
|
here's a scenario, we ended up using an open source wiki, as time
goes on it seems more and more apparent that that was a bad decision,
though it was partly a political decision. We are basicaly stuck with
it because if we get rid of it we have to rewrite too much stuff,
supporting it means we are limited to what it can do or that whatever
we develop is limited and kludgy. We can't really back track on that
without the project appearng to be very inefficiently planned out. The
team decision thing is also a misnomer, because certain managers make
the big decisions and if you disagree with them you you may fear that
it will reflect badly on you and you are under pressure to get stuff
done. Any bad decision that is made may also reflect on you, so you
are affraid of sticking your neck out, but on the other hand any
decision made appears to be done with some lack of information. So the
agile thing sounds like this cool sounding "open communication" stuff
and all, but the reality is different. Sometimes you have to be
carefull of what problems you voice because the solution they will try
to get you to agree to might be worse than the problem.
| Quote: |
Whatever happened to the idea that technology would make people's
lives easier ? At one time, people used to say the 4 day work week was
coming, but it seems alot of people work more than ever.
Ideally, we would teleconference inside holodecks. Most of that technology
is available, and of course it's absurdly expensive.
|
It seems like technology could imprison people as much as make life
easier. With more sophisticated technology the govt could spy on you
and companies could track everything you do ..
> |
|
| Back to top |
|
|
| |
Ads |
Advertising
Sponsor
|
|
Guest
|
| Posted: Fri May 25, 2007 4:32 pm Post subject: Re: Agile Manifesto |
|
|
In article <1180092363.610841.165410@u30g2000hsc.googlegroups.com>, surf says...
| Quote: |
Why shouldn't you try to encourage business owners to try to figure
out what they want in the long term ?
Because that burdens a project with its most important decisions made with
the least data.
Is it because the business people don't really want to think it
through ? Why does it seem I often hear that developers need to
understand the business, but I rarely hear that the business people
need to understand the technology ? If it is imbalanced like that, it
makes it sound like the business side is superior (though I find it
more dull and political, and then what would business be without the
technology ?). <snip
|
It is not that the business people don't want to think it through, it is that
they cannot, because they are not in a position to. Part of what makes Agile,
and some of the previous methods like prototyping so powerful, is that they help
to flesh out ideas before a large commitment is made.
Doing Big Requirements Up Front, can lead to a system that does the wrong thing
very well, or one that does the right thing but in a poor workflow. You also
may luck out and end up doing the right thing, but that is by no means assured.
On your "business is superior" comment - they are the ones paying the bills - of
course they are 'superior' in that sense. To most of them, technology is a
service, like water and electricity. Their job is to run their business, not to
run the technology.
| Quote: |
At any rate, one of the big criticisms I have heard about american
companies is that they are too focuses on the short term, quarterly
earnings that stock brockers and stock owners pressure them to focus
on. I know myself that at times I can write psuedo code and try to
figure out what I want to write for an app, plan it through in detail
and think about it. This takes time, and is not allways done best in a
meeting.
|
Long-term view is a whole separate conversation! :-)
But you are correct, planning on the fly in a meeting is probably the *wrong*
way to go for many reasons. Eliciting requirements, however, through a series
of conversations and through the early development of *at least* lo-fi
prototypes, will give you a much better target to aim for.
sdg |
|
| Back to top |
|
|
| |
Ads |
Advertising
Sponsor
|
|
JXStern
Guest
|
| Posted: Fri May 25, 2007 8:08 pm Post subject: Re: Agile Manifesto |
|
|
On 25 May 2007 04:26:03 -0700, surf <surfunbear@yahoo.com> wrote:
| Quote: |
Here is part of the Agile Manifesto:
"Welcome changing requirements, even late in
development. Agile processes harness change for
the customer's competitive advantage."
|
What a sweet-sounding ... piece of nonsense.
| Quote: |
Why shouldn't you try to encourage business owners to try to figure
out what they want in the long term ? In some cases you are not going
to be able to backtrack because you made a critical decision about
something at some point and if that changes it will adversly effect
what you end up with. It seems like in agile, you can argue planning
is problematic, but that doesn't mean you shouldn't encourage people
to try to make long term plans.
|
Correctamundo.
| Quote: |
Why shouldn't you try to encourage business owners to try to figure
out what they want in the long term ?
Because that burdens a project with its most important decisions made with
the least data.
Is it because the business people don't really want to think it
through ?
|
Basically, yes.
The "standard" today is for IT to consume -zero- attention from the
executive suite, other than budget. This is DRAMATICALLY different
from both best practices and common practices twenty years ago. Why?
Well, I could rant about that at length, but the short version seems
to be that computers are so cheap and fast now, that they can hire
cheap and less-expert developers and let them work inefficiently and
still get what they need. It *works* for them.
| Quote: |
Why does it seem I often hear that developers need to
understand the business, but I rarely hear that the business people
need to understand the technology ?
|
I NEVER hear that the developers need to understand the business, that
is, I don't hear it today, although it was standard twenty years ago.
But just perhaps, it's making a comeback!
Several job interviews I've had recently have SHOCKED me, as they were
apparently unhappy with the nerdly types they'd been interviewing,
they wanted developers who could talk to users and come up with
requirements! Note that this is DIFFERENT from being a Dilbert-type
who expects the users to TELL them what the requirements are!
| Quote: |
If it is imbalanced like that, it
makes it sound like the business side is superior (though I find it
more dull and political, and then what would business be without the
technology ?).
|
Well, when push comes to shove, the business side is supposed to be
"superior" in deciding on the *business* initiatives to pursue. It's
a modern perversity to think that programmers should not even discuss
the issues of what works best from a systems perspective.
The defense is that the fast-turnaround which is what makes "agile"
agile, is a process means of coping with all issues. And to some
degree, this is effective.
| Quote: |
When managers subtly or subconsciously imply that the
business side is superior (some think that way and will bully and look
down on programmers when under pressure themselves from upper
management) it may cause you to have self esteem issues.
|
Again, the "standard" today is for programmers to be like Dilbert - no
mouth. As a result, those who are programmers today, often are those
who like having no mouth, they are PROUD of having no mouth, they wake
up every day with the goal of saying nothing about anything. Twas
always thus in the depths of large corporations, but it's more like
it's always been than it ever was, I guess.
| Quote: |
My Uncle told
me being a manager after many years as a developer, life was easier,
he had to do less work, although another guy said he never wanted to
be a manager after they had him perform the duty of firing someone one
time.
|
Management has its own skillsets, contrary to rumor, it's not just
about having the biggest dick.
| Quote: |
At any rate, one of the big criticisms I have heard about american
companies is that they are too focuses on the short term, quarterly
earnings that stock brockers and stock owners pressure them to focus
on. I know myself that at times I can write psuedo code and try to
figure out what I want to write for an app, plan it through in detail
and think about it. This takes time, and is not allways done best in a
meeting.
|
That of course is the downside to agile, people don't care about
quality, since you're just going to do it over three or four times
anyway, the process will take care of things. So don't aim, just
machine-gun everything in sight, in no particular order, if the
business people specify the order of targets and it's suboptimal from
a development point of view, it's the business people's own money
that's being wasted, so you get to laugh at them.
| Quote: |
here's a scenario, we ended up using an open source wiki, as time
goes on it seems more and more apparent that that was a bad decision,
though it was partly a political decision. We are basicaly stuck with
it because if we get rid of it we have to rewrite too much stuff,
supporting it means we are limited to what it can do or that whatever
we develop is limited and kludgy. We can't really back track on that
without the project appearng to be very inefficiently planned out. The
team decision thing is also a misnomer, because certain managers make
the big decisions and if you disagree with them you you may fear that
it will reflect badly on you and you are under pressure to get stuff
done. Any bad decision that is made may also reflect on you, so you
are affraid of sticking your neck out, but on the other hand any
decision made appears to be done with some lack of information. So the
agile thing sounds like this cool sounding "open communication" stuff
and all, but the reality is different. Sometimes you have to be
carefull of what problems you voice because the solution they will try
to get you to agree to might be worse than the problem.
|
Dude, that's life, and no methodology is going to change it!
| Quote: |
It seems like technology could imprison people as much as make life
easier. With more sophisticated technology the govt could spy on you
and companies could track everything you do ..
|
Power tools save you time, but can also cut off your fingers. We're
waaay beyond software development methodology in talking about this!
J. |
|
| Back to top |
|
|
| |
Ads |
Advertising
Sponsor
|
|
H. S. Lahman
Guest
|
| Posted: Fri May 25, 2007 9:08 pm Post subject: Re: Agile Manifesto |
|
|
Responding to Surf...
| Quote: |
Here is part of the Agile Manifesto:
"Welcome changing requirements, even late in
development. Agile processes harness change for
the customer's competitive advantage."
Why shouldn't you try to encourage business owners to try to figure
out what they want in the long term ? In some cases you are not going
to be able to backtrack because you made a critical decision about
something at some point and if that changes it will adversly effect
what you end up with. It seems like in agile, you can argue planning
is problematic, but that doesn't mean you shouldn't encourage people
to try to make long term plans.
|
You're right that this part of the manifesto is much less important now,
at least for commercial businesses. That's because most modern
commercial businesses employ some form of Rapid Product Development. In
RPD processes the requirements are always fully defined before any
commitment to development and they are very rarely changed. (RPD also
employs much shorter product cycles than the historical norm so changes
are easily pushed to the next cycle.)
Nonetheless, one still wishes to avoid major headaches in those rare
situations where the requirements do need to change. So one still needs
practices and processes that allow rapid responses to changes. In
addition, the spirit of the manifesto applies across product cycles.
Since commercial shops now use shorter product cycles there tends to be
a lot more maintenance as the "new product" actually enhances the old.
So the software still needs to be constructed to readily support change.
Bottom line: I think it is still valid but de-emphasized since the mid-'90s.
| Quote: |
" The most efficient and effective method of
conveying information to and within a development
team is face-to-face conversation."
Where I work, people often feel they can no longer work from home or
telecommute as easily as they did before scrum meetings became the
norm. This effects working mothers, musicians, and frustration with
traffic jams etc.
Whatever happened to the idea that technology would make people's
lives easier ? At one time, people used to say the 4 day work week was
coming, but it seems alot of people work more than ever.
|
This manifesto element is ideal from the developers' viewpoint because
in agile processes the customer is supposed to be readily available for
such communications throughout the cycle. However, as you point out, it
often does not work out well for the business units that surround the
software development.
The problem lies in the word 'effective'. Because developers are highly
focused on small stories, such communication can be effective because it
is easier to identify and clarify inconsistencies, omissions, and
whatnot. IOW, the communication content is quite small so one is better
able to evaluate its completeness, precision, and ambiguity. Because of
their short IID cycles, the agile processes also have rapid feedback
when the communications fail and the scope of resulting rework is quite
small.
One obvious way the effectiveness breaks down is when the customer is
not readily available to the developers for clarifications. In a
business producing shrink wrap sotware the customer is never available,
so one needs surrogates like Marketeers. But in many businesses the
Marketeers feel it is not a valid use of their time to spend it holding
the hands of the software developers. Quite often Management will agree
with them since the highest paid software developer is probably paid
less that the lowest paid Marketeer and Management wants to use its
money effectively by having the Marketeers focus on what they are being
paid Big Bucks to do. [Things get much worse in milaero where there are
periods when the customer is prohibited by law from communicating with
the developers.]
Another problem is acceptance testing. Providings acceptance tests for
an agile team is a full time job for at least two customers. Real
customers certainly have better things to do and Marketeer surrogates
will at least believe they have better things to do. So one needs a
separate SQA group to act as a customer surrogate in writing acceptance
tests. That's fine except for the communication of requirements.
Now the customer needs to tell both the developers and the SQA team what
the requirements are. Having both teams attend an initial planning
meeting to define stories addresses that. The problem, though, lies in
clarifications that the developers OR the SQA people obtain
subsequently. Those clarifications will tend to get out of synch and
lead to surprises when the acceptance tests are actual run. At best,
there is an inherent inefficiency in bringing them back into synch at
the end of the cycle.
This is aggravated by the fact that there two other groups that need to
understand the requirements: Documentation and Customer Support. Thus
there are four independent groups that must be kept in synch using
verbal communcations in a very informal manner. Since the primary focus
of communication is between customer and developer, it is usually the
other three groups who end up out of synch and scrambling at the end of
a cycle.
The obvious way to ensure synchronization with verbal requirements is
for /every/ stakeholder to be present every time requirements are
communicated. But since the focus is on developers, that means the other
groups need to organize their schedules around those of the developers.
As you point out, that gets to be a real mess, especially if the
developers seek their clarifications on an ad hoc basis as the issues arise.
A related problem is that it is often not clear who the stakeholders are
until the requirements are actually communicated. Typically
responsibilities in other groups will be organized differently than the
way the developers are. For example, there may be a single Documetation
writer assigned to the Help system for all development teams. So if the
requirements being communicated affect the Help system, that writer
needs to be there. But if it doesn't affect the Help system, it is a
waste of time for the writer to be there.
Bottom line: informal verbal communications can be effective for
developers in an agile environment, but they tend to break down for all
the surrounding business units. IOW, it is impossible to efficiently
keep four independent groups in synch without writing things down and,
more important, ensuring those descriptions are updated when
clarifications or requirements changes are made.
*************
There is nothing wrong with me that could
not be cured by a capful of Drano.
H. S. Lahman
hsl@pathfindermda.com
Pathfinder Solutions
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
"Model-Based Translation: The Next Step in Agile Development". Email
info@pathfindermda.com for your copy.
Pathfinder is hiring:
http://www.pathfindermda.com/about_us/careers_pos3.php.
(888)OOA-PATH |
|
| Back to top |
|
|
| |
Ads |
Advertising
Sponsor
|
|
Ron Ruble
Guest
|
| Posted: Sat May 26, 2007 7:10 pm Post subject: Re: Agile Manifesto |
|
|
surf wrote:
| Quote: |
Here is part of the Agile Manifesto:
"Welcome changing requirements, even late in
development. Agile processes harness change for
the customer's competitive advantage."
Why shouldn't you try to encourage business owners to try to figure
out what they want in the long term ?
|
Because it hasn't worked, historically, in many
businesses. It's like asking users not to click on
attachments in email; if the users complied, it would
immediately solve the bulk of malware problems through
email.
The only problem is that it doesn't work.
Not because the -idea- is bad; but because people
consistently fail to execute the idea successfully.
The reason the agile manifesto says to welcome
changing requirements is because changing our
processes to permit changes without derailing
the project is something we -can- do successfully.
| Quote: |
In some cases you are not going
to be able to backtrack because you made a critical decision about
something at some point and if that changes it will adversly effect
what you end up with.
|
True. Which is why agile methodologies address the
order in which features are implemented (business
order), verification of the correctness of decisions
(test-first development and frequent release of
running code), and simplifying changes when needed,
in order to minimize the adverse effect of late changes
of direction (test first and continuous refactoring).
| Quote: |
It seems like in agile, you can argue planning
is problematic, but that doesn't mean you shouldn't encourage people
to try to make long term plans.
|
Small push back. There is no benefit, either technical
or to the business, in people -trying- to make long
term plans. There is only benefit to -successfully-
making long term plans.
| Quote: |
" The most efficient and effective method of
conveying information to and within a development
team is face-to-face conversation."
Where I work, people often feel they can no longer work from home or
telecommute as easily as they did before scrum meetings became the
norm. This effects working mothers, musicians, and frustration with
traffic jams etc.
Whatever happened to the idea that technology would make people's
lives easier ? At one time, people used to say the 4 day work week was
coming, but it seems alot of people work more than ever.
|
Yes. But your argument is an argument against the
ethics or desirability of face-to-face communication.
The statement you're replying to says nothing about
desirability, only effectiveness.
Given that face-to-face communication is more effective,
how would you alter the work process or environment to
be effective -and- desirable?
Generate better results, less rework, fewer emergency
meetings, fewer cases where "I don't care if her kid is
sick, Angela -has- to be at the meeting and work on-site
this week. She's the only one who knows this part of
the app."
All things agile attempts to address. |
|
| Back to top |
|
|
| |
Ads |
Advertising
Sponsor
|
|
Phlip
Guest
|
| Posted: Sun May 27, 2007 10:10 pm Post subject: Re: Agile Manifesto |
|
|
surf wrote:
| Quote: |
Because that burdens a project with its most important decisions made
with
the least data.
Is it because the business people don't really want to think it
through ?
|
That would pass the buck to the business side.
| Quote: |
Why does it seem I often hear that developers need to
understand the business,
|
That passes the buck to the programmer side!
| Quote: |
but I rarely hear that the business people
need to understand the technology ?
|
Consider a super-big project, like an airport. You can't hold every nut and
bolt in your head, all at the same time, when you start. You can't predict
every variable. Yet we still build airports.
Google for Heathrow's upgrade, for an excellent example of a huge project
performed on-time and under-budget. They use something we can call "adaptive
planning".
| Quote: |
If it is imbalanced like that, it
makes it sound like the business side is superior (though I find it
more dull and political, and then what would business be without the
technology ?). When managers subtly or subconsciously imply that the
business side is superior (some think that way and will bully and look
down on programmers when under pressure themselves from upper
management) it may cause you to have self esteem issues. My Uncle told
me being a manager after many years as a developer, life was easier,
he had to do less work, although another guy said he never wanted to
be a manager after they had him perform the duty of firing someone one
time.
|
A power-sharing situation requires Bills of Rights. Look up "Developer Bill
of Rights" and "Customer Bill of Rights".
| Quote: |
At any rate, one of the big criticisms I have heard about american
companies is that they are too focuses on the short term, quarterly
earnings that stock brockers and stock owners pressure them to focus
on. I know myself that at times I can write psuedo code and try to
figure out what I want to write for an app, plan it through in detail
and think about it. This takes time, and is not allways done best in a
meeting.
|
If you mean the planning game, less is more. The best planning game is a few
minutes at the corkboard.
If you don't know the estimate for something, be honest and leave it wide.
If the customer asks you to make a smaller estimate (infringing on the
Developer Bill of Rights), you ask them to split the card (obeying the
Customer Bill of Rights).
In every situation, the card will split between high- and low-priority
details. "Don't worry about a treeview there just make a listview for now."
This is small-scale management that makes large scales possible. You eat an
elephant one spoonful at a time (and stop when full!). You plan multi-year
goals by showing your short-term goals are feasible, and by using live
results from a running program to help managers steer the project towards
those goals.
| Quote: |
here's a scenario, we ended up using an open source wiki, as time
goes on it seems more and more apparent that that was a bad decision,
though it was partly a political decision.
|
That transgressed the Bill of Rights, if someone in a Customer role foisted
the Wiki upon you.
If the developers accepted the Wiki and it doesn't work out long-term, then
this was simply a mistake. Passing blame is a political game.
After detecting the bad decision, you fix it.
| Quote: |
We are basicaly stuck with
it because if we get rid of it we have to rewrite too much stuff,
supporting it means we are limited to what it can do or that whatever
we develop is limited and kludgy.
|
But you have wall-to-wall unit tests, right? And you only picked a wiki that
itself had wall-to-wall unit tests, right?
People who try to be agile often discover they can't get more agile than
their upstream vendors.
| Quote: |
We can't really back track on that
without the project appearng to be very inefficiently planned out. The
team decision thing is also a misnomer, because certain managers make
the big decisions and if you disagree with them you you may fear that
it will reflect badly on you and you are under pressure to get stuff
done.
|
You have real numbers on your side - a chart of your velocity over time.
We had a high velocity before because we made a mistake with this Wiki. It's
why the velocity went down here, because it can't scale. Note that our other
modules still have a higher velocity.
We need to take a hit in velocity, now, to fix this Wiki, and then we will
have a higher velocity. If we don't fix it, we keep going down.
"Are you going to take a whole iteration just to fix the Wiki??"
No, we will leave it online for a while. But we need time in this iteration
to select an alternate Wiki. Then, in the next iteration, some stories will
be slower because we will be integrating them into the new Wiki instead of
the old one. That means we will get the benefit of the new Wiki, as early as
possible, for some of our features.
Over time, the old Wiki will run out of clients. Then we will retire it. We
expect our velocity to recover long before then!
| Quote: |
Any bad decision that is made may also reflect on you, so you
are affraid of sticking your neck out, but on the other hand any
decision made appears to be done with some lack of information. So the
agile thing sounds like this cool sounding "open communication" stuff
and all, but the reality is different. Sometimes you have to be
carefull of what problems you voice because the solution they will try
to get you to agree to might be worse than the problem.
|
The goal here is to unify authority and responsibility. If you have the
responsibility to make the code work, then you have the authority to decide
which modules go in it. And the authority to use "deprecation refactor" to
replace a bad module.
If your business side has the authority to direct features, they have the
responsibility to steer towards business goals using available resources.
This "open communication" thing is not lip-service, it is specific
guidelines about how and what to communicate.
| Quote: |
It seems like technology could imprison people as much as make life
easier. With more sophisticated technology the govt could spy on you
and companies could track everything you do ..
|
Hide in plain sight, comrade.
--
Phlip
http://flea.sourceforge.net/PiglegToo_1.html |
|
| Back to top |
|
|
| |
Ads |
Advertising
Sponsor
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
191 Attacks blocked
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
