I would love to hear the developers point of view about that. (I do not refer to the theory of 12 principles and the emphasis on individuals and interactions, and so on)
I refer to the day to day practice. I confess that I have the “project management bias”, so I would love to hear your opinion as developers(or other IT roles) about that.
¯\(ツ)/¯
Every company I’ve worked at (or interviewed with) has claimed to be “agile” and meant something different by it. I really don’t know what you might be thinking of when you say “the day to day practice”. After all, one of the strong arguments of the theory of agile development is that teams should be self-organizing and should evolve their practices to meet their own needs.
The term “agile” isn’t important to me because it means whatever management wants it to mean to sell it to the higher ups that they are doing their job (as middle management).
The times I’ve heard it are in contexts where its given more as a buzzword than anything practical. “We are doing agile”, when the project has 3 months behind, over budget with complex requirements missing, and ever increasing scope. Sure its called agile, but it doesn’t seem anything like what I’d imagine it to be.
Whatever management has in their head that is “agile” is what was deemed as “agile”. How that impacts the every day grunt that is doing the actual work doesn’t actually matter much “day to day” since the word carries no consistent meaning, or specifics.
If my concept of “agile” doesn’t match your concept of “agile” is that an issue with one of our concepts? Or is the idea that “agile” is a concrete concept in the first place the issue? If that is the case, where throwing around terms that have inconsistent meanings, then that is the core issue. How can you get your workers to know what to do if the words you tell them have an inconsistent meaning? Even if they have a consistent meaning, are they applied consistently, reliably, and supported by management? If so, then yea your doing your version of “agile”, and hopefully its actually working for you, as that isn’t always the case.
Thanks for your answer. Yeah, you are Right, sometimes is used more as a buzzword rather than a concrete methodology.
Hello, thanks for your answer. Sorry if I caused confusion with the “every day” part. What I was referring was, that, both the scrum master and the product owner have a relative perception of the importance of the methodology.
But, the opinions of the teams, could be different. (In my country for example,there are many people reluctant to adapt, or prefer to call “agile” to other things).
This topic was automatically closed 182 days after the last reply. New replies are no longer allowed.