Description: The focus of the discussion was how to deal with organizations/people outside of your control that have demands that are based on a more traditional "waterfall" model.
Organizer: Paul Boos
Attendees: Stuart Perron, Mike Cottmeyer, Lisamarie Babik, Tracy Beeson
We started and pretty much stayed with my (Paul's) problem statement. The worry is that parts of the organization (outside of your control, but must work with) that operate with little to zero agility may decrease you agility; what are ways to mitigate this risk? There were 4 areas of bureaucratic/non-agile areas that were addressed:
- IT Security; demands for documents, some out of nowhere, some pre-defined (example: security control matrix)
Paul plans to have a set of standard "templates" that would be filled in on this, that should reduce the time spent.
Lisamarie suggested that these either become stories or be connected to stories, which would also ensure that as a change to code that touched that touched the story the story isn't signed off until the matrix is updated. This would increase visibility and allow better estimation on these in the future. This was brilliant! (Wish I had though of it...Guess as a bureacrat, it fell out of the box of mmy thinking.)
- Budget development; budgeting far in advance for funds to be committed on projects or products that are not known or maybe only in a very general sense
Understanding estimates can help here for concepts that are bring kicked around for products or projects; obviously those that have not been hypothesized, can't be addressed.
- SDLC "Standards" group; the problem here is not that Paul's team is being affected, but frequent "accusations" occur from those that follow the standard SDLC process about the agile team not followingthem...
Paul has created a "map" between these processes, but it may not suffice; but it is more of trying to prevent interference that currently is not happening.
Mike had two suggestions: 1) follow the means of describing the risks as in the "Reinventing Project Management" book; there are four dimensions that characterize a project: complexity (technical risk), technology (task uncertainty), pace (urgency of the need), and novelty (uncertainty of the goal) - agile projects fit those with high risk and fast pace. Some details on this at the agile management BLOG 2) Follow the standard "waterfall" method if that is the general practice, but focus on setting up a sprint cadence during each phase with a deliverable product artifact and run each sprint as a sprint. As the group gets comfortable and those outside get comfortable, start combining design with requirements, then later add-in construction, and then add-in testing - at that point your agile! Mike also asked whether everyone really needed to be agile. He prompted us to ensure we didn't push agile into an organization where they actually CAN describe their requirements fully upfront, perhaps waterfall should not necessarily be abandoned in this case. There were some excellent suggestions from Tracy and Stuart on the issues that they see with their organizations and clients that they deal with as they transition.
- IT Infrastructure; folks that install and set-up test, staging, and production environments
We didn't really address this except to say we thought it just has to be something you need to plan.
I felt honoredto be there and thanks to everyone that came to my session! I got a lot out of it!
Return to Sessions2008
Organizer: Paul Boos
Attendees: Stuart Perron, Mike Cottmeyer, Lisamarie Babik, Tracy Beeson
We started and pretty much stayed with my (Paul's) problem statement. The worry is that parts of the organization (outside of your control, but must work with) that operate with little to zero agility may decrease you agility; what are ways to mitigate this risk? There were 4 areas of bureaucratic/non-agile areas that were addressed:
- IT Security; demands for documents, some out of nowhere, some pre-defined (example: security control matrix)
Paul plans to have a set of standard "templates" that would be filled in on this, that should reduce the time spent.
Lisamarie suggested that these either become stories or be connected to stories, which would also ensure that as a change to code that touched that touched the story the story isn't signed off until the matrix is updated. This would increase visibility and allow better estimation on these in the future. This was brilliant! (Wish I had though of it...Guess as a bureacrat, it fell out of the box of mmy thinking.)
- Budget development; budgeting far in advance for funds to be committed on projects or products that are not known or maybe only in a very general sense
Understanding estimates can help here for concepts that are bring kicked around for products or projects; obviously those that have not been hypothesized, can't be addressed.
- SDLC "Standards" group; the problem here is not that Paul's team is being affected, but frequent "accusations" occur from those that follow the standard SDLC process about the agile team not followingthem...
Paul has created a "map" between these processes, but it may not suffice; but it is more of trying to prevent interference that currently is not happening.
Mike had two suggestions: 1) follow the means of describing the risks as in the "Reinventing Project Management" book; there are four dimensions that characterize a project: complexity (technical risk), technology (task uncertainty), pace (urgency of the need), and novelty (uncertainty of the goal) - agile projects fit those with high risk and fast pace. Some details on this at the agile management BLOG 2) Follow the standard "waterfall" method if that is the general practice, but focus on setting up a sprint cadence during each phase with a deliverable product artifact and run each sprint as a sprint. As the group gets comfortable and those outside get comfortable, start combining design with requirements, then later add-in construction, and then add-in testing - at that point your agile! Mike also asked whether everyone really needed to be agile. He prompted us to ensure we didn't push agile into an organization where they actually CAN describe their requirements fully upfront, perhaps waterfall should not necessarily be abandoned in this case. There were some excellent suggestions from Tracy and Stuart on the issues that they see with their organizations and clients that they deal with as they transition.
- IT Infrastructure; folks that install and set-up test, staging, and production environments
We didn't really address this except to say we thought it just has to be something you need to plan.
I felt honoredto be there and thanks to everyone that came to my session! I got a lot out of it!
- I did bring a "brief", but it was more for referring to things if needed; we didn't need it, but here it is if you want it... ImprovingAgilityAtRuralDevelopment
Return to Sessions2008