Interesting article, and I would agree with some of the benefits described in it but still think its important for there to be some meetings.
I have had a mixed experience with Agile. In the past I worked for an employer who was very over the top with Agile and so much time of every week was spent on the PROCESS of agile rather than actually DOING the work. As such projects would take ages, often meandering along for years.
The best project I have ever worked on was run with an "Agile Light" philosophy (as the project manager would describe it) where we did not have stand ups every day, and only had 1 retro at the end of the project. We were encouraged to work collaboratively together to solve problems as they arose, which really helped the flow of the development of the project.
The project manager would visit the people on the project individually each day or 2 to check if any blockers or issues and take care of them, but otherwise mostly left the developers (and others) to get on with the work planned for the sprint.
This involved some degree of trust and self responsibility to raise any issues with the project manager that they needed to know about, and actually get on and do the work.
Every week we would have a meeting with the client to report on progress, show and tell, and discuss larger topics or issues. Day to day we were allowed direct contact with the client - via email or slack - to ask smaller questions, technical things etc as the need arose which again helped with the flow of development.
Also we did not bother with a physical Kanban board with tickets. We found using our online user story ticketing system much better to track planned work for the sprint, the status of stories, etc was much better as all staff no matter where they were located - and even the client - could access it and see the current state of things.
The question I would propose to people reading this is: how much of your project's time and budget would you rather spend on development than meetings, arranging tickets on a board, retros, and other aspects of the agile process?
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.
Interesting article, and I would agree with some of the benefits described in it but still think its important for there to be some meetings.
I have had a mixed experience with Agile. In the past I worked for an employer who was very over the top with Agile and so much time of every week was spent on the PROCESS of agile rather than actually DOING the work. As such projects would take ages, often meandering along for years.
The best project I have ever worked on was run with an "Agile Light" philosophy (as the project manager would describe it) where we did not have stand ups every day, and only had 1 retro at the end of the project. We were encouraged to work collaboratively together to solve problems as they arose, which really helped the flow of the development of the project.
The project manager would visit the people on the project individually each day or 2 to check if any blockers or issues and take care of them, but otherwise mostly left the developers (and others) to get on with the work planned for the sprint.
This involved some degree of trust and self responsibility to raise any issues with the project manager that they needed to know about, and actually get on and do the work.
Every week we would have a meeting with the client to report on progress, show and tell, and discuss larger topics or issues. Day to day we were allowed direct contact with the client - via email or slack - to ask smaller questions, technical things etc as the need arose which again helped with the flow of development.
Also we did not bother with a physical Kanban board with tickets. We found using our online user story ticketing system much better to track planned work for the sprint, the status of stories, etc was much better as all staff no matter where they were located - and even the client - could access it and see the current state of things.
The question I would propose to people reading this is: how much of your project's time and budget would you rather spend on development than meetings, arranging tickets on a board, retros, and other aspects of the agile process?