Co-development partnerships
So, what happens when an Agile organization attempts to work a co-development project with a non-Agile organization? Panic! Chaos! Hilarity ensues!
We have these weekly status meetings with such a project. They are pressing us hard for "Final Design" this Friday so they can start development. Meanwhile, we're 3/4 complete with total development (not that we're telling them that), but missing design details on the 1/4 not yet addressed. Which has them in a total panic. This, in turn, puts our PMs in a total panic. Hilarity ensues.
In some ways this is similar to the problems faced by an Agile development group in a non-Agile organization: at the touch points (before and after development) the product development needs to look like a waterfall project. In a lot of ways it's different, however. Co-development requires functional areas to be synchronized. Therefore functional interfaces must be completed at roughly the same time for the project to move forward.
I think we could have avoided some of these issues had they given us their top concerns earlier. Unfortunately an SDLC/waterfall organization is unable to express their concerns early due to the "specs must be written first" mentality. At this point I see two ways forward - give them information we know to be incorrect to fulfill their need and force thru a change request when we have accurate data, or stall and deliver when we have more accurate data for their concern.
1. Deliver incorrect with intention to submit change later:
PRO: People are used to this approach with waterfall projects. They will become unblocked on the design doc and may start development.
CON: Must manage informal channels to insure development doesn't start on bad part of spec; change request may be denied, locking us to bad design.
2. Stall until accurate data is available:
PRO: They will not have option to develop incorrect solution.
CON: They may stall all development, even on complete areas, to satisfy process requirement.
Basically, everyone should move off of the SDLC development process. It would make my life a whole lot easier.
We have these weekly status meetings with such a project. They are pressing us hard for "Final Design" this Friday so they can start development. Meanwhile, we're 3/4 complete with total development (not that we're telling them that), but missing design details on the 1/4 not yet addressed. Which has them in a total panic. This, in turn, puts our PMs in a total panic. Hilarity ensues.
In some ways this is similar to the problems faced by an Agile development group in a non-Agile organization: at the touch points (before and after development) the product development needs to look like a waterfall project. In a lot of ways it's different, however. Co-development requires functional areas to be synchronized. Therefore functional interfaces must be completed at roughly the same time for the project to move forward.
I think we could have avoided some of these issues had they given us their top concerns earlier. Unfortunately an SDLC/waterfall organization is unable to express their concerns early due to the "specs must be written first" mentality. At this point I see two ways forward - give them information we know to be incorrect to fulfill their need and force thru a change request when we have accurate data, or stall and deliver when we have more accurate data for their concern.
1. Deliver incorrect with intention to submit change later:
PRO: People are used to this approach with waterfall projects. They will become unblocked on the design doc and may start development.
CON: Must manage informal channels to insure development doesn't start on bad part of spec; change request may be denied, locking us to bad design.
2. Stall until accurate data is available:
PRO: They will not have option to develop incorrect solution.
CON: They may stall all development, even on complete areas, to satisfy process requirement.
Basically, everyone should move off of the SDLC development process. It would make my life a whole lot easier.
posted by nitpickable at
12:04 PM
0 Comments:
Post a Comment
<< Home