Agile is Dead
linkedin.com
linkedin.com
> If I were king, I would prefer to see a methodology using the (ISC)2 recommended practices in the SDLC, and the emerging OWASP practices, with more certifications like the CSSLP.
The author apparently calls himself an "Enterprise Architecture Evangelist MSEA BSEE CEA³ CISSP-ISSAP PMP ITIL"
I've got to chuckle. What does any of this even mean? And what does it have to do with writing good software?
edit: Perhaps it is a certified enterprise architect "black belt" such and such from:
https://www.feacinstitute.org/feac-courses
Looks like all you need is 11K and 14-16 hours:
http://www.tomsitpro.com/articles/enterprise-architect-certi...
It has nothing do with writing good software. I've seen these sprinkled about on titles before and I've just rolled my eyes in the past and will continue to do so in the future.
"And, unfortunately, I think time has proven me right. The word “agile” has been subverted to the point where it is effectively meaningless, and what passes for an agile community seems to be largely an arena for consultants and vendors to hawk services and products." (https://pragdave.me/blog/2014/03/04/time-to-kill-agile/)
"Doing the right thing at any time" is still a perfectly valid principle, though.
MSEA - Maryland State Education Association BSEE - Bureau of Safety and Environmental Enforcement CEA3 - Clean energy associates CISSP-ISSAP - CISSP-Information Systems Security Architecture Professional PMP - Project Management Professional ITIL -Information Technology Infrastructure Library
Those got less interesting as I went on. :/
His title reads like a shitty craigslist posting
For sale - 92 Toyota Corolla $100000
TOYOTA COROLLA ACURA HONDA FORD CORVETTE CHEVROLET DATSUN...
And the best part is, you can access his slides later. Through an OWASP and OASIS-approved highly-scalable and enterprise-y SOAP API which is extremely easy to consume, as long as you use his Enterprise Scalability Patterns Application Block (it's well-documnented in his 890-page book, which is a must-buy).
In other words, if your process involves predicting time needed to complete a project, you've already failed.
The difference was that in construction, the same subprojects have to be done over and over again, so subcontractors can easily be given and held to realistic deadlines, and your only bloat comes from the usual hiccups. On the other hand software engineers _by definition_ estimate things they've never built before. If they've already built it, they can just port it over and start working on something new.
Combine that with everyone's tendency to underestimate, inability to determine unknown unknowns, and the usual hiccups, and we're left with the usual refrain: accurate software estimation is basically impossible.
1 - You can fix the time or the scope of the project, but not both. I can say, "I will deliver project X in 4 months" but you have to be willing to let me toss out scope, and the earlier the better. This does work. Just like I can say, "I will promise to deliver all the scope in project X, I just can't promise how long it will take." Agile helps break this into smaller chunks, and allows you to get more visibility into what's realistic more quickly. I've seen too many waterfall projects slip by 3-6 months at a time only when the final deadline approaches.
2 - I've seen more projects slip because of "Unplanned work" and "Missed Dependencies" than due to "Misestimated work". It's either scope creep, or "I didn't realize we needed to test integration" or "Person X didn't give me what I needed." The only counter-examples I've seen are when engineers aren't consulted in the estimates.
Sounds like the Cone of Uncertainty:
Agile is a phenomenon with lots of different manifestations that try to do their best at embracing the Agile Manifesto. Yes there is hype and people who make money of it. But that hype is justified by many examples of successful Agile manifestations.
Most important to Agile is to get it. To get into the mindset of feedback loops and collaboration. For larger companies with "non-Agile" habits, that is hard by default.
I however hope 'agile' as a spirit of talking to your users, breaking down tasks into bite size deliverables, testing, and making sure things move in a generally agreeable direction, well, I hope that persists and flourishes.
Go back to W. Edwards Deming—understand your customers, understand your company and your people, manage with respect and based on science and psychology, and base decisions on the reality of your systems and customers, rather than fantasy goals or objectives.
If you ask around, you'll notice that (many|most) people equate "agile" with "two week sprints". But if you actually read the Agile Manifesto you find this:
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
Agile does not dictate that you use two week sprints. In fact, th term "sprint" itself is not even part of agile! The term "sprint" comes from Scrum, which is simply one specific methodology which claims adherence to the agile philosophy. But Scrum != Agile. Agile can also be XP, Crystal Clear, or AUP, etc.
The problem is that Scrum "sprints" are like treating a marathon as 422 contiguous 100m dashes.
Yep. Or to put it another way, too many shops seem to think that you can "sprint" ALL THE TIME. And while it's "only a metaphor", it's a meaningful one in this case. You can't:
sprint -> sprint -> sprint -> sprint -> sprint -> sprint -> ∞
sprint -> sprint -> breather -> sprint -> breather -> sprint -> sprint -> breather -> ∞
Replace sprint with time segment. And you get more accurate picture.
Except when they are. And just using that term encourages people to treat them like actual sprints, instead of just metaphorical sprints. This is why I advocate for use of the term "iteration" instead. But even then, I think it's important to include "slack" iterations that are for random bug fixes, miscellaneous refactoring, etc., that is developer driven, not business user driven.
Ok. I listen. What is it wrong with it ? Then there is an endless list of links. I don't even know where to start. Impossible to argue against that. But I still don't understand what the author meant.
So. If we just stick to the agile manifesto. Is there something wrong with it ?
The worst part is that there is no proposed alternative. I kind of get the idea that the author still thinks big upfront design is the way to go. If he believes agile is no better than Waterfall. I can't agree with that. I would hate to go back to that.
Manifesto for Agile Software Development
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value
Individuals and interaction over process and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan
That is, while there is value in items on the right, we value the items on the left more.
Also, he clearly never learned the secret sauce of "agile" that Scrum and modern proponents only pay lip service to because it doesn't "sell well": Fucking. Technical. Practices. I've spent over a dozen years now on teams that focused on a.) pair programming b.) test coverage and testability c.) CI (actual CI on one branch - not GitFlow B.S.) and d.) Close customer involvement. We shipped high quality, low bug software that made money for the businesses. Teams that fail to learn technical excellence leave 75% of the value of "agile" on the table, and 9 times out of 10 it's the fools in suits that won't 'let' them do it.
As far as I'm concerned, big organizations can go to hell & keep failing over and over. As software becomes more powerful, 'we' don't need them: http://allankelly.blogspot.com/2015/10/software-has-disecono...
Software is and ever was product of art and skill. There are great ways to improve productivity, for instance I really like how kanban fits software development. On the other hand, using Scrum and sprints and what not is how non-tech HR person explains to the non-tech management how software should be developed.
Our standups lasted minimum 1 hour every day. Every Thursday we had a show-and-tell meeting, which meant going through everything we worked on and fixed (some of these meetings lasted 3 hours) and we also had a pre-planning and post-planning scrum meeting, each lasting 3 hours.
At one point I was charging the company more for meetings than actual work (it was 70/30 meetings to work).
I finally left when we added another 1-hour meeting on Fridays where we would just tell a joke, funny story, or something about our life. Since the majority of other contractors/developers on the team were from other countries (and didn't speak English very well), it was one of the most awkward situations I've ever encountered at work.
In contrast, I've been part of agile teams where we were from three different timezones, had short standups (sometimes multiple times a day depending upon the need), and focused on delivering value.
DevOps is about eliminating the decades-old division between development staff who control the programs and operations staff who control the data. By having "DevOps" staff who control both programs and data, businesses open themselves up to large-scale employee theft and fraud.
For software, that means delivering high value, high quality working software quickly and frequently. One needs the fundamentals of short feedback loops, the ability and willingness to inspect and adapt, and collaboration and teamwork. Everything else - training, release planning, standups, story card walls, iterations - is all just the ceremonies and techniques that support these fundamentals.
It's a marketing term. It's the place in the bookstore you go to buy books about cool stuff technology teams are doing nowadays.
If I want science fiction, I go to the science fiction aisle. If all the science fiction sucks this week, I either buy something else or wait until next week. I've already established that I like reading science fiction.
If I'm consuming material titled "Agile" that doesn't seem to work, or seems like a scam? I stop consuming that material. More will be along later.
And just like in books, many times you have to take the book home and try it out to see if it works for you.
I think there are some people who really, really, really want a magic bullet. They want an answer to life, the universe, and everything. And in so many fields, that just doesn't exist. These are some of the same people, by the way, who make Agile so terrible for everybody else. You gotta dial back the feverish adopter thing, whether you're for or against Agile, to make any progress in your career.
Open floor plans are not a requirement of "agile". That people think this, is evidence of the real problem here: hucksters have been selling something else, but using the word "agile" to promote it. If one wants to argue that the term "agile" is dead, then maybe one has a point. But I'll argue that the essence of agile is just as sound as it ever was, it's just that we let the term get misappropriated. How to proceed from here is an open question...
I don't see it quite that way. Services business work in our economy, but if you're doing something on a services basis, you have to understand the implications of that and how to manage them. There are all sorts of services in our economy that work (mostly) fine today.
To illustrate what I mean, let me use an example.. if you take your car in to a shop for repairs, you expect an estimate, and you aren't necessarily pissed if the final tally is off the estimate by a bit. But you will be royally pissed if it's off by an order of magnitude or more.
So, do software projects sometimes cost (in time, money, both, etc.) an order of magnitude more than estimated? Yeah, I'd say so. But here's the rub... are car mechanics better at estimating than software developers? Not necessarily, but their customer doesn't typically come along when the project is half done, and yank the rug out from under them and ask for something that negates half the work they've already done.
"Yeah, about replacing that spun bearing...I don't really want that, just replace the fuel injectors instead".
Nope. Doesn't happen. But I'll argue that the equivalent does happen in our world.
Of course the Agile Manifesto is all about the idea of embracing change, and accepting change even late in the process. So we have to accept that and deal with it. But the rub here is that we have do so in a way that doesn't come across to the customer as an order of magnitude failure.
This is one place where I think we, as an industry, kinda fell on our swords. WE understand agile, but we didn't always educate the customer on what agile meant. And we didn't do a very good job of communicating to the customer what the impact of their change in requirements is. We accept changing requirements, yes... but we haven't always made it absolutely clear to the business customer that "making this change is the equivalent of asking the auto mechanic to replace the fuel injectors instead of fixing the bearing. This is throwing out all the work we've already done, and we need to re-estimate everything now."
Is it because IT people lack the nerve to push back when business users make huge demands? Or something else? I don't know, but over the years I've become convinced this is a big part of the problem. We let the users change things (which they have the right to do), but we don't make damn sure they understand the implications of what they're asking for, and update the estimate/plan/etc. to reflect the new reality.
Right and this why I say that so many people are (intentionally or not) misunderstanding what "agile" means, and selling something else using that label. Look at what the Agile Manifesto actually says about plans / planning and what not:
Through this work we have come to value:
...
Responding to change over following a plan
...
That is, while there is value in the items on
the right, we value the items on the left more
If "agile has failed" is really true, then here's the one place where it probably failed: It was never prescriptive enough. Which might seem paradoxical, but the problem is, the AM is subjective enough that people could find justification for whatever bullshit ideas they came up with, in the Manifesto. :-(
It may be that agile is just not appropriate for such projects, in which case I wish companies and customers would stop trying to force-fit them.
The thing is, a certain measure of "change control" was always a good idea, even in an "agile" environment. My (admittedly subjective) take is that getting away from change control contributed to everyone's mindset shifting to where "changes are free".
Keep doing the parts of it that work for you. If parts of it don't work for you, change them or drop them. (Part of the agile philosophy is that you can hack your process.)
We may need to drop the word "agile". But if the mindset leads to you practices that are helpful, use them.
When others ran the stand-ups, they tended to let people ramble more, and they were more painful. I did my best not to step in and corral the situation, but I still often ended up asking the appropriate question.
My meetings went the same way, with a focus on getting things done so we could all go back to our desks. We socialized plenty from our desks and other times, and there was no need to drag out meetings.
I was thanked for my efforts numerous times, and I tried to be aware of any discord that was created, so I'm fairly sure I wasn't making enemies by doing it.
My point is that standups don't have to suck, but someone has to keep them on track. That's what the standup leader is supposed to be doing anyhow.
I'd love to hear some examples here, maybe a snippet of one of your stand-ups.
The essential purpose of a standup is to make sure everyone knows what everyone else is working on, to identify any potential blockers early, and to get the right people collaborating offline to work out details. It really doesn't take very long to say this: "ComponentX, componentY; Blocked on componentZ; need to talk to Bob and Sue afterwards" is fine.
I know I personally can't get started on things right away in the morning because of the psychic weight standups carry. I can't get focused because in the back of my mind I know I'm going to get interrupted soon for a meeting that mostly has little relevance to me.
Also, there's nothing that says that standups have to be in the morning. Most of the teams I've worked on actually had theirs either right after lunch or mid-afternoon. That accommodated those of us who were late-risers, it let the early-risers get some work in in the morning, and it meant that it'd often fall during food coma or when energy levels hit a mid-afternoon nadir.
I felt the same way. And now after a few years of open floor plans, I actually love them. Sure there are some drawbacks: noise can increase, and certainly there are more distractions, but there are many benefits. Communication is easier. That feeling of isolation is gone. The group feels more cohesive. I think the only modification that could be made would be to create more isolated areas off to the side either for individual work or team meetings. And companies are doing that, although the private areas are moreso for meetings. But I hear that some are even making smaller areas just for individuals who need a few hours to focus on one task.
> Code quality suffered because of the constant pressure to get things done now
It takes some wisdom for managers to be able to properly apply Agile principles. Pressuring devs to spit something out without properly designing it is poor management practice. Its common, yes, but its still wrong. That's why Agile suggests a fairly wide range of time to deliver software (from two weeks to two months). Every piece of software is different, and it takes good people to determine the correct balance between release frequency and development time. You should prefer to release frequently, but if you're releasing garbage then what's the point?
Not because those terms mean anything even remotely bad (in fact, he agrees with a lot of the philosophies), but because those terms come pre-loaded with a lot of baggage and preconceived notions by management, and saying that we have an agile-like process is just begging for some C-level with not enough work to do, to get involved and begin dictating requirements they don't understand.
I doubted this until I saw it happen personally a couple of times.
The process is completely, totally meaningless (and in many cases actively harmful), unless you also get the culture change to go with it.
Agile is what you make of it. The biggest thing holding back a "by the book" agile scrum implementation at enterprises is budgetary process. Business people, who own budgets, have an extremely hard time understanding why they can't build X for $Y, because there are few agile processes that help them clarify that.
I've never been an an AGILE project where architects and managers followed through with designs or documentations. The halfway through the sprint you'll get clarifications of specs if you're luckly. Something needs to be redesigned? too late, you're doing another sprint next week.
People buy cheap outsourced development written to spec. People say they want all the benefits of agile but that means embracing risk in order to access the potential of their coders in a real agile management environment. In fact they are happier missing out on a great implementation if it is cheap and timely.
So there is a lot of agile bullshit out there, looking agile-ish but really being paranoid micromanagement by cheapskate philistines making crap software, managed on kanban boards by people with certifications.
Real agile is hard. Maybe impossible for most projects. But being fake agile avoids grappling with the hard problem of how to get the most out of your software development with the resources you have.
It works well when you can control or bound the expectations of your users. Delivering a gradually-expanding customer self-service portal, for example, is a perfect candidate for agile processes.
However, it doesn't work when the requirements are legal or financial compliance. There is seldom an opportunity to iterate and improve, it needs to be done once and fully by the go-live date. You can't release a small part of a compliance project ahead of schedule because, well, it wouldn't be compliant... Date-bounding makes-up a large proportion of enterprise business logic for this reason.
Counter-intuitively a large enterprise actually needs to be more flexible in its project management and methodology than a small, "agile" start-up. Deploy whichever technique is appropriate for the task, which means you have to have adaptable staff.
Source: having worked for a Fortune 100 that was agile-ising.
In the legal/financial compliance zone, it's probably about "here are the things we need to get done for this aspect of compliance," and then just doing them.
We're saying the same things, yeah?
Anyone that lists under certifications...
'Winter Survival, Civil Air Patrol, Starting 1974'
'22% raise in one year, CDC'
I think this guy isn't a developer, and fetishes over planning and really process driven development.
72 hours ago there was "The Lie That Has Beguiled A Generation Of Developers" (https://www.linkedin.com/pulse/lie-has-beguiled-generation-d...), and now there's this.
I can't wait to see what's next. Maybe "The End of Programming".
Now I know what blogs are just sensational twaddle.
But the web is much more accessible to the average user, there's a reason that there's been so much success with JS front-end apps. Sure they aren't as quick and streamlined as their native counterparts, but where cutting-edge performance isn't required I think it's a pretty good option.