I saw an meme awhile ago "scrum is faster smaller waterfalls, change my mind". Somehow I believe that when JIRA is leverages as the end-all source of 'done'.
Item 1 from the Agile Manifesto: "Individuals and interactions over processes and tools".
So yes, if JIRA becomes the blocker it is the anti-pattern to fluid and rapid product creation.
My new PM gets annoyed when I call it mini waterfall, but like, if I'm spending half the sprint waiting on things to get in QA, and then I get flooded with tests to write, isn't that waterfall?
Devs can pick something from next sprint to pull in and work on to be occupied, but there's only so much automation I can preplan without code in front of me feature complete from a dev. I was able for one sprint to argue that I could fix a bug as a dev before the QA flood, but that hasn't really worked since (because I don't feel like arguing for work every single sprint planning)
Do you think, getting flooded is a direct result of using Jira or is it related to the way the project is structured? Getting flooded is always a bad thing (and probably your PM should get annoyed by that), but I believe that could happen to you with any other tool.
Jira's a variable, for sure, but it's mostly management.
Mainly, Jira metrics are what run our management (actual HR managers, not PMs). Because of needing set qualitative measures to judge teams on, no one is allowed to use anything other than the Approved Jira Workflow For Scrum Teams.
My team is over 50 sprints in with a fleshed out backlog... there's no reason other than politics for why we can't go Kanban. And Kanban is pretty much the only way to stop that flood since more things can ebb and flow naturally rather than in structured time frames. The alternative would be to make stories ultra tiny to get the burndown started earlier, but that would cause a dramatic drop in effectiveness since we'd be bogged down with the process of it all.
While Jira does have Kanban boards, the concept of something not being done by the end of a sprint is too ingrained in how teams are deemed successful or not.
Yeah, the devs aren't considered responsible for having completed testing. As you say, they pull in additional work for the sprint rather than making sure the rest is DoD.
The Agile Manifesto works. All (Agile) methods/processes/frameworks do not work. The idea about he manifesto is to constantly (re)think about improving your process (read: way of working). When you adopt a process, like Scrum, and stick to it, you stop doing that. Thus, you are no longer agile.
I complete agree with you. Violation of the first principle of the Agile Manifesto happens way too often.
Too many people out there in the industry, trying to push Agile as a solution to problem X... Without understanding this first line.
It would be weird if we were invaded by buzzwords at each stratum of software development but not on the methodology level. Judging by the amount of books, courses, silver bullets, variations of agile, self anointend gurus and so on, it's perfectly understandable that meanings get lost in the process.
On this website we debate all the time about the viability of this or that approach, of this or that technology, it's not easy to debate the viability of different approaches to develope software as a whole or to manage teams only by the cover.
Ben's approach, to be always changing and refining, it's probably the most functional, but as you said, many people read an article or a book, decide it makes sense because they used it successfully in company X and then use Agile as a hammer. Kinda like some devs use microservices as a hammer because they used them successfully at Netflix ;-)
I'm guilty of using my favorite programming language as a hammer in the past.
This "agile confusion" we're in is understandable and Jira's complexity doesn't help.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I saw an meme awhile ago "scrum is faster smaller waterfalls, change my mind". Somehow I believe that when JIRA is leverages as the end-all source of 'done'.
Item 1 from the Agile Manifesto: "Individuals and interactions over processes and tools".
So yes, if JIRA becomes the blocker it is the anti-pattern to fluid and rapid product creation.
My new PM gets annoyed when I call it mini waterfall, but like, if I'm spending half the sprint waiting on things to get in QA, and then I get flooded with tests to write, isn't that waterfall?
Devs can pick something from next sprint to pull in and work on to be occupied, but there's only so much automation I can preplan without code in front of me feature complete from a dev. I was able for one sprint to argue that I could fix a bug as a dev before the QA flood, but that hasn't really worked since (because I don't feel like arguing for work every single sprint planning)
Do you think, getting flooded is a direct result of using Jira or is it related to the way the project is structured? Getting flooded is always a bad thing (and probably your PM should get annoyed by that), but I believe that could happen to you with any other tool.
Jira's a variable, for sure, but it's mostly management.
Mainly, Jira metrics are what run our management (actual HR managers, not PMs). Because of needing set qualitative measures to judge teams on, no one is allowed to use anything other than the Approved Jira Workflow For Scrum Teams.
My team is over 50 sprints in with a fleshed out backlog... there's no reason other than politics for why we can't go Kanban. And Kanban is pretty much the only way to stop that flood since more things can ebb and flow naturally rather than in structured time frames. The alternative would be to make stories ultra tiny to get the burndown started earlier, but that would cause a dramatic drop in effectiveness since we'd be bogged down with the process of it all.
While Jira does have Kanban boards, the concept of something not being done by the end of a sprint is too ingrained in how teams are deemed successful or not.
Yeah, the devs aren't considered responsible for having completed testing. As you say, they pull in additional work for the sprint rather than making sure the rest is DoD.
Im constantly sadden by
Too many people out there in the industry, trying to push Agile as a solution to problem X... Without understanding this first line.
The end result is many projects being, agile in name only.
And unfortunately with my very terribly small dataset of personal experience. This correlates strongly to those who insist on JIRA being the answer.
The Agile Manifesto works. All (Agile) methods/processes/frameworks do not work. The idea about he manifesto is to constantly (re)think about improving your process (read: way of working). When you adopt a process, like Scrum, and stick to it, you stop doing that. Thus, you are no longer agile.
I complete agree with you. Violation of the first principle of the Agile Manifesto happens way too often.
It would be weird if we were invaded by buzzwords at each stratum of software development but not on the methodology level. Judging by the amount of books, courses, silver bullets, variations of agile, self anointend gurus and so on, it's perfectly understandable that meanings get lost in the process.
On this website we debate all the time about the viability of this or that approach, of this or that technology, it's not easy to debate the viability of different approaches to develope software as a whole or to manage teams only by the cover.
Ben's approach, to be always changing and refining, it's probably the most functional, but as you said, many people read an article or a book, decide it makes sense because they used it successfully in company X and then use Agile as a hammer. Kinda like some devs use microservices as a hammer because they used them successfully at Netflix ;-)
I'm guilty of using my favorite programming language as a hammer in the past.
This "agile confusion" we're in is understandable and Jira's complexity doesn't help.