[SCRUMDEVELOPMENT] Completely new to Agile Dev principles, and it sure feels like I'm in over my head right now...

[[e-mail] [SCRUMDEVELOPMENT]]

Hi, Scott here. I work remotely (strike 1 against Agile Dev) as a newly christened Project Manager for a software company that uses a combination of onsite and offshore assets (strike 2) in their workflow as a matter of process.


The project I was handed as my first effort in this role is an enormous (strike 3) database migration, where the client insisted we employ Agile Dev principles because they wanted tangible deliverables to be delivered regularly (which would be reasonable if not for the scope of the project).


I knew, when I saw the scope of this project, that Agile was not going to work, so I've been doing my best to adapt at least some of the principles to improve workflow and engagement.



So now I'm neck-deep in it, and I'm taking fire from all directions. Trying to teach the offshore team about Agile principles and my need for them to be creatively involved in the project instead of just waiting for me to tell them exactly what to do and how to do it is an exercise in futility thanks to language and culture barriers. Even the client side is driving me nuts. The communication is so poor, my primary contact on the client side is telling me that my burndown chart tells him that my team is falling behind because the actual tickets remaining line is below the projected line (!!!!!)


I'm at my wit's end here. Advise would be great. And yes, I know, send out resumes is good advice, but that's really not an option at this point. I have to figure out how to keep this whole thing from crashing and burning.

[Michael Vizdos [e-mail] [SCRUMDEVELOPMENT]]

If you have one boss, talk to that person about what is keeping them up at
night that you can help solve for them.

One. Thing.

Work on that.

The rest is burning and will continue to burn.

While it totally can be a career limiting move (as you have stated with the
resume comment) remember your job is to WHAT (get clarity on that).

I am sure others will have comments coming.

Good luck with this. I feel deep empathy for you.

Agile and Scrum exposes organizational dysfunctions. Here they are.

- Mike Vizdos
Focus. #deliver

Post by ***@yahoo.com [SCRUMDEVELOPMENT]
Hi, Scott here. I work remotely (strike 1 against Agile Dev) as a newly
christened Project Manager for a software company that uses a combination
of onsite and offshore assets (strike 2) in their workflow as a matter of
process.
The project I was handed as my first effort in this role is an enormous
(strike 3) database migration, where the client insisted we employ Agile
Dev principles because they wanted tangible deliverables to be delivered
regularly (which would be reasonable if not for the scope of the project).
I knew, when I saw the scope of this project, that Agile was not going to
work, so I've been doing my best to adapt at least some of the principles
to improve workflow and engagement.
So now I'm neck-deep in it, and I'm taking fire from all directions.
Trying to teach the offshore team about Agile principles and my need for
them to be creatively involved in the project instead of just waiting for
me to tell them exactly what to do and how to do it is an exercise in
futility thanks to language and culture barriers. Even the client side is
driving me nuts. The communication is so poor, my primary contact on the
client side is telling me that my burndown chart tells him that my team is
falling behind because the actual tickets remaining line is below the
projected line (!!!!!)
I'm at my wit's end here. Advise would be great. And yes, I know, send
out resumes is good advice, but that's really not an option at this point.
I have to figure out how to keep this whole thing from crashing and burning.

[Alan Dayley [e-mail] [SCRUMDEVELOPMENT]]

Why do you have to be the lone hero to solve this? Does anyone else want a
positive result? Who are those people that care and can be your partners in
improving the work? I don't mean lip-service people. I mean people who will
reserve and spend time doing things to solve problems.

Be transparent about the problems. Find the most painful one and work on
solving it. Sometimes one seemingly simple or small improvement can have a
huge impact. Your partners can help you find and improve those things.

I wish you luck!

Alan

Post by Michael Vizdos ***@gmail.com [SCRUMDEVELOPMENT]
If you have one boss, talk to that person about what is keeping them up at
night that you can help solve for them.
One. Thing.
Work on that.
The rest is burning and will continue to burn.
While it totally can be a career limiting move (as you have stated with
the resume comment) remember your job is to WHAT (get clarity on that).
I am sure others will have comments coming.
Good luck with this. I feel deep empathy for you.
Agile and Scrum exposes organizational dysfunctions. Here they are.
- Mike Vizdos
Focus. #deliver

Post by ***@yahoo.com [SCRUMDEVELOPMENT]
Hi, Scott here. I work remotely (strike 1 against Agile Dev) as a newly
christened Project Manager for a software company that uses a combination
of onsite and offshore assets (strike 2) in their workflow as a matter of
process.
The project I was handed as my first effort in this role is an enormous
(strike 3) database migration, where the client insisted we employ Agile
Dev principles because they wanted tangible deliverables to be delivered
regularly (which would be reasonable if not for the scope of the project).
I knew, when I saw the scope of this project, that Agile was not going to
work, so I've been doing my best to adapt at least some of the principles
to improve workflow and engagement.
So now I'm neck-deep in it, and I'm taking fire from all directions.
Trying to teach the offshore team about Agile principles and my need for
them to be creatively involved in the project instead of just waiting for
me to tell them exactly what to do and how to do it is an exercise in
futility thanks to language and culture barriers. Even the client side is
driving me nuts. The communication is so poor, my primary contact on the
client side is telling me that my burndown chart tells him that my team is
falling behind because the actual tickets remaining line is below the
projected line (!!!!!)
I'm at my wit's end here. Advise would be great. And yes, I know, send
out resumes is good advice, but that's really not an option at this point.
I have to figure out how to keep this whole thing from crashing and burning.
--

Thank you.
- mike
Focus. #deliver
www.michaelvizdos.com

[Scott Griffin [e-mail] [SCRUMDEVELOPMENT]]

Mike, 
Actually, that was probably the best thing I could have heard right now.  Me running around with my hair on fire isn't going to put the inferno out, it's just going to make me look as incompetent as everyone else.  
Thank you, sir.


On Wednesday, September 20, 2017 5:58 PM, "Michael Vizdos ***@gmail.com [SCRUMDEVELOPMENT]" <***@yahoogroups.com> wrote:



  If you have one boss, talk to that person about what is keeping them up at night that you can help solve for them.  One. Thing.  Work on that.  The rest is burning and will continue to burn.  While it totally can be a career limiting move (as you have stated with the resume comment) remember your job is to WHAT (get clarity on that).  I am sure others will have comments coming.  Good luck with this.  I feel deep empathy for you.  Agile and Scrum exposes organizational dysfunctions.  Here they are.  - Mike Vizdos
  Focus.  #deliver
On Wed, Sep 20, 2017, 4:29 PM ***@yahoo.com [SCRUMDEVELOPMENT] <***@yahoogroups.com> wrote:


  Hi, Scott here.  I work remotely (strike 1 against Agile Dev) as a newly christened Project Manager for a software company that uses a combination of onsite and offshore assets (strike 2) in their workflow as a matter of process.
The project I was handed as my first effort in this role is an enormous (strike 3) database migration, where the client insisted we employ Agile Dev principles because they wanted tangible deliverables to be delivered regularly (which would be reasonable if not for the scope of the project).  
I knew, when I saw the scope of this project, that Agile was not going to work, so I've been doing my best to adapt at least some of the principles to improve workflow and engagement.


So now I'm neck-deep in it, and I'm taking fire from all directions.  Trying to teach the offshore team about Agile principles and my need for them to be creatively involved in the project instead of just waiting for me to tell them exactly what to do and how to do it is an exercise in futility thanks to language and culture barriers.  Even the client side is driving me nuts.  The communication is so poor, my primary contact on the client side is telling me that my burndown chart tells him that my team is falling behind because the actual tickets remaining line is below the projected line (!!!!!)
I'm at my wit's end here.  Advise would be great.  And yes, I know, send out resumes is good advice, but that's really not an option at this point.  I have to figure out how to keep this whole thing from crashing and burning.

[Michael Wollin [e-mail] [SCRUMDEVELOPMENT]]

Agree. Mike’s advice is spot on!

Mike,
Actually, that was probably the best thing I could have heard right now. Me running around with my hair on fire isn't going to put the inferno out, it's just going to make me look as incompetent as everyone else.
Thank you, sir.
If you have one boss, talk to that person about what is keeping them up at night that you can help solve for them.
One. Thing.
Work on that.
The rest is burning and will continue to burn.
While it totally can be a career limiting move (as you have stated with the resume comment) remember your job is to WHAT (get clarity on that).
I am sure others will have comments coming.
Good luck with this. I feel deep empathy for you.
Agile and Scrum exposes organizational dysfunctions. Here they are.
- Mike Vizdos
Focus. #deliver
Hi, Scott here. I work remotely (strike 1 against Agile Dev) as a newly christened Project Manager for a software company that uses a combination of onsite and offshore assets (strike 2) in their workflow as a matter of process.
The project I was handed as my first effort in this role is an enormous (strike 3) database migration, where the client insisted we employ Agile Dev principles because they wanted tangible deliverables to be delivered regularly (which would be reasonable if not for the scope of the project).
I knew, when I saw the scope of this project, that Agile was not going to work, so I've been doing my best to adapt at least some of the principles to improve workflow and engagement.
So now I'm neck-deep in it, and I'm taking fire from all directions. Trying to teach the offshore team about Agile principles and my need for them to be creatively involved in the project instead of just waiting for me to tell them exactly what to do and how to do it is an exercise in futility thanks to language and culture barriers. Even the client side is driving me nuts. The communication is so poor, my primary contact on the client side is telling me that my burndown chart tells him that my team is falling behind because the actual tickets remaining line is below the projected line (!!!!!)
I'm at my wit's end here. Advise would be great. And yes, I know, send out resumes is good advice, but that's really not an option at this point. I have to figure out how to keep this whole thing from crashing and burning.
--
Thank you.
- mike
Focus. #deliver
www.michaelvizdos.com <http://www.michaelvizdos.com/>

[[e-mail] [SCRUMDEVELOPMENT]]

Hi Scott,

I'd like to comment on the part you've called "strike 3" against
Agile - the database migration. I understand why you may think Agile
may not be suitable for that work, but that's not necessarily true.

Agile teams have migrated large databases - at least several
terabytes, and no reason they could not be much larger. I know because
I coached a group of teams doing exactly that at a bank. They kept the
apps working that accessed the databases, while migrating one database
table at a time to a new vendor's database. Essentially the "seam"
between old and new database kept moving each day but that was at a
level lower than the apps in use by the bank's employees.

Of course this could not be done without Agile tech practices (think
XP). Way too many teams try to use Scrum without any automated tests,
refactoring, or automated builds etc. That's a fatal though all too
common mistake. You can rapidly build those skills but since you're
under time pressure, I believe you'd need to bring in a good technical
coach on each team, including the offshore ones.

Best of luck in your Agile initiative!

- Nancy V.

Post by ***@yahoo.com [SCRUMDEVELOPMENT]
Hi, Scott here. I work remotely (strike 1 against Agile Dev) as a newly christened Project Manager for a software company that uses a combination of onsite and offshore assets (strike 2) in their workflow as a matter of process.
The project I was handed as my first effort in this role is an enormous (strike 3) database migration, where the client insisted we employ Agile Dev principles because they wanted tangible deliverables to be delivered regularly (which would be reasonable if not for the scope of the project).
I knew, when I saw the scope of this project, that Agile was not going to work, so I've been doing my best to adapt at least some of the principles to improve workflow and engagement.
So now I'm neck-deep in it, and I'm taking fire from all directions. Trying to teach the offshore team about Agile principles and my need for them to be creatively involved in the project instead of just waiting for me to tell them exactly what to do and how to do it is an exercise in futility thanks to language and culture barriers. Even the client side is driving me nuts. The communication is so poor, my primary contact on the client side is telling me that my burndown chart tells him that my team is falling behind because the actual tickets remaining line is below the projected line (!!!!!)
I'm at my wit's end here. Advise would be great. And yes, I know, send out resumes is good advice, but that's really not an option at this point. I have to figure out how to keep this whole thing from crashing and burning.

[[e-mail] [SCRUMDEVELOPMENT]]

Nancy,

I wasn't suggesting it wasn't viable for a DB migration, more speaking to the fact that this is a pretty massive migration and, when I was handed the "keys" to this clunker, a 6-month sprint plan (26 two-week sprints) was handed to me with expected deliverables for each sprint.


My understanding is that large-scale projects like this are not good candidates for Agile principles, and definitely that planning them out this far in advance is a terrible idea according to Agile methodologies.


To the rest of you, thank you, some good thoughts here. Working remotely leaves me feeling pretty isolated on the whole situation, because I have to wait for people to respond and/or be available to communicate, then I have to hope (again, language/cultural barriers) they are understanding what I'm trying to tell them.

[Kevin Johnston [e-mail] [SCRUMDEVELOPMENT]]

Does the product owner exist in all of this? If so might be worth
explaining the dysfunctions to them and explaining it’s unlikely to be
fixed without some help re coaching around communications and the agile
principles. I’m assuming the person that told you to use agile is
effectively the P.O. it’s good they see agile as a way forward but they
need to understand that it highlights the problems which have to be solved
if you actually want to be agile and deliver regular value.

Hope it works out

Kevin

[George Dinwiddie [e-mail] [SCRUMDEVELOPMENT]]

Scott,

You've gotten some good advice. I'll add one more suggestion.

Find some meaningful way of measuring progress. In this case, I'd want
to measure the ability to use the migrated data. If you can figure out
the ways in which it's currently being used, you can track progress by
which of those ways can be successfully used on the migrated database.
This will give you a clear view of the progress in a way that's less
likely to hide undoneness. It might also give you some good ideas on how
to chunk the work for taking smaller steps and setting priorities.

- George

Post by Scott Griffin ***@yahoo.com [SCRUMDEVELOPMENT]
Hi, Scott here.  I work remotely (strike 1 against Agile Dev) as a newly
christened Project Manager for a software company that uses a
combination of onsite and offshore assets (strike 2) in their workflow
as a matter of process.
The project I was handed as my first effort in this role is an enormous
(strike 3) database migration, where the client insisted we employ Agile
Dev principles because they wanted tangible deliverables to be delivered
regularly (which would be reasonable if not for the scope of the project).
I knew, when I saw the scope of this project, that Agile was not going
to work, so I've been doing my best to adapt at least some of the
principles to improve workflow and engagement.
So now I'm neck-deep in it, and I'm taking fire from all directions.
Trying to teach the offshore team about Agile principles and my need for
them to be creatively involved in the project instead of just waiting
for me to tell them exactly what to do and how to do it is an exercise
in futility thanks to language and culture barriers.  Even the client
side is driving me nuts.  The communication is so poor, my primary
contact on the client side is telling me that my burndown chart tells
him that my team is falling behind because the actual tickets remaining
line is below the projected line (!!!!!)
I'm at my wit's end here.  Advise would be great.  And yes, I know, send
out resumes is good advice, but that's really not an option at this
point.  I have to figure out how to keep this whole thing from crashing
and burning.