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.
A better analogy, is that some of the more advanced examples have "sublimed" as in Iain M. Bank's "Culture" series.
I was just having this thought last night. "eXtreme Programming" and Scrum seem to either exist in a clunky bureaucratic mutant form or have evolved into companies that use CI and prioritize really good communication. (Yes, people in the late 90's and early 00's did sometimes write it like that.)
Great Questions. This is a huge paradigm shift that will cause a ton of growing pains for the tech industry and governments. A simple case study would that of Uber and their adoption of non-government based background checks. Is it in our best interest for the government to perform the background checks for drivers? Who knows...but problems like these need answers.
When people say IFTTT, are they referring to the company or to the verbs which they actually represent? (just curious) I feel like the 'If This Then That' paradigm has been around for a long time, while the company which adopted the phrase has not been around so long.
Good intentions, but the visualizations don't work for me (I get Invalid Date errors) and I find the analysis to be shallow. If the amount of data which they say was collected, was actually collected, I think that this dataset deserves a much deeper dive.
Thank you! It is blocked by uBlock Origin as well. So if you are seeing the article but without any visualizations check your ad blocker. Definitely not a good sign for a startup.
Edit: Also, they claim insights about what influences productivity. However the visualizations shown (after you disable adblocking) do not reflect the claimed insights.
Edit2: Downvote this all you want. I assume you have a personal stake, and I doubt you will make it disappear -- they are valid criticisms. Maybe responding would be more constructive.
Edit3: Hey Colby, thanks for responding (can't respond directly). Turning uBlock off and reloading may have been coincident with visualization showing back up. Maybe overtaxed servers with the front page HN spot? (Congrats btw).
I have nothing to do with this startup but from your comments I don't think you read the article very carefully. Also it's unfair to blame them for what your browser plugins did.
uBlock Origin ("uBO") isn't blocking the visualisations on that page. The only way I could reproduce such issue is by blocking 1st-party scripts, definitely not a default settings in uBO.
