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?

SomeDev
  • 97
  • 4
  • 3
    "avoid asking subjective questions where … your question is just a rant in disguise: “______ sucks, am I right?”" ([help/dont-ask]) – gnat Jul 16 '17 at 17:30
  • Well, I'm actually asking for the success factors (sic!) of "traditional" projects. – SomeDev Jul 16 '17 at 17:32
  • see [Why do 'some examples' and 'list of things' questions get closed?](https://softwareengineering.meta.stackexchange.com/a/7538/31260) – gnat Jul 16 '17 at 17:33
  • One success factor is sufficient, I'll appreciate your contribution. – SomeDev Jul 16 '17 at 17:34
  • 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
  • Scrum is nice to get out of a ditch, to have a reference. If you are doing well already it will most likely just destroy a lot of goodness going on. Here's my take: https://softwareengineering.stackexchange.com/questions/349336/how-to-develop-excellent-software-with-agile-methods/349346#349346 – Martin Maat Jul 17 '17 at 05:33
  • If you think SCRUM is same as Agile, I recommend watching this video : https://www.youtube.com/watch?v=hG4LH6P8Syk – Euphoric Jul 17 '17 at 08:18
  • 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 09:33
  • 1
    @ThomasJunk Which is why first sentence of [Agile Manifesto](http://agilemanifesto.org/) is "Individuals and interactions over process and tools". – Euphoric Jul 17 '17 at 11:38
  • 1
    @Euphoric or as I wrote in another comment: »Independent from actual methodology, the secret sauce of "agile" is to emphasize the role of communication« – Thomas Junk Jul 17 '17 at 16:40
  • @SomeDev: Maybe you can find interesting insight in this book: "Agile!: The Good, the Hype and the Ugly" – Giorgio Jul 17 '17 at 18:25
  • Processes never make software better. They may make it more or less expensive to develop, that is all. – Frank Hileman Jul 19 '17 at 02:26
  • @Ewan Have the agile projects you've been in been light on processes? – user253751 Apr 09 '19 at 00:40

4 Answers4

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

Community
  • 1
dagnelies
  • 5,415
  • 3
  • 20
  • 26
  • 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
  • " 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." this is my life – user1450877 Jul 17 '17 at 12:09
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".

juhist
  • 2,579
  • 10
  • 14
  • " 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." Can you tell me where in "agile" does it say people are identical? Hell, "waterfal" is where people are considered "resources" to be plugged into process. – Euphoric Jul 16 '17 at 20:27
  • 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
  • Why are you equating Scrum with Agile? And I agree that what you described is not good. Which is why Scrum is the worst "agile" methodology. – Euphoric Jul 16 '17 at 20:36
  • @Euphoric: because "agile" by itself is just a vague buzzword/philosophy without clear definition perhaps? – dagnelies Jul 16 '17 at 20:46
  • 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 05:20
  • People is only replaceable when they add no value at all to the project. That's what predictive (aka waterfall) do best. Withdraw any human importance and influence into the whole project. Fortunately, in today's software developments, devs are persons not robots, developments are rather crafted than assembled in a assembly line. Software factories (even the name smells to waterfall) have been proven to be utopic (at the moment). Waterfall subyugate everything to the plan. Success is measured according to how we stick to the plan rather than providing usefulness and value to the project. – Laiv Jul 17 '17 at 06:29
  • @Giorgio So you are saying that it is normal, or even optimal, for one person to be single source of truth. So that this position guarantees him immunity from being removed from the team? And that the risk of him having an accident is not worth spreading that knowledge around other people in the team? – Euphoric Jul 17 '17 at 07:48
  • »I would say what differentiates satisfying projects from those that aren't is the presence or lack of good project management« Definitely: yes! The key to successful projects is really simple, but hard to accomplish: good communication (structures). Independently from actual methodology, the secret sauce of "agile" is to emphasize the role of communication. So the answer to the question above is simply: If your waterfall projects were better than your "agile" ones, then communication was better doing waterfall. Agile offers you structures, but it is up to you, how you use them. – Thomas Junk Jul 17 '17 at 09:26
  • 1
    @Euphoric: You contrast an extreme with another one, and since one is bad, you conclude that the other must be good. There are lots of intermediate shades between black and white. E.g. one developer can be specialized on one module even though others review his / her work and would not have big difficulties to take the work over. This is neither "one person to be single source of truth" nor "everybody is the source of truth". The latter often means that everybody works on all possible tasks and nobody is a real expert in any of them. – Giorgio Jul 17 '17 at 17:18
  • @Giorgio Can you point me to any Agile proponent who claims what you are saying? Or is it just something you imagine is true? Also, assuming you worked in "agile" environment, did you try to raise this problem with whoever was responsible in implmeneting/running the agile process? – Euphoric Jul 17 '17 at 17:29
  • 2
    @Euphoric: Maybe it is not the official position of the agile proponents (however, see e.g. https://www.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.

Telastyn
  • 108,850
  • 29
  • 239
  • 365
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.
Ewan
  • 70,664
  • 5
  • 76
  • 161
  • "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