Here is a little ironic reflection on the 12 principles of Agile Manifesto. Scroll to the end of the page to read serious content.
Making fun of methodology
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
In most cases, the highest priority is to get as much money from the customer as possible with least work thanks to a big mouth sales manager, submissive project manager, and coders who know how to kick the bucket of refactoring long down the road.
Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
Almost any software engineer moans and yells when requirements change, because the world should be static enough to fit in his mind work, but not static enough to let him go and stop getting paid for his creation.
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
Sprint a week is nice, do you agree, fellow developer? winks uncontrollably
Business people and developers must work together daily throughout the project.
It is an amusement and great pleasure to get an answer from BA less than 3 days after the request, most time they are very busy with making your life harder. On the other hand, developers don't really want to get alongwith those humanitarian degree peasants that don't embrace the greatness of another Javascript framework and are not hip at all, a business does not give a damn about developers and requires working functionality here and now(they have not yet decided actual body of work for it, but you gotta do something).
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
Motivated individuals are great people with hiring ratio for your company close to zero. Most of the people work to get fed and covered, not to bring value to somebody else's business. Unfortunately, the real world breaks the bright visions of the future when methodology for focused self-controlled motivated professionals is applied to procrastinating incontinent discouraged amateurs.
The most efficient and effective method of conveying information to and within a development team is a face-to-face conversation.
Outsourcing reality: your manager is the only in/out source of data to the customer which leads to unfortunate data corruption on the way. Your teammates are not willing to do anything but code and drink coffee, so face-to-face conversations turn into interrogations with an enemy spy rather than friendly convos.
Working software is the primary measure of progress.
Translation from your manager: don't give a heck about legacy and technical debt the size of US national debt until the system starts breaking like a heart of 90 years old coffee maniac. When it does - rush to fix it, but not too long, you are not paid for fixing stuff.
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
That is the development pace - you break and rot the project until every new feature implementation process feels like Indiana Jones movie tomb walks, then customer sets you up one sprint for refactoring and fixing the tech debt. After a few hours of fixing customer is confused that the project is still not elegantly ideal.
Continuous attention to technical excellence and good design enhances agility.
Code up and break things, production will signal all the bugs, leave "technical excellence" at the university, we are in the real world of development, where there is only blood, iron and bits... What? Our test suite runs for hours and some components are 3000 lines long? Come on, we bring the value, there is no need to worry.
Simplicity--the art of maximizing the amount of work not done--is essential.
The customer knows best what to do, yep, we had a lot of situations where requirements changed mid-sprint or right after it, even though everyone was digging hard to release the feature no one needs as a result. This is simple - you are paid to code, not to argue.
The best architectures, requirements, and designs emerge from self-organizing teams.
And his left hand did not know what the right did, so they were self-organized as a swan, pike and a crab.
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
It is hard to reflect when your manager thinks effectivity depends on the number of hours you spend at the office.
On the serious note
Modern computer industry has a steady flow of newcomers, growing each year, Though, part of them are professional, aspired by the domain, have appropriate education(by themselves or in the university) and would stay in the field even if wages were lower and hype was not there, there is a vast majority of individuals that are here to make money and do the job that pays out most. Those people have different intentions but both types are welcome to the workplace because demand does still outreach supply and from the first sight it is hard to separate one from another(not even going into the debate on moving from one state to the other because or burning out, finding pleasure in coding, e.t.c).
Different intentions, focus and working quality of people directly influence the processes and treatment needed for their employer to reach his goals. Agile was created as a movement for better code, better quality and value brought to energize customers business. It implied that people who work in the field are self-manageable motivated professionals that know what they are doing. And some people are like that, so agile works for them. The others, on the other hand... They are not that independent yet or at all, so at some level methodology fails for them. In can be everywhere, on the business level, on the level of management or development. The fact is that some people are unable to work without process close to Ford factory where they are responsible only for their part of the process and are not required to do anything else.
Fast-food pipeline
Let us draw a cooking analogy. One of the major process features of McDonald's (and almost any other fast food restaurant chain) is steadiness and relative simplicity of their recipes. They try to keep their instructions on how to prepare some meal in a form which can be perceived and reproduced by any sapient human with the expectable result. Such cuisine will never be tremendously delicious, but it will be edible and the customer will be able to have some sense of decent meal even though it won't be anything special. They produce semimanufactures, write recipes and shape processes in a way that will allow the pipeline to produce steady result no matter what cooking skills a person at the kitchen has.
Perfect cuisine
On the other side of the specter, you have an elite-class Michelin star restaurant with a team of dedicated professional chefs that know perfectly well how to cook a proper meal from anything they are given except maybe from milk with cucumber. They know how to team up and work alone, they tried every piece of equipment in the
kitchen and know when to use it, they learned to improvise and to be consistent with the recipe to the last word. Each one would have opened a restaurant of their own if they did not enjoy working together so much. They are given a free choice of products for their meals and can do everything they want with one little constraint - clients should always be happy with what they eat.
So what?
Most of the companies out there are somewhere between those categories. The problem is - the same methodology does not fit all. You cannot give freedom to a person that wants to be constrained and have proper wording of what is required, do the steps and pass it to the next employee in the chain, the same way you cannot limit and put in the mechanic process a Michelin chef expecting him to work better in such an environment. In the industry sometimes you have highly constrained and detailed processes that use developer only as a code-generating bolt in the sequence as well as do-what-you-have processes that require tact, open mind, motivation and mindfulness from everyone in the chain for the job to be done. Strangely, both process configurations are called agile, even though the only thing they share in common is rituals around the delivery process but none of the values. Maybe we should come with new terminology on how the Manifesto was implemented in the wild?
Top comments (15)
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.