When developers are the one doing agile-ing, it seems to more successful. When it's a process driven by/for management it can get frozen in place making change harder.
Developer driven:
Mike: "Bob, I'm skipping scrum today."
Bob: "K" (Thinks "He's still working on the gnarly multithreading problem.")
Management driven:
Manager/Scrum Master: "Bob, where's Mike?"
Bob: "He's deep in flow working on that multithreading problem."
Manager: "Go get him, he can work on that later." (Thinks "I have boxes to fill in my spreadsheet. How can I do that without a scrum meeting??")
I dislike Agile because apparently the only thing is "waterfall" or "Agile". Many seem to think that before "Agile" or at least "Extreme Programming" there was nothing but the waterfall boogie-man.
It's as if they had never read books like "Rapid Development" which describes over a dozen different design approaches, with pros and cons.
I dislike Agile because apparently the only important thing is the Toyota Way. They never mention alternatives like the Volvo's Uddevalla plant and humanistic manufacturing.
Eg, quoting from http://gerpisa.org/ancien-gerpisa/actes/9/9-5.pdf "After a slow start Uddevalla took off and in 1991 reached the level of the Gothenburg mass production plant. From the last quarter of 1990 to the last quarter of 1992 Uddevalla cut the assembly time at an average rate of one hour a month. This rapid learning curve surpassed developments at the Gothenburg plant, where lean production techniques were introduced to boost performance."
Yes, such conclusions are contested, but it's still a concrete alternative that's almost ignored by those repeating the chant "Toyota ... Toyota ... Toyota."
I dislike Agile because it's a collection of ill-defined mush. If a group adapts or changes in any way during a project, and the project is successful, then it's counted as an Agile success story, while if it project fails despite flexibility then it must not have been True Agile, or at least Enough Agile.
"Rapid Development" was/is one of my all time favorite "project management" type books. Waterfall is a baseline. Even in what people would consider waterfall, there were "buffer" items incase we needed to change everything. The scrum disciples are being disingenuous when they compare everything to waterfall. It's like comparing the newest language to programming the Altair.
IMHO purpose of agile was to reduce the work in progress at Toyota. This can improve efficiency of existing assembly line. It was never supposed to build the new and improved assembly lines in short sprints. But that's what it is being shoe horned into and have become an excuse for not spending time doing the requirement gathering and deep design thinking.
I strongly feel Agile is a nice fit only when base work is done properly in terms of getting the software architecture and contracts correctly defined.
Because few organizations actually enable real Agile development. I did some "Agile coaching" in a previous life and time and time again I'd see teams embrace the cosmetic parts of Agile - daily standups, iterations, retrospectives - but workflow was still much the same as it always was.
Agile, done right, is more about how work is broken down into consumables and deliverables. It's about clear prioritization and freedom to focus on the task at hand. But most development teams would iterate aimlessly, while the organization around them continued doing business as usual.
To successfully embrace Agile, the entire organization has to do so at some level or another. You have to break requirements down into pieces that can be consumed in an iteration. You have to prioritize clearly. And you can't change priorities until the iteration is complete.
Additionally, many software teams misunderstand how they work. I can't tell you how many times a team would insist to me they were using a waterfall process, but when I asked them to describe the previous workday they'd describe end-to-end firefighting. When I would introduce Agile and the controls that it brings, they would react negatively expecting that Agile was some magical organized free-for-all.
Additionally, lots of consultants made money off of the promise of Agile and the cult of Agile. They didn't provide practical solutions, and organizations resisted change. So much of the indigestion that developers have regarding Agile is due to their own experiences with organizations that bought the promise of Agile but didn't do the necessary work to make it successful.
Heh, classic response. Whenever your project fails, your coach tells you it's your fault because you didn't do real Agile. Same with OOP, whenever your code inevitably becomes a tangled mess of classes, you will have all sorts of gurus making metric shit tons of money from books and consulting telling you you didn't do real OOP.
Guys, please, can you just admit there is no recipe for success (rhetorical question, of course you can't, that's where you money comes from, maybe you even believe your own bullshit)? There is no real Agile and OOP and other crap that I forget, they're just buzzwords that, when applied long or hard enough, produce shit. If you had kept you project to an absolute minimal level of Agile and OOP, it would probably still be alive and kicking. But you didn't, because you jumped on the bandwagon, you used religiously whatever was popular.
> Agile, done right ...
Yeah, heard that a thousand times before. Sadly, younger developers fall for this all the time, so shit grows exponentially. I'm aware my opinion has always been in minority but whatever.
I have done it right. It worked well for me. I've been on happy teams that produced good code: high quality, high test coverage, good for users. We did technical work that I'm still proud of. And we believe that was true because we paid careful attention to how we were working and improved it continuously, using a lot of techniques from the Agile movement.
I grant that there's no one right way. There are many, and they depend on circumstances. I certainly grant that there are an ocean of idiots selling bullshit. But you're throwing the baby out with the bathwater.
There are better and worse ways to make software. Teams can reflect on how they work and get better over time. Those teams can recognize patterns, and other teams can benefit from learning about those patterns and trying them out in their environment. And that's how things like Extreme Programming came to be: teams experimenting and sharing what they'd learned with other people who wanted to get better. That was exactly what the early Agile movement was.
Piss all over that if you like. But you'll be missing out.
I've been on teams that have agile it right. Some have failed and some succeeded. I've been on teams that practiced chaos driven development. Some of those succeeded and some of those failed.
My opinion (not "theory") is that teams are not interchangeable. Companies are not interchangeable. Industries are not interchangeable. What works for one team may not work for another. What works for a 10 man startup is not going to work for a 200,000 person company. What works for a web app company is not going to work for a video game company. But, Agile and Scrum have been shoehorned into every tech company I can see no matter how inappropriate it may be for that particular team, company or industry.
Your question prompted me to consider a thought experiment. Let's assume that management techniques are completely ineffective and the deciding factor in whether a project ships and is successful or not lies entirely with the programmers and designers. Now, let's take it one step further and say that most management techniques actually reduce the likelihood a product ships and is successful. Do you think that would stop management from trying to exert control over something that is completely out of their control? Do you think that would stop management from thinking that their input is actually making things better when in fact their input is making things worse? Managers are ultimately responsible for producing results, but they have no direct control over those results. Most humans, when put in that situation, will try to do something, anything, to make it feel like they have some control over the situation. Even if it makes that situation worse. Finally,what if what I have described above isn't actually a thought exercise, but a fairly good description of what is happening in the real world right now. Would we be able to tell?
Managers in large companies will push anything in a top-down fashion. Before, they pushed waterfall. Now, they are pushing something they call Agile. (They do, I don't.) In 5 years, the consultant-managerial complex will push something else. I agree that is bad. [1]
But the top-down thing is explicitly not what the Agile movement was about. As the early Extreme Programming community would say, "By-the-book Extreme Programming is where we suggest you start, but it's definitely not where you should end up." The notion was always that teams would take time every iteration to look at how they were working and improve it to match local conditions.
So the way to think about it isn't in terms of manager interventions. It's in terms of those non-interchangeable teams experimenting and then sharing what they've learned with other teams. Teams will learn things! Some of those things will apply to other teams. A few will apply widely. And that's exactly how the good Agile teams work today. They may start from some recommended set of practices, just like any novice does while learning things. But they are supposed to evolve from there to match local talent and conditions.
Not so weird at all. Codebase and process don't matter to a customer, all they see and judge is the end product. Sometimes even the end product doesn't matter, as the likes of Google can put much more money into ads and marketing than you.
There might be a correlation between what people do and how the project goes if you're NASA or BMW. But for 99% of the software world, nobody cares if you have the most hacky codebase ever as long as it does what it's supposed to do and doesn't have too many bugs.
The customers don't care how the programmers work as long as they get good results. But the people on the team should really care. And if they do, they should a) experiment, and b) exchange ideas with other teams.
Well, I don't know if that's fair: most of the places I've worked at that claim to use "Agile" methods were participating in a kind of Cargo Cult. In other words, they thought they were jumping on the popular bandwagon, but if you examine what they did and compare it to what the Agile et. al. stuff was supposed to be, it's not that.
I don't know how one does real OOP, but I know what C++ OOP looks like when used long enough.
1) Architecture. Architecture trumps everything. Even though "favor composition over inheritance" has been repeated for a very long time, some people just didn't get the memo, and you'll encounter mind-boggling inheritance hierarchies (sometimes even template inheritance, to make it fun) with more levels than circles of hell.
2) Class-itis. Everything must be a class, and free-floating functions are seen as coming straight from The call of Cthulhu. Most people are more concerned with the way the class will look and fit in the existing architecture than if the desired functionality is achieved.
3) Code reuse mania. If you write the same line of code in two different places, some people's palms start sweating. More than two identical lines in two different places and you'll have people screaming to move the coded to another place and share it, irrespective of whether it is beneficial or not.
4) God objects. When people just can't take it anymore and simply jam yet another object in the God object. Yes, I know a lot of people from the cult of OOP will tell you this is an anti-pattern, and I agree, but it happens. And when they unravel the God object, an even bigger mess emerges most of the time.
I don't know, I'm probably forgetting a dozen other manifestations of OOP.
You know what "you're not doing real Agile/OOP" sounds like? "You're not doing real communism". And we never will.
>you can't change priorities until the iteration is complete
The original agile manifesto was meant to avoid following plans blindly like that. It's only four lines one of which is "Responding to change over following a plan".
Despite what the kanban people think, Agile isn't supposed to be "small waterfall" where the work and priorities are set in advance instead of discovered as you test hypotheses through trying different technological approaches and doing back and forth with the users.
What you propose means that if in a cycle you discover that the plan was sub optimal and not well prioritized (and when you are iterating, you are in the best position to find that out) you march on towards the dead end and only adjust after the "sprint" is over? That is not agile, it may fall under scrum but really it is just small waterfall.
Good agile as it was originally stated is compatible with and even comes from a similar line of reasoning as the Lean approaches. The core of Lean is that the people closest to the technology should be put in a close relationship with the users to be in the best position possible to resolve what I like to call the crux of innovation. Innovation's most difficult and most crucial part which is to figure out what work has the most value to effort ratio, what has the most risk and needs to be studied early to clear up that risk and ultimately what the team should be working on first. At least for any work that is somewhat leading edge or a bit experimental, priorities cannot be properly assessed without experimentation, user feedback and management of uncertainty and risk trough early experimentation.
Scrum tends to ignore this core problem by positing a product owner that has the answers. This is very reminiscent of waterfall where people disconnected from the technology and who aren't experimenting and putting things in front of users, who are ultimately in a bad position to make plans are making those plans anyways. IMO what you are describing and a lot of the ideas in scrum are the very things that original agile was meant to prevent and also goes against Lean approaches.
Here is the agile manifesto:
"Individuals and interactions over processes and tools
The problem with breaking things down iteratively is the same as trying to paint a mural 1 square inch at a time. The developers / designers don't get a feel for the overall picture what so ever.
Also, instead of having broader estimates in terms of months, you force developers to rush constantly with sprint completion pressure. In case you didn't know, rushing developers is very, very counterproductive. Cost, Time, Scope. Pick 2.
Software development is all about breaking problems down iteratively. If you can't break the problem down to a scale where people understand, how can you ever break a problem down to a scale where a computer can understand?
But I do agree with you about "sprint completion pressure". With Kanban you don't have that and you don't have large day long "sprint planning sessions". You have just enough work in the "Dev ready" column to keep the pipeline going.
Of course not having the sprint planning pressure and not having a deadline to release doesn't work without a continuous delivery pipeline and some way to turn features on when ready.
>Software development is all about breaking problems down iteratively.
It is, but it depends on the size of the iteration and who is breaking it down as to whether or not it is useful.
I much prefer, "here is the problem, solve it," to "here is the problem and I'm going to tell you how to solve it, even though I have no idea how software development works."
Of course, the most recent "official scrum" environment I worked in was horrible. They really used it to micro-manage development. We actually created all the stories for a multi-year project so we could give an overall timeline (waterfall) to management, then the business dictated the order of the stories even when they made no sense. It was a constant battle.
It is, but it depends on the size of the iteration and who is breaking it down as to whether or not it is useful.
I much prefer, "here is the problem, solve it," to "here is the problem and I'm going to tell you how to solve it, even though I have no idea how software development works.
Yes I've been subjected to that also. But the right way to do it is to have an experienced developer working with the business representative/product owner to do "backlog grooming" before the item ever gets seen by the rest of the team.
Where I recently did this, each iteration was a feature and it was supposed to be "code complete, ready for production, never needing to be modified again." We had to constantly fight to refactor existing stories when new stories were introduced that made our original designs less than desirable. It was a mess.
Then you shorten iterations if you need to change priorities more often, or you stop the iteration and start a new one. Waterfall created a scenario where requirements couldn't be changed without significant effort. Agile creates a situation where those managing the backlog can change requirements whenever they see fit. And developers, next time an iteration is planned, take the top items from the backlog that fit into their iteration capacity.
The side effect of shorter iterations is that requirements have to be broken down to fit inside the smaller iteration, so there is a price to be paid by those managing the backlog and generating requirements if change needs to happen quickly.
Agile methodologies don't enable change as needed, they create a structured way of handling inevitable change. And when the backlog is adjusted to accommodate that change, the consequences of that change to budget and delivery date are easy for everyone to see.
If you don't have controls in place, then there is no understanding of the cost of change. And without understanding the cost, good cost-value decisions can't be made.
Shorten the iteration or abort it midway? Not gonna happen. Management loves having a Monday to Friday iteration. That structure and control is way more important to them than reaponding to change.
Shortening the iterations means you now how to rechop all your tasks and do the estimates again wasting even more time. Also the smaller the task the less people focus on the bigger picture and your software just turns into a mess of puzzle pieces.
Just my experiences from having to go through Agile Hell.
Then that confirms my OP - everyone wants to embrace the cosmetic pieces but the actual meat of Agile is ignored.
Every control has to have consequences, or else bad behavior has no cost. Your organization is addicted to what the calendar says, and the software is neglected. The consequences are suboptimal productivity and/or quality. Appearing to work has more value than completing work.
No software process is immune to leadership failures.
Wasting time? Measuring twice and cutting once is done because it saves time. As a shirt I saw recently said, "weeks of programming saves hours of planning".
Agile often allows no time for doing it right, leading to high levels of technical debt. In the end it leads to Rube Goldberg machines and the "big ball of mud." It's suitable for prototyping but often fails for producing quality software.
The nastiest balls of glued together snot I have ever seen were almost all from textbook Scrum shops. The rest were from lowest bidder outsourcers that probably use similar management methods to try to get code from bad or underpaid/unmotivated coders.
The problem is that deep conceptual thought about a design and deep refactoring are hard to capture as a ticket item. Quality is something that perfuses all deliverables but is not itself a deliverable.
Agile is also totally unsuited for innovation. You will never get a Xerox Parc or SRI with agile. You can only make what you already know to make with agile.
I was an early adopter (1999-2000), and for years was excited. I was burnt out on programming and considering quitting the industry, but adopting XP made things so much saner that it turned things around for me. But circa 2007 I heard more and more horror stories about companies that were "doing Agile", by which they meant top-down imposition of some fraction of things, plus managers slapping shiny new labels on their same old bullshit.
It was heartbreaking to see something that helped me and my teams a great deal get so throughly misused. It became just another stick to beat developers with. I spent a lot of time apologizing for all the pain people endured.
It's hardly the first time, though. The original paper on Waterfall basically said, "This is a thing that is bad and does not work." But people went and did waterfall anyhow, because a) it conforms to a number of human biases, b) it reinforces the typical top-down corporate power structure, and c) provides endless opportunities for people to blame other people for problems. So in retrospect I'm not shocked at all that we've mostly turned the various Agile methods into meaningless pablum.
> People desire a structure that allows them to abdicate responsibility.
s/People/Managers/
In many of the cases I have experienced, agile breaks down into an excuse to not plan ("Requirements just slow things down!"), and the elements of it that would drive success are ignored.
So often business leaders just want shit done, and when the technical types warn about reliability or technical debt, there is a lot handwaving. Thus short attention spans see agile as a way to justify shortcuts. When this happens the result can be worse than a poorly executed waterfall model.
Agile works when all the proper elements are used, just like any other endeavor, and it fails for the same contrary reasons. Developers become frustrated when yet another path to accomplishment is blocked.
Disclaimer - Am technical manager. Have watched business peers shortcut to failure. Have fought the battles and lost. Frustration apparent.
This exactly. Agile allows managers to push all responsibility onto the developers (design, testing, deployment, ops, customer service, spec writing, documentation, training, etc), while simultaneously enabling them to demand milestones every two weeks.
I have seen this taken to the extreme-- the management at one company I worked for would not specify ANYTHING in writing. Nothing. Not even bullet points on what a feature would do. They would then micro manage intensely (I had a non-technical VP doing code reviews on a Senior Architect).
Estimates, however, only included development time, never any other tasks, and were always challenged. Deadlines were always hard. In short, we had all the responsibility of Agile but none of the empowerment. Engineering was to blame for everything.
If you think this was some small crazy startup... This companies revenues are about 500m a year. Almost every American has our products in their homes.
> "So often business leaders just want shit done, and when the technical types warn about reliability or technical debt, there is a lot handwaving. Thus short attention spans see agile as a way to justify shortcuts."
This is the crux of the problem with agile. The reason it's embraced so readily by business types is the reason that it fails. With the 'justifying shortcuts' description you hit the nail on the head.
About nine months ago I was hired to create a modern "agile" development shop with an IT department that had a legacy product built on Access, SSRS, stored procedures, an old version of Sql Server, etc...
It broke every single rule of what I look for when accepting a job. I only took the job with the condition that I would have 100% support, budget and time to set things up right from my future manager.
I laid out my vision....
1. Realistic timelines based on a 40 hour work week. All estimates and deadlines were based on realistic hours, realistic staffing levels, and realistic utilization.
2. I would be given the time and budget to setup a proper CI/CD platform.
3. We would put in all of our estimates time for automated testing and code reviews.
4. Devs would have direct access to the (internal) customer.
5. I would have the budget to contract smart people at market rates.
6. Any dissension from the legacy developers with an attitude of "why do we need to change. That's the way we've always done things" wouldn't be tolerated. If they couldn't get on board, I would hire my own team and let the existing developers support the legacy product.
It's working well so far. I would never have accepted the job as just another developer. I only accepted it as an architect that was given the authority to make the changes. I haven't gotten any push back from the higher ups. I had to sell everything as a long term cost savings:
- automated tests keep the cost of hiring QA down. QA only has to test new functionality. The more automated tests you have -- both unit and integration tests - the less manual regression testing you have to do.
- automated testing also allows us to ramp up with contractors and you don't loose business knowledge when people leave because the business logic is in the automated tests - not a bunch of documents in SharePoint. If a contractor comes in and makes a change and the tests break, they've broken a piece of business logic.
- Once everything is setup, and documented, you don't need dedicated "release engineers" all releases are coded with Powershell and configured with Consul. We treat servers like "cattle not pets".
We also based the project on Mongo and not sql server so we don't have to worry about database deployments. We decorate the fields in our POCOs that are being stored with attributes that tell the individual services at startup to auto create any missing indexes that we need. Schemas are enforced by microservices that are the only way to access Mongo.
That right there is one of my biggest pet peeves in any dev shop. It's astounding how few people see the connection between "the way we've always done things" and "the problems we've always had".
See a more detailed summary in my previous response, but well so far. If it doesn't work out, I have no one to blame but myself. I've been giving the authority, the budget, and the support to do it right.
I think some dislike agile because its adherents so often write articles like this. Pompous, dismissive, assuming facts without providing real measurable evidence and implying that people who disagree only do so because they're just not smart enough. If Agile didn't improve your processes, why it must be because you didn't do it right! And because of that, you hate yourself! You're just afraid of success! Uh-huh.
I dislike it because it makes me a worker at a conveyor belt rather than a craftsman or artist. The person paying the bill might argue they need something built so can't pay a craftsman to improvise - which is why this friction occurs. It's between software development as engineering vs. as an art/craft. It will always be both.
It depends on which "Agile" you mean, but for me it's just the opposite. It's no accident that a lot of the people behind the Software Craftsmanship movement were part of the early Agile movement:
The first realization should be that Agile is not a silver bullet and is not needed to build great software. Great software was built before Agile existed.
People who care passionately about technology and software build great software.
On recent Agile projects I have been involved in, a lot of Agile 'artifacts' were produced (mostly walls covered in Post-it notes). Software seemed to by a by-product and didn't really feature much.
I think this is a result of the 'busywork' Agile created.
This is something I hadn't considered. Thinking back on it, the teams I've been on that did agile had 3 or 4 times the number of managers that non-agile teams did. You needed more people to enforce the process, wrangle the engineers, plan the meetings and make sure that wall of post-it notes was updated. Something I frequently heard was that programmers were paid too much to waste their time playing arts and crafts.
When software projects fail, it's natural to think "wow, if only we had organized things in this way...", or "if only we had a more accurate schedule...", but it's just a way of ignoring the elephant in the room: your developers weren't up to the task. Think about it this way: if your developers knew about all of the issues that would result in a failed project and a) didn't tell you or b) didn't quit if you ignored their warnings, then what kind of professional developers are you employing ?
This micro-management of the entire software development process is completely unnecessary and contrary to every bit of real-world evidence that we have about what has made certain software projects successful, and others not. Ambition, drive, and a penchant for excellence is what makes great software, not a bunch of managers pushing along a group of mediocre developers like cattle.
Hardly anyone is going to quit just because you ignore their warnings and let them work on a project doomed to fail, barring a significant equity stake. Software projects fail due to bad management, not (solely) bad developers; you go to war with the army you have.
Would you spend a year or more on a project that you knew was going to fail 2-3 months in to the project ? I certainly wouldn't, but maybe I'm in the minority. It certainly doesn't look that great on one's resume...
Really? I'm sure some would regard it as an example of professionalism, "going down with the ship", "when the going gets tough ...", etc.
Some people would jump at the change to learn a new technology on the company's dime, if they know that the project failure can't be attributed to them. Eg, a front-end engineer could say "we developed an Angular2 front-end which was on-time and tested well, but the back-end engineers failed to <insert failure here>."
What does it mean then that after the first delivery, the project's customer representative was burned out and couldn't be replaced, the software was only ever used for 10,000 of the 87,000 people it was supposed to be used for, but even with the smaller number it still took 9 hours to run, and new developed stopped two years later, never reaching the original design goal?
If project failures look bad, how is it that XP ends up with such a good reputation?
Sorry for not replying sooner, I missed your reply.
I should have been more specific about the context: I'm talking about failed projects that were doomed from the start, and known to be in such a state by those that were involved. There are many (most ?) projects that look okay right up until the implementation when all the problems become visible. Those types of projects are fertile grounds for learning from experience, and I would categorize them as valuable experiences.
Obviously if a developer is in a junior position in a project that encompasses a small army of developers, then they may not have any problem with staying on with such a project. But, I would gather that these types of projects are pretty rare, and that most projects involve much smaller teams. In such an environment, the stress and toll on one's family life and health aren't worth sticking around for, even for any learning experience that one may gather from the failure. It's a much better situation to simply learn the involved technologies on one's own in your spare time than subject oneself to that level of harm.
Yet we know that people join these projects. Yourdon's “Death March" covers the topic. I haven't read it in a while, but according to http://wiki.c2.com/?DeathMarch the first chapter includes "what motivates developers to join them".
Looking around now, https://www.quora.com/What-is-it-like-to-work-on-a-death-mar... summarizes what people do in these sorts of projects: "(a) follow all orders you are given, (b) avoid being given orders if you can (i.e. don't volunteer for more work), (c) always appear busy and productive, and (d) start doing side projects (and, possibly, looking for other jobs) to stay sane. A death march project can be a great time to build unrelated skills on the clock, because there tends to be a lot of downtime due to miscommunications. ... keep quiet, always appear busy, and focus on your own career vector."
This agrees with my understanding, which is why I don't think it's such a CV death knell as you suggest.
> This micro-management of the entire software development process...
I've been there. I've also been in the opposite, where there really is no technical leadership. I can't say it's better.
For what it's worth, certain agile techniques do provide a structured way to make clear group decisions. Unfortunately those decisions usually revolve around development methodology and not, you know, the design of the actual product.
Point being, micro-management is often a broad reaction to a vacuum of technical leadership. But instead of innovating, with the team makeup in mind, on how to make sure good decisions emerge, a manager will figure they need to personally make those decisions. So they need more structure to make sure they're better informed, and agile techniques tend to get hijacked to that end.
Yes, but that's my point. If you have a lack of technical leadership, then you need a different set of developers and need to look at who you're hiring as developers, not whether you need more management of the group of developers. For the cost of a technical manager, you can add quite a bit of salary to each developer position in a small group.
I'm not sure that developers dislike those they work with so much as they dislike being managed - the fun part of the job is exploratory programming and chasing technical curiosities. Having a manager and customers means we actually have to create something that works and generally includes more "drudge work".
If developers dislike agile, you'd expect them to be happy with BDUF (waterfall) and I never hear people saying they're happy with book-sized specification documents.
Isn't this really the difference between computer science and software engineering? As developers we have to straddle the fence.
Software developers are human beings. This seems like a "duh" moment until you realize that we routinely ignore this basic fact. As human beings, we operate best when we feel like we're doing something important or valuable. If we are tasked with something that is neither, then it is up to the person that is assigning the task to acknowledge the situation and make it be known that "taking one for the company" won't go unnoticed. There are also additional compensation options that could be used to make the whole situation more tolerable. Something along the lines of "Bill spent two weeks documenting that entire area of the product that everyone is so wary of altering, so he's earned that extra 3 days of vacation".
Edit: In case it wasn't clear, I agree with everything you're saying. However, I do think that good managers that understand their developers can make things work and keep everyone happy.
Agile encourages staying flexible and able to change plans on a whim. In practice that tends to mean that people using agile processes don't plan long term. Piss-poor performance is the result. Breaking tasks down into manageable pieces is hard, and requires good long-term planning for any significant project.
Agile in practice is "weeks of work can save you hours of planning".
This my experience too - agile seems to exist because clients and middle management refused to determine and plan exactly what the want developed, preferring to "know it when I see it". Agile encourages this attitude.
No one knows what they want until they see it. They may have some vague idea but without seeing at least a minimum viable product or at least a non production ready proof of concept how can they know what they want?
The other side of rapid iteration and emergent design is building a system with change in mind, not over architecting and living by the principle of YAGNI - You Ain't Gonna Need It.
It's the job of the architect who should have both the people skills and the technical skills to give the customer what they want and not what they ask for.
Processes are needed for sanity, and not much else. Don’t be the baker who’s really firm on a choice of a 9x13 pan and the entire set of ingredients for a cake, only to find out that people want cookies.
To move quickly, you really need just two things: a way to make sure things don’t change unexpectedly, and a way to recreate anything you had before (where the 2nd is a crutch if the 1st fails). To have sanity, you need somebody setting a direction (“we’re doing this”), and somebody deciding what can wait.
For software, this means things like: “for Pete’s sake, use revision control”, “track versions of dependencies”, “back things up”, “write scripts instead of step-by-step instructions”, “test somehow”, and “track problems”. There is no “daily one hour meeting” phase of software development.
I love Agile and Scrum for solving my own problems. Nothing is better than being able to iterate on an idea to determine if it's right or not.
However, I mostly witness selfish, political, or misinformed ideas being dictated as "requirements". I learned really fast that stakeholders do not like their ideas being questioned with data points from a scrum research spike.
So who enjoys wasting time when your professional viewpoint won't be heard?
If management or stakeholders are unwilling to listen to the team that solves problems for a living, why should I/we waste energy on Agile or Scrum?
I dislike it because it forces you to think, work and report almost exclusively "in the small." I prefer to focus on larger scope, not merely live surrounded by a fog of scope, while working on the small things that contribute to the larger scope.
I'm the same way. Though you need the whole team working on the same larger scope. The Agile approach is to break everything down and make many small adjustments to make sure that happens.
That's certainly not the only way, however, to ensure a common vision of the future.
Truth is you need to get st done, I see a lot of mediocre developers hiding behind agile processes, when they can't figure out something they throw their hands in the air and scream "bad requirements" , boohoo man-up and do the business.
I feel like in order for agile (and devops) to work, you have to at least half invent it yourself, before realizing what it is. If you try to just impose it on a team, then it get a little cargo cult-y and people don't understand why they're doing it.
This like essentially justifying - "Why do X dislike Y?" questions by the person who loves Y. It is not surprising that there has to be set of process or steps when doing anything, and I mean anything. The problem arises when Y is suited for type A projects but just because the Manager has read about Y in some magazine he thinks "one size fits all". The problem can be seen from the blog itself. The Toyota Way and contextual changes. In software sometime defining the context itself becomes impossible. It certainly is more difficult in a company which has no other defined processes but wants to implement Agile.
In and of itself, I don't see much wrong with it. Agile itself does not seem to be the problem.
Problems arise when it is heavily abused and applied incorrectly by management, in my experience. My first time doing Agile (well, SCRUMM, but bear with me here) was someone using it to manage multiple unrelated projects at once. Predictably, it crashed a burned miserably. The person who decided on it was suckered by the buzzwords but failed to actually understand the purpose of the process.
My current company uses SCRUMM quite effectively, and it's been a wildly different experience. It probably helps immensely that the people in charge are also developers.
I think those conflicts exist in all so-called "teams", but in Agile those conflicts become sublimated by a grumbling about "process" on a sprintly, if not daily, basis.
If your plan, on the other hand, is to have three people develop three separate parts for a year, and then think you are going to stick them together and release in two weeks, people can avoid interpersonal conflicts entirely for a year, after which there is a crisis, which is often survivable by the participants because there are already so many chips in the pot...
there is a pretty vast middle ground between 'talking every day for a year, and never making any plans' and 'make a plan for a year, don't meet in the interim and try to integrate then'
make plans. try to gauge costs. change plans when necessary. integrate as soon as is reasonable. use consensus to drive structure/interfaces. maintain a testable artifact.
maybe running a service is different, but variants on the above seem to be the only thing that works for software.
Simple, developers dislike it because it leads to very messy code, quick fixes that lead to messier code, and a stressful work environment. On the other hand, waterfall leads to missed deadlines, cost overruns and applications that don't meet needs.
I think we need something in the middle. Does anyone have any ideas?
I suspect the fix will be on the type of software app that people are writing rather than the way apps are written. Monolithic apps are hard to write and maintain so we need to think small and generalize software something similar to lego bricks.
The Greenhopper plugin was a joy to use, 10 years ago.
Jira Agile is an atrocity, especially in an enterprise environment. About 5% of the time you'll actually be using it to help you do your job. You'll spend far more time answering questions and doing risk analysis, etc, etc all at the request of some random person you've never met who needs reporting on some random bit of information that is of no consequence.
It's used as a reporting and tracking tool now, not a tool to handle development flow.
scrum could work, but only in speciql cases. for example, it cannot deal with new coworkers, at least not in the teams I experienced. it could work for ad hoc teams with the same knowledge, but in practice that is never the case
Developer driven:
Mike: "Bob, I'm skipping scrum today."
Bob: "K" (Thinks "He's still working on the gnarly multithreading problem.")
Management driven:
Manager/Scrum Master: "Bob, where's Mike?"
Bob: "He's deep in flow working on that multithreading problem."
Manager: "Go get him, he can work on that later." (Thinks "I have boxes to fill in my spreadsheet. How can I do that without a scrum meeting??")