I see no indication that agile is dying. The consultant speak cult that developed around it is. The hugely processed SCRUM version of it seems to be. Yet the fundamental idea behind Agile (in the manifesto) seems to be as relevant as ever:
>Individuals and interactions over processes and tools
>Working software over comprehensive documentation
>Customer collaboration over contract negotiation
>Responding to change over following a plan
The process we've designed and use daily at Gridium most definitely adheres to those principles. We've tested and abandoned the idea of "sprints" and weekly estimation cycles. We have no idea what our "velocity" is.
Yet we collaborate with customers nearly constantly. We are highly responsive to changes in the business. We integrate continuously. We deploy very often. All ideas that I think where present when we all fell in love with the idea of "agile".
* Edit: Shame on me for not reading the article, because I basically summarized it :) Heap your downvotes on me HN!
Yep. If people checked their actions against the agile manifesto they would immediately see that most scrum teams violate "Individuals and interactions over processes and tools" and "Responding to change over following a plan". A lot of scrum teams I see are fully process and tool oriented and have no ability to respond to change. I hate when I hear "Yes you are right but we can't make changes because the sprint would not finish".
I also have given up on fixed sprints for my (not anymore) scrum team. We have a prioritized backlog and whatever is next gets done. More like Kanban. As long as people behave like adults and do their work efficiently it works pretty well. We still have a weekly velocity and that number is surprisingly reliable.
The daily standup ("scrum") did make some sense in the context of agile development. The idea is that you embrace the unpredictability of software and respond to change. So you take on a task, but you accept that the task is likely to not go as you expected. You may need to change direction. You may need to take a different approach. Or you may need 10 weeks instead of 1, and even that is getting fuzzy… under these circumstances, it can be useful to remain in frequent contact with the development team and business/end users users.
But as you pointed out, daily scrums can essentially devolve into what is essentially a policing of developers to make sure they are staying the course and are reminded daily of their deadlines.
It's actually just an unusually unfriendly version of waterfall. Why? Cause at least in waterfall, the business users are forced into something unfair and impossible as well. It's impossible for developers to accurately estimate completion dates, but it's also impossible for business units to accurately and fully spec out a software application. "You didn't meet your estimate"... "Yeah, well, you changed your mind".
It's a nasty business, but there you go. Best to avoid the entire thing and work on projects that are very high value but aren't deadline dependent, where the value of a developer is measured by working software at reasonable intervals rather than daily discussions of sprints, stories, and deadlines.
Actually, in some ways, that sounds more like what agile is supposed to be than all this scrum/velocity/stories stuff that isn't in the manifesto in the first place.
>Yes you are right but we can't make changes because the sprint would not finish".
That makes absolutely no sense because the sprint always finishes, on a scale far basis.
The only way to make a sprint not finish is to submit code that cannot be safely deployed, and that is a bug in the code, nothing to do with changes in plan.
>Individuals and interactions over processes and tools
>Working software over comprehensive documentation
>Customer collaboration over contract negotiation
>Responding to change over following a plan
The process we've designed and use daily at Gridium most definitely adheres to those principles. We've tested and abandoned the idea of "sprints" and weekly estimation cycles. We have no idea what our "velocity" is.
Yet we collaborate with customers nearly constantly. We are highly responsive to changes in the business. We integrate continuously. We deploy very often. All ideas that I think where present when we all fell in love with the idea of "agile".
* Edit: Shame on me for not reading the article, because I basically summarized it :) Heap your downvotes on me HN!