애자일 "방법론"이라는 것은 생각해 보면 오히려 비즈니스 사이드에서 요청하기 더 좋은, 또 적용하고 싶은 개발 방법론일 수 있다고 생각한다. 뭔가 좋은 회사라면 당연히 이렇게 일할 것 같다는 느낌이 나기도 하고, 독특할 것 같아서도 있지만,  "그래서 언제까지 되는데?"를 잘못된 스토리 포인트 산정 방법을 통해서 통제를 하려 하고, 그때까지 수행하지 못한 팀에 책임을 전가하고 비난할 수 있는 도구가 될 수 있기 때문에.

 IT, Product Management, Agile, Scrum, Kanban, Waterfall, 등등등 방법론과 수행과정에 대한 수많은 도서들과 글들이 생산되고 소비되는 이유는, 그만큼 다양한 IT 프로덕트/ 프로젝트들이 생겨나고 있다는 뜻이고, 많은 사람들이 시작할 때 생각한 만큼 원하는 것들을 달성하지 못하고 있다고 생각하고 있다는 뜻이라고 생각한다.
하지만, 방법론과 적용방법에 관한 도서들이 많아지고 글들이 많아질수록, "본질"을 찾아가기보단 "누군 이렇게만 했는데 안 밀리고 잘되었다고 하더라"에 집중하게 되는 것 같아 마치 미취학 아동들에게 전기톱을 쥐어준 것 같은 불안감을 느끼기도 한다.

https://brunch.co.kr/@tsp/41