5

Disclaimer: I think about the agile values a lot, and happily support them.

After almost 20 years of "non-agile" software development projects, and a couple of years in Scrum and alleged "XP" projects, I'm sorry to say that:

  • the non-agile projects worked out pretty well (they were <= 1000 man-days, small-ish teams, ~3 milestones in each project)
  • in general it was really satisfying to have rather large assignments and to organize work and communication quite freely and cooperatively
  • and yes, I learned a lot despite not regularly (and not for endless hours) sitting next to others in order to do pair programming
  • nowadays, everyone around me hates being suffocated by "agile" processes, tiny tasks and massive control machinery around
  • people change jobs a lot more than before, become quickly frustrated due to constantly being regulated, and actually the productivity goes down tremendously

Of course I read "so obviously you guys are doing [insert-cool-method-here] wrong!" a lot. Well, then maybe it's quite difficult to do it correctly, and so far it has only frustrated everyone I know, and not brought any benefit - except that we learned about ticket-based development and how it is making us really unhappy. (I may add that I know of a couple of rare cases where Scrum worked out OK for rather low-profile work. Also the junior-senior ratio seems to be much higher today.)

I understand that requirements change, communication is important, and we need ways to keep track of the project. Actually I've also been a quite decent "rather traditional" project manager, too. Well, we ... inspected and adapted, actually! And we didn't even give it any special name.

One thing I don't get at all is why more process, and more control, should ever make software development better? To developers (and probably many other jobs), I sometimes feel some sort of Heisenberg effect applies.

If any recent management method is supposed to be the solution to any evil-Waterfall-related problem, then I decidedly want that problem back.

But then, a question remains: how come my Waterfall projects were largely more satisfying - and also more successful in a business sense - than all those new "agile" projects? Is there a practical, yet not-so-much advertised approach I may dare to suggest to my managers?

closed as primarily opinion-based by Euphoric, Thomas Owens Jul 17 '17 at 12:25

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 3
    "avoid asking subjective questions where … your question is just a rant in disguise: “______ sucks, am I right?”" (help center) – gnat Jul 16 '17 at 17:30
  • 3
    While I think there is something interesting at the core of your question, there is a major flaw: your claims are based on your personal feelings of projects success and team satisfaction. This is a good start for a discussion at the water cooler, but I would expect a more scientific approach for a discussion on SE.SE, something like “here, see, my studies show that our Agile projects have a drop of 14% of success rate, and developers' satisfaction dropped by three points.” In its current form, the question is just too subjective. Sorry. – Arseni Mourzenko Jul 16 '17 at 17:52
  • 6
    aglie should be LESS processes than waterfall. can you add some examples? – Ewan Jul 16 '17 at 18:03
  • 1
    Although this question is predestined to attract opinions, I think there is indeed a more general point in it. I think, the answer lies neither in waterfall nor any agile methodology but in the setting in which the methodologies take place. The key to answer the above question is the analysis of the communication structures. And the general conclusion would be, that success is more dependend on working communication settings than on actual methodology. – Thomas Junk Jul 17 '17 at 9:33
  • 1
    @ThomasJunk Which is why first sentence of Agile Manifesto is "Individuals and interactions over process and tools". – Euphoric Jul 17 '17 at 11:38
5

Disclaimer: what follows are merely my own opinions, with my limited experience of 4 workplaces.

First, I think the most important is the people you work with. I kind of like the term "peopleware". Because in the end we do the software, not some methodology. And the results highly depends of the people involved and they work together.

Regarding the methodology, I think applying either in their "pure" form sucks badly. The ideal IMHO is something in between that fits the team/project.

Waterfall

"Plan first, then do!"

How it can be done well

It makes sense to clarify what should be done and how before writing all the code, especially if it's a fairly big project. You first analyze what should be done, then split the work, then do it. It's quite effective actually. Waterfall doesn't mean that it's written in stone either. Of course you re-iterate and adjust it as you go. It's just that you plan what to do before you do it instead of the other way round.

How it can go wrong

Of course it's possible to make disasters out of it. Distance between the "architect" and the developers, over engineered stuff, with lots of intertia, and when change is requested, people raise their arms saying "that was not in the specs". Although it doesn't have to be, it has a tendency to it.

Agile

"Let's start and adapt as we go on!"

How it can go well

I think ideal for smaller projects or when the end result is quite blurry, which is actually fairly common in my experience. Moreover, if clients have a prototype they can toy with, it can be very useful for feedback or clarifying the details. It's a very adaptive process, and the progress is more visible.

How it can go wrong

First, it can be a pain to rewrite everything every month because of constant change or whims. Also, often, temporary code becomes permanent and "should be done later" stays forever, leading to technical dept that just piles up as the software grows. IMHO there's a bit too much micro-managament involved in the SCRUM stuff. Instead of empowering the devs, it treats them like robots.

Side story, just as an anecdote. In one project I was in, we had a daily standup meeting with a team of 15 guys. It was simply a silly waste of time, everyone talked about specific details nobody else understood or cared about.

Current workplace

At my current workplace, we are fairly "process-less" and I think it works quite well. It's actually really simple. We meet up once a week in a small team, have a small chat about progress, events, and what should be done next. That's it. Everything else is up to the dev. No time estimates, no schedules, no reporting, no management per se, just: "ok, the next thing we should do is XYZ ...and if you still have time, there's also ABC. Do it as you please.". Usually tasks taking days to weeks. Separately, there are bug reports that should be resolved with priority, but these aren't too many.


Conclusion

IMHO strictly following either methodology won't write better software. Having friendly contact, competent co-workers, clear objectives and being heard will do.

my 2 cents

  • May I ask you where you work? In my old team we were having two meetings a week and we were much more focused and effective than having daily stand ups. – Giorgio Jul 16 '17 at 19:37
  • 2
    What you have described in your last paragraph is what Agile really should look like. – Euphoric Jul 16 '17 at 20:31
  • 2
    @Euphoric Well, actually, I find us closer to a waterfall process. We plan, analyze, then do. It's just small waterfalls. We don't have that whole SCRUM crap that is associated with agile. – dagnelies Jul 16 '17 at 20:35
  • 2
    No, "waterfal" means that there are distinct phases (analysis, design, implementation, etc..) and each phase begins only after previous ends. And once final phase ends, the project is "done". "just waterfalls" doesn't make sense. What you have described feels more like a form of Extreme Programming. – Euphoric Jul 16 '17 at 20:37
  • I work in a similar way as that final paragraph, after having been burned by heavy scrum processes with big daily stand-ups where nobody paid attention. But, a key point is that your team has to be ready for that level of autonomy. If you have a bunch of unskilled juniors you need to wrap them in a lot more layers of process or they just won't get things done. Agile = adapt to the needs of the day. If your needs involve more structure, add more structure. – Joeri Sebrechts Jul 17 '17 at 11:14
2

I have worked in successful and non-successful projects, some of which used agile and some of which didn't. Overall, I would say what differentiates satisfying projects from those that aren't is the presence or lack of good project management. So, the successful non-agile projects had regular team meetings (not necessarily every day) and also good project management where tasks were intelligently assigned to those who had the most expertise.

I would categorize "agile" as a buzzword. Everyone is talking about it these days. Yet for very large software development projects (10+ years, 7-70 persons), it makes sense to consider people not as identical but as individuals with differing skills and differing knowledge of various parts of the codebase. Exactly the opposite of what "agile" means. In one company where I worked, we were officially using Scrum, but the process was adapted to the special nature of the large (10+ years, 70 persons) software development project. So not very "agile" after all... And perhaps that's why it worked.

For small projects where all people are competent and there is so little so trivial code that special and differing expertise in some parts of the codebase doesn't develop, I would actually say agile may be the best method. But for long-term large projects, it certainly isn't, unless so heavily modified you cannot anymore call it "agile".

  • 1
    @Euphoric Yes, the assumption is that you can assign a difficulty value for each task in Scrum (the most popular agile process), while obviously the difficulty is a function of the person implementing this task, something which Scrum does not take into account. So, you can have components A and B, and persons a and b expert in those components, respectively. Now if b works on A or a works on B, the results are increased development time, even if both a and b have equal amounts of past programming experience. – juhist Jul 16 '17 at 20:32
  • 1
    If you consider "agile" a meaningless buzzword, why does your post contain assertion of what "agile" means and what practices are part of it? – Euphoric Jul 16 '17 at 20:48
  • 1
    @Euphoric: please don't put words in my mouth I didn't say. I never said it was meaningless, nor did I provide an exact definition of what agile is or is not. Moreover, my post starts with "Disclaimer: what follows are merely my own opinions". Nor do I want to start an argument about this. I stick to my point though that "agile" is rather vague, often used as buzzword, and commonly incorporated by SCRUM. – dagnelies Jul 16 '17 at 21:03
  • 2
    @Euphoric: "Can you tell me where in "agile" does it say people are identical?": Shared code ownership, all members of the team possibly working on all modules, doing the testing. That kind of stuff. Everybody does everything so that everybody is easily replaceable. – Giorgio Jul 17 '17 at 5:20
  • 2
    @Euphoric: Maybe it is not the official position of the agile proponents (however, see e.g. martinfowler.com/bliki/CodeOwnership.html) but "collective code ownership" (also phrased as "no code ownership") was practiced in all the agile teams I have worked (three of them). Which means that everyone is free to modify or rewrite code without consulting with the previous author(s). I have raised this problem in all the teams I have worked in, and my current team there is at least some effort to discuss changes on parts of the code that were originally written by others. – Giorgio Jul 17 '17 at 18:11
1

How come my Waterfall projects were largely more satisfying than all those new “agile” projects?

If I had to guess, nostalgia. It is more satisfying to get this big 6 months project done than this stupid little 2 weeks of work - that doesn't mean it was done better (on time, on budget). And of course there's also the problem that most places are only sorta-Agile. They say they're agile, they have the same ceremonies, but have none of the mindset.

For example:

nowadays, everyone around me hates being suffocated by "agile" processes, tiny tasks and massive control machinery around

So change. You are a self-organizing team, right? A cornerstone of many Agile approaches?

Even if you're not, you should definitely abide by "Individuals and interactions over processes and tools". It's literally line #1 of the agile manifesto!

One thing I don't get at all is why more process, and more control, should ever make software development better?

There's situations where it may, but odds are that they won't. Hence manifesto item #1.

I hate to repeat things you've heard, and I wish things were better for you, but your companies are doing it wrong. You are right that it's difficult to do. It's difficult for people to trust one another. Trust that people can make good decisions without process. Trust that if we make choices towards the goal we'll eventually get there. Trust that individual interaction is happening and effective rather than having meetings and oversight and onerous bug tracking micromanagement.

0

I think 'Agile' works well, but when I say it I mean:

  • 5 to a team
  • Week long sprints
  • Daily Standup : you point at the task you did yesterday and are working on today and the only time you have anything more than "I did this, now im doing this" to say is if its going wrong. Basically its just roll call.
  • no retros, no planning, no estimates. Just pull from the backlog and slap new tasks into it when you think of them.
  • Deploy/Demo at the end of the week.

It works when you have people who know what they are doing "write me an app/website/business workflow/whatever" and have the necessary tools to do it to hand (language chosen, dev env, production env)

It solves 2 problems

  • Big Company problem : We have to do months of requirement gathering and document writing before we can even start programming and it all gets ignored anyway.

  • Small Company problem : The devs say they are working but i have no idea on what or when they will be finished or whether it will work at the end of it.

My guesses as to why developers often don't like it are:

  • Developers don't see the Big Company problem. We get the well defined specs and write some code that satisfies it. Easy.
  • Developers LIKE the small company problem, we get to be all silicone valley startup rock stars! yeee haa!
  • Scrum has a billion meetings and meetings are shit.
  • Estimation is a hard and thankless job.
  • Developers HATE sales people and 'agile coaches'/consultants/scrum masters/Martin 'so called' Fowler if that even is his real name! etc are basically selling agile.
  • "We have to do months of requirement gathering and document writing before we can even start programming and it all gets ignored anyway." Early prototyping is used also outside of agile. – Giorgio Jul 16 '17 at 19:02
  • I dont think we are going to come to a right answer here, you should write up your experiences as an answer so we can learn from them – Ewan Jul 16 '17 at 19:15
  • I'm struggling to see how your setup works, if there's no estimating, no evaluating, and seemingly no control over the backlog. I can see how it makes the team happy, and how it produces some kind of product, but how do you make sure you're building the right thing, and have it done on time? – Erik Jul 17 '17 at 11:06
  • The transparency enables project managers to see what is happening and how quickly. The quick release cycle means the product is immediately in the market and can be evaluated – Ewan Jul 17 '17 at 16:28

Not the answer you're looking for? Browse other questions tagged or ask your own question.