Here is a little ironic reflection on the 12 principles of Agile Manifesto. Scroll to the end of the page to read serious content.
Maki...
For further actions, you may consider blocking this person and/or reporting abuse
I enjoyed this read a lot.
Without taking anything away, the moment you have a project manager - this is not agile.
If you have predefined scope+time - you are not agile.
Agile works great if it is your product and your production, owned by the dev team.
Once you have the mess of project based work, you're better off with other methodologies.
And soft project managers should switch to a different career. Nothing costs a company more money than a project manager who wants to please a client. Disclosure: I was one, but I played hardball.
I agree that Agile has its place, but it has certainly always struck me as the manifest idealism of starry-eyed business majors. It would be amazing, if it weren't for the fundamental problem that destroys every well-meaning methodology in this industry: software is weird.
I would disagree on several levels. First of all, people are wierd too. Second of all, agile actually embraces the wierdness of both software and people. With the right mindset it is very functional and sets up very nice environment to work in.
Without dedication and understanding, it sets up a very frustrating and unproductive environment.
In fact, the methodology that embodied the "starry-eyed idealism of business majors" was Waterfall/SDLC. Imagine believing that business wonks could sit in a room and define every aspect of a huge, six-month development effort down to the user interface and then predict (with the accuracy of a train schedule) when each component and feature would be delivered. Now that's a fantasy.
By comparison, Agile is a steely-eyed practical acknowledgement that software is weirdly fluid, always in negotiation and what the client wants delivered is not 500 features a year from now but 2 or 3 features that are most important right now with promise of more in the future.
That said, all the sarcastic bits in this article are sadly funny and true. Those really are the many ways that Agile gets corrupted by management and developers. The worst of these (by far) is turning Agile into Waterfall Lite where the six-month or year-long Death Marches of Waterfall are replaced with 3-week-long Death Sprints masquerading as Agile. Forget that noise.
So, please, anyone who wants to run down Agile or has only experienced bad Agile, you simply have no idea how horrible what came before was. By all means, let's criticize and critique Agile if it leads to something better. Until then, I'll continue to believe in the overwhelmingly positive and productive Agile workflow I've seen work in the real world with real developers even in tough environments.
I think that waterfall done right is far better than agile done right. You need to have an architectural design. You need to plan things. Agile is far too seat of the pants to be effective. Especially when it comes to long-lived legacy applications. Nowadays we write software and it's thrown away a few years later to be rewritten or refactored or some other BS and this just hasn't been the case in the past. there's been a lot of really good systems created with the waterfall methodology and as I said by and large I believe it is the better of the two paradigms
Well, no, I don't know that I can agree here. Agile and Waterfall are both vulnerable to the strange phenomena that plague software development. There are many effectively implemented Agile projects, whether fully or partially compliant with the standard. There are also a number of effective waterfall projects.
One must remember that Agile attempted to answer real problems with waterfall, and it partly succeeded. Managers have always been fairly obsessed with ROI, so they're not going to repeatedly sink time and money into Agile processes instead of the much cheaper waterfall processes if they're not getting something out of it.
Like I said originally...
I think the bigger mistake is to believe that one methodology is inherently "better" than the other, or somehow less prone to failure. Own what works for you and your projects as your personal experience, but don't map that experience to the rest of the industry.
This is what I meant by "the manifest idealism of starry-eyed business majors"; they assumed that, because they could see it working in their minds, it could never fail. Does it work sometimes? Definitely. Does it work enough to warrant learning it and considering it a viable option? No doubt. Is it the answer to All Things, Even World Peace? Not by a longshot.
Waterfall is never done right, though. It assumes infinite foresight and precision planning that must never fail or falter.
Who says Agile done right includes no planning? As an organization, you still need to do requirements analysis and prioritization, only Agile gives you permission to continually reassess and adapt to changing goals and market conditions without calling that a failure.
Finally, "Nowadays ... we write software and it's thrown away ... rewritten or refactored." Heck, yeah! That's a feature not a bug. Not only do requirements change and new technologies come along but the truest statement I know in software is "Good software is written. Great software is re-written." Once you've used software in production for a while, why wouldn't it make infinite sense to eventually rewrite parts that aren't working well and hone and expand parts that are proving indispensable? Best of all, Agile plus Continuous Integration lets you "improve in-place", A-B test and innovate in a way that Waterfall could never do without shutting down the whole assembly line and waiting for the organization to gear up for the next big push.
Once again, I must disagree. If this were the case, we would have never shipped a single usable software project prior to the invention of Agile. In fact, not only was software shipped, but some of that same software is still in use, and sometimes is more stable and reliable than some of its modern equivalents. So, Waterfall cannot be unilaterally altogether incompatible with completing a project.
The way it is usually done, yes. Waterfall has issues, many of which Agile attempted to address.
That said, I've seen many of the same assumptions and mistakes made with Agile.
In reality: both methods would theoretically work well, but for human folly. I've used both successfully, and (more often), I've cherry-picked from both techniques (and others besides) to tailor the exact methodology needed for a single project.
When it comes to methodologies, anytime anyone says "X always works" or "X never works", that demonstrates they have failed to understand the vast majority of components in the problem they're trying to solve. (That's not a personal attack; I just find that to be universally true.)
I agree with you 100%. Anytime that process becomes the most important thing there's an issue. Also I think the other problem is that there are far too many people with one two or three years experience that buy into this and become scrum masters or some other BS term and destroy an entire dev team because they are in no way qualified to discuss anything related to it and should remain relatively silent and continue to develop their technical ability
Except Agile Manifest was written by Software developers. They saw the multiple layers of translation by business people as inefficient and error prone compared to speakind directly with the customer
This article is a great way to get people to actually read the Agile 12 steps (erm, ...principles). Far too often I come across some team or company that claims to be 'Agile' without having any idea or opinion of what Agile concepts are. In other words, of all of the people that I've interacted with who claim to be 'using Agile' I'd guess only 30% of them have actually read the principles much less the entire document.
I think you are spot on with your assessment of the motivation of employees in general: some are 'all in' for improving the product/business/workplace/etc. while most really just want a paycheck -and that this is not a bad thing. While some people are comfortable with autonomy in the workplace, most are not (IMHO). In my experience most people want to have clear, specific, guidelines and procedures to follow in order to earn their paycheck. Most people don't want to continue thinking about work when they are off the clock.
With that said, I believe you are advocating that, in any attempt to to implement Agile a balance must be found between purist principles of a methodology and a well defined workflow structure. My experience supports this notion as well.
I too think it would be incredibly useful to see/have more discussions about where and why Agile principles have broken down in the actual workplace/wild. These discussions, ideally, would be analytical assessments. But I doubt such discourse will occur without people drawing lines in the sand -and defending their point of view for the sake of the position and not the argument. Nonetheless, constructively critical articles such as this are useful and appropriate (IMHO).
Growing number of startups puts on managers, owners position a lot of unskilled, unprofessional people, who never had experience/especially long term of building teams and products. Those people at the end read somewhere that Agile is cool, then read few articles and believe that they know how to manage people. Of course it does not work like this, and usually results in a ruined project.
Milk with cucumber :D
geniuskitchen.com/recipe/tarator-b...
The best way to intimidate the management is to state: I want to hard earn paycheck, tell me what to do, specify my work, micromanage me.
That's way they adopt corporate Agile.
Well, a lack of flexibility, combined with breathless assertions of any system being the One True Solution™. No methodology works for all cases.