A Practical Question

[David A Barrett]

I have a situation that I'm hoping the list can help me with.

We're a small team (4 people) doing development work for internal business
units. Of necessity, each of our Scrums need to address a number of
different projects and one-off items for a variety of departments. We do
our best to keep the departments focused on strategic goals, and we find
that this is working very well.

Here's the problem. We've got a project coming down the pipe that we've
known about for some time. This project involves outside business partners
and has been mired in contract negotiations, internal executive approval
process and the like for some time now. We have an idea of the scope of
the project, but only restricted access to necessary outside technical
resources until the contracts are signed. We're reluctant (refuse) to
start work on this project prior to final approval, even if we could start
now (which we probably couldn't). Our current Sprint ends November 12th.
We are likely to find out that project has a formal go ahead sometime next
week, and they would like to be in a position to do some restricted
implementation by December 1st.

The quantity of work feels do-able in that time (possibly). It doesn't
feel do-able in the time from November 15th to December 1st. We don't want
Scrum to become a "bondage and discipline" methodology that gets in the way
of IT being an "enabler" of business initiatives. On the other hand, we
are extremely happy with the results we get from Scrum and like idea of
being able to say, "We have a system, it works, and if you want our help
you'll need to play by our rules". We don't want to jettison the
methodology this time, because that sends the message that we're willing to
jettison the methodology and the business unit involved will keep bringing
up projects in the future that won't fit into our Sprint schedule.

In the course, Ken paints this as a rather black and white picture. If the
customers start to get silly and messing around with the process, you call
a Premature Termination of Sprint, nobody gets anything and you start all
over. In our mixed bag Sprints, though, this would penalize the other
internal business units.

So, the question: How can I handle this situation, get the work done by
December 1, and still preserve some adherence to Scrum principles?


Dave Barrett,
Lawyers' Professional Indemnity Company



------------------------ Yahoo! Groups Sponsor --------------------~-->
$9.95 domain names from Yahoo!. Register anything.
http://us.click.yahoo.com/J8kdrA/y20IAA/yQLSAA/9EfwlB/TM
--------------------------------------------------------------------~->

To Post a message, send it to: ***@eGroups.com
To Unsubscribe, send a blank message to: scrumdevelopment-***@eGroups.com
Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/scrumdevelopment/

<*> To unsubscribe from this group, send an email to:
scrumdevelopment-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

[m***@comcast.net]

David:
Are you running this project or does the contract include the vendor providing the project management?

I ask because if the vendor is running the project then you need to establish explicit interface rules that allow you to manage your area.


--
Mike Dwyer

"I Keep six faithful serving-men
Who serve me well and true:
Their names are What and Where and When
And How and Why and Who." - Kipling

-------------- Original message --------------

Post by David A Barrett
I have a situation that I'm hoping the list can help me with.
We're a small team (4 people) doing development work for internal business
units. Of necessity, each of our Scrums need to address a number of
different projects and one-off items for a variety of departments. We do
our best to keep the departments focused on strategic goals, and we find
that this is working very well.
Here's the problem. We've got a project coming down the pipe that we've
known about for some time. This project involves outside business partners
and has been mired in contract negotiations, internal executive approval
process and the like for some time now. We have an idea of the scope of
the project, but only restricted access to necessary outside technical
resources until the contracts are signed. We're reluctant (refuse) to
start work on this project prior to final approval, even if we could start
now (which we probably couldn't). Our current Sprint ends November 12th.
We are likely to find out that project has a formal go ahead sometime next
week, and they would like to be in a position to do some restricted
implementation by December 1st.
The quantity of work feels do-able in that time (possibly). It doesn't
feel do-able in the time from November 15th to December 1st. We don't want
Scrum to become a "bondage and discipline" methodology that gets in the way
of IT being an "enabler" of business initiatives. On the other hand, we
are extremely happy with the results we get from Scrum and like idea of
being able to say, "We have a system, it works, and if you want our help
you'll need to play by our rules". We don't want to jettison the
methodology this time, because that sends the message that we're willing to
jettison the methodology and the business unit involved will keep bringing
up projects in the future that won't fit into our Sprint schedule.
In the course, Ken paints this as a rather black and white picture. If the
customers start to get silly and messing around with the process, you call
a Premature Termination of Sprint, nobody gets anything and you start all
over. In our mixed bag Sprints, though, this would penalize the other
internal business units.
So, the question: How can I handle this situation, get the work done by
December 1, and still preserve some adherence to Scrum principles?
Dave Barrett,
Lawyers' Professional Indemnity Company
Yahoo! Groups Links

[Mike Cohn]

Can the team, ScrumMaster and Product get together and agree to an early
termination of the current sprint with some delivered functionality? That
is, some of what is done is salvageable either immediately or with a day or
two (or more) of work. If you spent a day or two wrapping up, couldn't you
then start a new sprint that delivered the new project with perhaps some of
the currently planned features that would get dropped?

--Mike Cohn
Author of User Stories Applied for Agile Software Development
www.mountaingoatsoftware.com
www.userstories.com

-----Original Message-----
From: David A Barrett [mailto:***@lawpro.ca]
Sent: Friday, October 29, 2004 7:19 AM
To: ***@yahoogroups.com
Subject: [scrumdevelopment] A Practical Question






I have a situation that I'm hoping the list can help me with.

We're a small team (4 people) doing development work for internal business
units. Of necessity, each of our Scrums need to address a number of
different projects and one-off items for a variety of departments. We do
our best to keep the departments focused on strategic goals, and we find
that this is working very well.

Here's the problem. We've got a project coming down the pipe that we've
known about for some time. This project involves outside business partners
and has been mired in contract negotiations, internal executive approval
process and the like for some time now. We have an idea of the scope of
the project, but only restricted access to necessary outside technical
resources until the contracts are signed. We're reluctant (refuse) to
start work on this project prior to final approval, even if we could start
now (which we probably couldn't). Our current Sprint ends November 12th.
We are likely to find out that project has a formal go ahead sometime next
week, and they would like to be in a position to do some restricted
implementation by December 1st.

The quantity of work feels do-able in that time (possibly). It doesn't
feel do-able in the time from November 15th to December 1st. We don't want
Scrum to become a "bondage and discipline" methodology that gets in the way
of IT being an "enabler" of business initiatives. On the other hand, we
are extremely happy with the results we get from Scrum and like idea of
being able to say, "We have a system, it works, and if you want our help
you'll need to play by our rules". We don't want to jettison the
methodology this time, because that sends the message that we're willing to
jettison the methodology and the business unit involved will keep bringing
up projects in the future that won't fit into our Sprint schedule.

In the course, Ken paints this as a rather black and white picture. If the
customers start to get silly and messing around with the process, you call
a Premature Termination of Sprint, nobody gets anything and you start all
over. In our mixed bag Sprints, though, this would penalize the other
internal business units.

So, the question: How can I handle this situation, get the work done by
December 1, and still preserve some adherence to Scrum principles?


Dave Barrett,
Lawyers' Professional Indemnity Company




To Post a message, send it to: ***@eGroups.com
To Unsubscribe, send a blank message to:
scrumdevelopment-***@eGroups.com
Yahoo! Groups Links









------------------------ Yahoo! Groups Sponsor --------------------~-->
Make a clean sweep of pop-up ads. Yahoo! Companion Toolbar.
Now with Pop-Up Blocker. Get it for free!
http://us.click.yahoo.com/L5YrjA/eSIIAA/yQLSAA/9EfwlB/TM
--------------------------------------------------------------------~->

To Post a message, send it to: ***@eGroups.com
To Unsubscribe, send a blank message to: scrumdevelopment-***@eGroups.com
Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/scrumdevelopment/

<*> To unsubscribe from this group, send an email to:
scrumdevelopment-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

[Boris Gloger]

On Fri, 29 Oct 2004 09:19:05 -0400, David A Barrett

Post by David A Barrett
I have a situation that I'm hoping the list can help me with.

[...]

Post by David A Barrett
Here's the problem. We've got a project coming down the pipe that we've
known about for some time. This project involves outside business partners
and has been mired in contract negotiations, internal executive approval
process and the like for some time now. We have an idea of the scope of
the project, but only restricted access to necessary outside technical
resources until the contracts are signed. We're reluctant (refuse) to
start work on this project prior to final approval, even if we could start
now (which we probably couldn't). Our current Sprint ends November 12th.
We are likely to find out that project has a formal go ahead sometime next
week, and they would like to be in a position to do some restricted
implementation by December 1st.
The quantity of work feels do-able in that time (possibly). It doesn't
feel do-able in the time from November 15th to December 1st.

[...]

Post by David A Barrett
So, the question: How can I handle this situation, get the work done by
December 1, and still preserve some adherence to Scrum principles?
Dave Barrett,

Hi Dave,

I have no out of the box advice for you, and I do not see how to solve
that problem on a simple way. What i doubt is, that the siutation is
so tight as you describe it. I mean, if the project did not start so
far, who defined that it needed to be ready by 1st of December? I mean
- the development team start to think about the amount of work, that
is able to deliver in the Sprint Planning. There was not Sprint
Planning, who did create this feeling that it is possible to deliver?

At the moment there is not project, as I understand, right? So lets
say you get the approval for running the project next week, lets say
on Thursday. Nobody will start on Friday. So you might start on Monday
the 8th, right?

If you really able to start on the 8th that would make me wonder. Are
all interfaces to outside partners defined? Are the responsibiliies
clear? I mean in a traditional project management world you would need
at least a week to set up the environment, right?

Why do you not start the project, but you do not waste the effort of
your team. You could set up the environment, talk to your partners
about the way you want to work with them and you could define the
necessary meetings for the week after the 12th. So you would not spent
the time of your team, besides your own time and you could define with
your customer on the 15th what they will get on the 1st of Dec. Maybe
only 80 % but - well that is all you can deliver.

Or you go the way that Mike suggestes - ask you business, what is more
important. The old project finished in the right way with deliverables
or waste everything and start now - without an approval?

The point is - you have to make clear - it is not the process which is
responsible for what happens, but the nonsens to non-start a project
with a clear defined end before starting the project.

boris


------------------------ Yahoo! Groups Sponsor --------------------~-->
Make a clean sweep of pop-up ads. Yahoo! Companion Toolbar.
Now with Pop-Up Blocker. Get it for free!
http://us.click.yahoo.com/L5YrjA/eSIIAA/yQLSAA/9EfwlB/TM
--------------------------------------------------------------------~->

To Post a message, send it to: ***@eGroups.com
To Unsubscribe, send a blank message to: scrumdevelopment-***@eGroups.com
Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/scrumdevelopment/

<*> To unsubscribe from this group, send an email to:
scrumdevelopment-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

[Hubert Smits]

Hello David,

Without knowing much about your company, and the way Scrum is
implemented I would have a question/assessment:

Is your management a full part of the Scrum implementation? In other
words, do they prioritise backlogs and decide which business values
are to be delivered in any sprint.

My assessment is that they are not, as you seem to be dealing with the
priority question.

I would only halt the current sprint if I feel that the business value
of the newer contract exceeds the business value of the current
sprint. But when proposing that to the management I would also make it
clear that the work done in the current sprint will deliver no
business value. Let the management make the choice: halt now, destroy
the invested money and deliver the new contract in a sprint. Or
complete the current sprint, then plan the next one. That next one has
two options: either run a full sprint, with a full delivery, and
deliver by 15 Dec. Or run one or two 2-week sprints. Delivering value
by Dec 1st, albeit not the full value.

This is the black and white option that Ken pictures, true. The reason
for doing this is to make the management fully aware of their
responsibilities. You are pulling them into Scrum. It is too easy for
them to leave you with the decision problem. You'll never get it right
(either your current customers get value and the next ones don't, or
vice versa), you take the blame, and they get on with playing golf.

The long and short: your management has to take on the
responsibilities that they own: make business decisions.

Just my 2p, remember that I can only assess, not assert, as I don't
know you, your company or projects.

Success with the process,

Hubert

On Fri, 29 Oct 2004 09:19:05 -0400, David A Barrett

Post by David A Barrett
I have a situation that I'm hoping the list can help me with.
We're a small team (4 people) doing development work for internal business
units. Of necessity, each of our Scrums need to address a number of
different projects and one-off items for a variety of departments. We do
our best to keep the departments focused on strategic goals, and we find
that this is working very well.
Here's the problem. We've got a project coming down the pipe that we've
known about for some time. This project involves outside business partners
and has been mired in contract negotiations, internal executive approval
process and the like for some time now. We have an idea of the scope of
the project, but only restricted access to necessary outside technical
resources until the contracts are signed. We're reluctant (refuse) to
start work on this project prior to final approval, even if we could start
now (which we probably couldn't). Our current Sprint ends November 12th.
We are likely to find out that project has a formal go ahead sometime next
week, and they would like to be in a position to do some restricted
implementation by December 1st.
The quantity of work feels do-able in that time (possibly). It doesn't
feel do-able in the time from November 15th to December 1st. We don't want
Scrum to become a "bondage and discipline" methodology that gets in the way
of IT being an "enabler" of business initiatives. On the other hand, we
are extremely happy with the results we get from Scrum and like idea of
being able to say, "We have a system, it works, and if you want our help
you'll need to play by our rules". We don't want to jettison the
methodology this time, because that sends the message that we're willing to
jettison the methodology and the business unit involved will keep bringing
up projects in the future that won't fit into our Sprint schedule.
In the course, Ken paints this as a rather black and white picture. If the
customers start to get silly and messing around with the process, you call
a Premature Termination of Sprint, nobody gets anything and you start all
over. In our mixed bag Sprints, though, this would penalize the other
internal business units.
So, the question: How can I handle this situation, get the work done by
December 1, and still preserve some adherence to Scrum principles?
Dave Barrett,
Lawyers' Professional Indemnity Company
Yahoo! Groups Links

------------------------ Yahoo! Groups Sponsor --------------------~-->
Make a clean sweep of pop-up ads. Yahoo! Companion Toolbar.
Now with Pop-Up Blocker. Get it for free!
http://us.click.yahoo.com/L5YrjA/eSIIAA/yQLSAA/9EfwlB/TM
--------------------------------------------------------------------~->

To Post a message, send it to: ***@eGroups.com
To Unsubscribe, send a blank message to: scrumdevelopment-***@eGroups.com
Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/scrumdevelopment/

<*> To unsubscribe from this group, send an email to:
scrumdevelopment-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

[David A Barrett]

First of all, thank you for all the suggestions and replies.

After our Scrum on Friday, I laid the situation out for the team. There
was no doubt in their minds; give management the option of terminating the
current Sprint in order to start on the new project right away. To be
honest, we smelled this coming, and we made an effort to unofficially
divide the current Sprint into two parts. Halfway through, we have fair
number of Sprint Backlog items completed (or close enough ) so that would
could deploy them, another bunch of Sprint Backlog items that haven't been
touched at all and only a very few items were we've invested any
significant amount of time but aren't yet completed.

We're supplying senior management with a list of what's been done, and what
will not be delivered if we terminate the Sprint tomorrow. We're going to
have a meeting shortly to get our minds wrapped around what this new
project will take to complete, and based on that we'll build some time
estimates and let senior management know how much (if any) of the dropped
items can be added to the new Sprint.

We like this approach, because it makes it brutally obvious the impact of
this kind of "planning" on the part of one business unit has on all of the
others. Personally, I've always viewed the "Premature Terminate of Sprint"
to be a bit of a big stick to use, and a little bit confrontational. On
the other hand, the team is fully booked, and the senior management need
the opportunity to tell us what the priorities are.

Post by Boris Gloger
If you really able to start on the 8th that would make me wonder. Are
all interfaces to outside partners defined? Are the responsibiliies
clear? I mean in a traditional project management world you would need
at least a week to set up the environment, right?

You know, I could have a programmers up and running tomorrow on this if I
wanted. Yeah, I don't know all of the details about anything, but I do
know that I'm going to need to add a few files to my database; I've got XML
transfers involved, so I'll need to build a handler for them; I've got to
send some flat files out to a third party, I can get someone started on a
program to build that. There's lots of other stuff that we could start
right away. In all of these cases, I don't have enough information to
finish, but I do have enough information to start with very little chance
that the programmers would go significantly astray before we had the
details they needed at hand.

What I can do, is to sit down with the team and go over the entire business
scenario with them, and share as much as I know about what the business
units involved are concerned about, what the business partners are looking
for and so on. Thusly informed, I hope, they'll be able to make superior
decisions about how to design stuff, when to design and build stuff and
where to ask for more information.

I've noticed that with brand new systems like this, the biggest hurdle is
the inability of the users to visualize the solution during the
specifications phase. One of the things I like about Agile is that you can
almost throw that aways, sit the programmers down with the users, cut some
code and show them what you've done so they can see it and comment.

Dave Barrett,
Lawyers' Professional Indemnity Company



------------------------ Yahoo! Groups Sponsor --------------------~-->
$9.95 domain names from Yahoo!. Register anything.
http://us.click.yahoo.com/J8kdrA/y20IAA/yQLSAA/9EfwlB/TM
--------------------------------------------------------------------~->

To Post a message, send it to: ***@eGroups.com
To Unsubscribe, send a blank message to: scrumdevelopment-***@eGroups.com
Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/scrumdevelopment/

<*> To unsubscribe from this group, send an email to:
scrumdevelopment-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

[Boris Gloger]

Hi Dave, ...

On Mon, 1 Nov 2004 14:32:09 -0500, David A Barrett

Post by David A Barrett
First of all, thank you for all the suggestions and replies.

[...]

Post by David A Barrett

Post by Boris Gloger
If you really able to start on the 8th that would make me wonder. Are
all interfaces to outside partners defined? Are the responsibiliies
clear? I mean in a traditional project management world you would need
at least a week to set up the environment, right?

You know, I could have a programmers up and running tomorrow on this if I
wanted. Yeah, I don't know all of the details about anything, but I do
know that I'm going to need to add a few files to my database; I've got XML
transfers involved, so I'll need to build a handler for them; I've got to
send some flat files out to a third party, I can get someone started on a
program to build that. There's lots of other stuff that we could start
right away. In all of these cases, I don't have enough information to
finish, but I do have enough information to start with very little chance
that the programmers would go significantly astray before we had the
details they needed at hand.
What I can do, is to sit down with the team and go over the entire business
scenario with them, and share as much as I know about what the business
units involved are concerned about, what the business partners are looking
for and so on. Thusly informed, I hope, they'll be able to make superior
decisions about how to design stuff, when to design and build stuff and
where to ask for more information.

[...]

thanks for quoting me and I would love to see your team working -
obviously your team is in a very good shape - to phrase it in this
way. But you answer makes me wonder again. Where is the customer? That
you could sit with your team to get this project running I have no
doubt. But is this your role?

Dave I do not want to agrue for the sake of arguing - my concern is
that I got the feeling from you explainations that the business is not
really engaged. It sounds as that they demand something from you
without doing their own part.

But this is only a feeling, based on some sentences and I am sitting
thousends of miles away and have not real insight - so feel free to
ignore this mail :))

Boris


------------------------ Yahoo! Groups Sponsor --------------------~-->
Make a clean sweep of pop-up ads. Yahoo! Companion Toolbar.
Now with Pop-Up Blocker. Get it for free!
http://us.click.yahoo.com/L5YrjA/eSIIAA/yQLSAA/9EfwlB/TM
--------------------------------------------------------------------~->

To Post a message, send it to: ***@eGroups.com
To Unsubscribe, send a blank message to: scrumdevelopment-***@eGroups.com
Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/scrumdevelopment/

<*> To unsubscribe from this group, send an email to:
scrumdevelopment-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

[David A Barrett]

Post by Boris Gloger
But you answer makes me wonder again. Where is the customer? That
you could sit with your team to get this project running I have no
doubt. But is this your role?
Dave I do not want to agrue for the sake of arguing - my concern is
that I got the feeling from you explainations that the business is not
really engaged. It sounds as that they demand something from you
without doing their own part.

That's a darned good question. Where IS the customer, and is he fully
engaged?

This project has two business units involved. One is a product department,
and the other is the finance department. The driver is the product
department, but the nature of the project is such that the bulk of the
responsibility for day to day operation falls on the finance department.
The project can be described in about 10 minutes, and the bulk of the work
will be building controls to make sure that the data communication works
properly, and that the finance people can track the beans properly and
reconcile the numbers in a timely manner. One of the outside business
partners is concerned that the system is secure and fiddle-proof at our
end. The other outside business partner just wants it to happen.

The bottom line is that any experienced software developer could tell the
various customers what they should want on this particular project. Is the
Finance Department fully engaged? Nah. Does that matter? Not really.
Our relationship with the finance department is such that they trust us not
build a system which won't give them the controls they need, and at this
point in time they don't have enough of a feel for how it will work to
start giving input into what controls they want. Also, the Controller's
office is right next door to mine and enough informal conversations will
take place over the next month to keep things on track.

All of this puts the IT department in the middle of the situation. Is that
bad? Not really, its part of our perceived value to the company; that we
can step out of the pure "developer" box and be involved in the business
decisions behind the requirements for the software when we have to.

As to my role? My role is make it happen. Period.

Dave Barrett,
Lawyers' Professional Indemnity Company



------------------------ Yahoo! Groups Sponsor --------------------~-->
$9.95 domain names from Yahoo!. Register anything.
http://us.click.yahoo.com/J8kdrA/y20IAA/yQLSAA/9EfwlB/TM
--------------------------------------------------------------------~->

To Post a message, send it to: ***@eGroups.com
To Unsubscribe, send a blank message to: scrumdevelopment-***@eGroups.com
Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/scrumdevelopment/

<*> To unsubscribe from this group, send an email to:
scrumdevelopment-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

[m***@comcast.net]

It sounds like you are going to be both the 'project guy' and the 'product owner guy'. It also sounds like their has been a lot of trust build up between you and the folks that write the checks for this project.

One of the truly great things about the methodology is that at no time is the check writer out of touch with what is going on. If you feel that the informal conversation level is going to keep them in control and you out of the middle - go for it. If not then keep in mind how many OH NO's it takes to trash a thousand attaboys.

--
Mike Dwyer

"I Keep six faithful serving-men
Who serve me well and true:
Their names are What and Where and When
And How and Why and Who." - Kipling

-------------- Original message --------------

Post by Boris Gloger
But you answer makes me wonder again. Where is the customer? That
you could sit with your team to get this project running I have no
doubt. But is this your role?
Dave I do not want to agrue for the sake of arguing - my concern is
that I got the feeling from you explainations that the business is not
really engaged. It sounds as that they demand something from you
without doing their own part.

That's a darned good question. Where IS the customer, and is he fully
engaged?
This project has two business units involved. One is a product department,
and the other is the finance department. The driver is the product
department, but the nature of the project is such that the bulk of the
responsibility for day to day operation falls on the finance department.
The project can be described in about 10 minutes, and the bulk of the work
will be building controls to make sure that the data communication works
properly, and that the finance people can track the beans properly and
reconcile the numbers in a timely manner. One of the outside business
partners is concerned that the system is secure and fiddle-proof at our
end. The other outside business partner just wants it to happen.
The bottom line is that any experienced software developer could tell the
various customers what they should want on this particular project. Is the
Finance Department fully engaged? Nah. Does that matter? Not really.
Our relationship with the finance department is such that they trust us not
build a system which won't give them the controls they need, and at this
point in time they don't have enough of a feel for how it will work to
start giving input into what controls they want. Also, the Controller's
office is right next door to mine and enough informal conversations will
take place over the next month to keep things on track.
All of this puts the IT department in the middle of the situation. Is that
bad? Not really, its part of our perceived value to the company; that we
can step out of the pure "developer" box and be involved in the business
decisions behind the requirements for the software when we have to.
As to my role? My role is make it happen. Period.
Dave Barrett,
Lawyers' Professional Indemnity Company
Yahoo! Groups Links

[David A Barrett]

Post by m***@comcast.net
It sounds like you are going to be both the 'project guy' and the 'product

owner guy'.

Hmmmm. More like the "product custodian guy". Once the Finance people
get their hands on it, and can understand it, they'll start to assume an
ownership role.

Dave Barrett,
Lawyers' Professional Indemnity Company



------------------------ Yahoo! Groups Sponsor --------------------~-->
Make a clean sweep of pop-up ads. Yahoo! Companion Toolbar.
Now with Pop-Up Blocker. Get it for free!
http://us.click.yahoo.com/L5YrjA/eSIIAA/yQLSAA/9EfwlB/TM
--------------------------------------------------------------------~->

To Post a message, send it to: ***@eGroups.com
To Unsubscribe, send a blank message to: scrumdevelopment-***@eGroups.com
Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/scrumdevelopment/

<*> To unsubscribe from this group, send an email to:
scrumdevelopment-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

[David A Barrett]

But all this still does not answer my question. How do BA's get
involved, if they have no knowledge of coding?

Re-arrange your teams, such that they have a mixture of coders, testers and
BA's. A single team is 100% responsible for delivering some quantity of
functionality/features in a single Sprint. Let them figure out how to best
use the talents of the team members.

We have group with three programmer types and one BA. The BA is 100% busy
through every Sprint. She is involved with requirements gathering and
documenting, organizing testing, performs testing, organizes demonstrations
and training sessions and a whole of other stuff that keeps the team on
track to actually delivery a quality working product at the end of the
Sprint.

Dave Barrett,
Lawyers' Professional Indemnity Company



------------------------ Yahoo! Groups Sponsor --------------------~-->
Make a clean sweep of pop-up ads. Yahoo! Companion Toolbar.
Now with Pop-Up Blocker. Get it for free!
http://us.click.yahoo.com/L5YrjA/eSIIAA/yQLSAA/9EfwlB/TM
--------------------------------------------------------------------~->

To Post a message, send it to: ***@eGroups.com
To Unsubscribe, send a blank message to: scrumdevelopment-***@eGroups.com
Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/scrumdevelopment/

<*> To unsubscribe from this group, send an email to:
scrumdevelopment-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

[Mike Dwyer]

A good BA can get the business rules into a place where they make sense in
both the business and in the compiler.

Well written code implementing terrible logic still smells.

Michael F. Dwyer

***@comcast.net
978 683 3439


-----Original Message-----
From: David A Barrett [mailto:***@lawpro.ca]
Sent: Thursday, November 04, 2004 10:19 AM
To: ***@yahoogroups.com
Subject: [scrumdevelopment] Re: Scrum and Business Analysts

But all this still does not answer my question. How do BA's get
involved, if they have no knowledge of coding?

Re-arrange your teams, such that they have a mixture of coders, testers and
BA's. A single team is 100% responsible for delivering some quantity of
functionality/features in a single Sprint. Let them figure out how to best
use the talents of the team members.

We have group with three programmer types and one BA. The BA is 100% busy
through every Sprint. She is involved with requirements gathering and
documenting, organizing testing, performs testing, organizes demonstrations
and training sessions and a whole of other stuff that keeps the team on
track to actually delivery a quality working product at the end of the
Sprint.

Dave Barrett,
Lawyers' Professional Indemnity Company




To Post a message, send it to: ***@eGroups.com
To Unsubscribe, send a blank message to:
scrumdevelopment-***@eGroups.com
Yahoo! Groups Links











------------------------ Yahoo! Groups Sponsor --------------------~-->
$9.95 domain names from Yahoo!. Register anything.
http://us.click.yahoo.com/J8kdrA/y20IAA/yQLSAA/9EfwlB/TM
--------------------------------------------------------------------~->

To Post a message, send it to: ***@eGroups.com
To Unsubscribe, send a blank message to: scrumdevelopment-***@eGroups.com
Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/scrumdevelopment/

<*> To unsubscribe from this group, send an email to:
scrumdevelopment-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/