3 ms·

Agile Manifesto (http://www.agilemanifesto.org/principles.html http://www.agilemanifesto.org/principles.html): >I did not do Sprint planning meeting and ticket

Agile Manifesto (http://www.agilemanifesto.org/principles.html http://www.agilemanifesto.org/principles.html): >I did not do Sprint planning meeting and ticket estimation (Agile poker cards) because people on my team loved to argue over minutiae's and I strongly suspected half of the team didn't know the details of what the other half is working on; So instead, we had a weekly "flowchart" meeting on a large whiteboard where we brainstormed and added more details to our software project (a big data pipeline lends itself to a flowchart); I found it to be a better visualization of the project than a post-it covered poster. Principle #5: Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. > The crux of the argument was Agile wasn't well suited for our team; the sprint model of Agile easily lends itself to arbitrary deadlines and building for the "demo" of the story/epic of that sprint and build-up of tech-debt Principle #7: Working software is the primary measure of progress >In the end, management relented and we ended our Agile experiment. Project tracking is done in Google Doc's with milestones instead Principle #12: At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. Presuming that you're delivering more responsively and quickly to the customer than you were before, which you didn't mention, it sounds like you're doing just fine with Agile.

noname123 11y ago
Thanks lr4444lr for highlighting and aligning the various principles the Agile manifesto with the minutiae details of the project I described. I definitely see your point (which I interpret as Agile is not a set of rigid techniques but one can adapt a team's makeup and culture to whatever will make software people feel motivated/empowered to do the work and have quick responsive/iterative cycles with the customer folks). >Presuming that you're delivering more responsively and quickly to the customer than you were before, which you didn't mention In the interest of full disclosure, I think we had a project time over-run of 2x (estimated 4 months to 8 months) mainly due to "feature creep" (is that a feature or a bug in Agile iterative cycles?); the project is a high-throughput data pipeline for genome sequencing and annotation. We overran time as a case of our customers/users wanted to add more bells and whistles to the tail end of the pipeline as they saw the end product more and more and proposed more added steps.
- nl 11y ago
  In the interest of full disclosure, I think we had a project time over-run of 2x (estimated 4 months to 8 months) mainly due to "feature creep" (is that a feature or a bug in Agile iterative cycles?) That's a sign of weak leadership by whoever was leading the project. New feature requests will always come. Agile is about prioritizing them compared to what is already in the backlog.

noname123 11y ago

Thanks lr4444lr for highlighting and aligning the various principles the Agile manifesto with the minutiae details of the project I described. I definitely see your point (which I interpret as Agile is not a set of rigid techniques but one can adapt a team's makeup and culture to whatever will make software people feel motivated/empowered to do the work and have quick responsive/iterative cycles with the customer folks). >Presuming that you're delivering more responsively and quickly to the customer than you were before, which you didn't mention In the interest of full disclosure, I think we had a project time over-run of 2x (estimated 4 months to 8 months) mainly due to "feature creep" (is that a feature or a bug in Agile iterative cycles?); the project is a high-throughput data pipeline for genome sequencing and annotation. We overran time as a case of our customers/users wanted to add more bells and whistles to the tail end of the pipeline as they saw the end product more and more and proposed more added steps.

nl 11y ago
In the interest of full disclosure, I think we had a project time over-run of 2x (estimated 4 months to 8 months) mainly due to "feature creep" (is that a feature or a bug in Agile iterative cycles?) That's a sign of weak leadership by whoever was leading the project. New feature requests will always come. Agile is about prioritizing them compared to what is already in the backlog.