15

I've worked in a number of small teams over the last 9 years. Each had the obvious good practices, such as short meetings, revision control, continuous integration software, issue tracking and so on.

In these 9 years, I've never heard much about development methodologies; for example, there's never been a "we're doing scrum", or "lets do agile", or anything more than a passing reference. All of the teams seemed to function fine, without following much process, we were just freeflowing and just naturally worked well.

Has anyone else progressed for long periods of time without encountering scrum/agile/etc?

The only exposure I've had to these is through sites like this one. I read questions like Sprint Meetings - What to talk about ... and all the talk seems to describe almost robotic like people who follow a methodology finite state machine. Is it really (though exaggerated) like that? I wonder if the people posting on the internet just loud supporters of "best practice", with similar textbook views, not really reflecting how people work... Or that I've encountered some teams making their processes up naturally.

Furthermore (I am in the UK, which may be relevant)... I think if a methodology were introduced to any of the teams I'd work on, they'd just reject it as being silly and unnecessary... then carry on. I'd tend to agree, following processes seems a bit unnatural. Is this typical or common?

Improve this question
1
  • 2
    The idea of "Process" is intended to teach managers what the good practices to produce consistent and correct results. Managers don't really know these things, and don't realize that they are part of the problem sometimes. "Do we do X?", "No? Well we do now, and I need it next week!". Management in turn uses those processes to try and turn their technical people into assembly line workers. So yes, I agree, process for process sake is insanely stupid--and insanely expensive.
    – Berin Loritsch
    Nov 5, 2010 at 11:52

6 Answers 6

Reset to default
19

Over 20 years of development experience here, and I've never used a formal methodology. Never needed them, and I dont plan on using one in the future. Methodologies might be fine for some people, but they are no substitute for skilled programmers who write good, tested code.

Personally, I think it would behoove a lot of people to care less about following the day's hottest new methodology, and focus more on code quality.

Improve this answer
0
10

Honestly, if your small team has been working without major incidents well for all these years without thinking of process, you were probably doing some form of agile. All an agile process means is that it complies with the "Agile Manifesto" http://agilemanifesto.org/ which has surprising little to say about iterative, story boards, etc. The very first tenant of agile is that you prefer "Individuals and interactions over processes and tools". Any team that works well together doesn't really need to think hard about process.

The different brands of agile (like Scrum, etc.) are very useful if you have a brand new team that isn't used to working with each other. They kind of set the framework for how to build a cohesive team, which in turn will build a cohesive product.

If what you are doing is working, keep doing it. If you are constantly late with deliverables, having to routinely pull overtime, or having to fix major bugs after you deployed something--then something is wrong. That's when you make a series of small changes to fix the problems.

Improve this answer
5

If everything is fine and it's always fine then there's no problem - so introducing a new (your teams will have been following some sort of methodology - formal or otherwise) methodology would indeed be a waste of time.

Where methodologies really help though is when the team encounters problems or has problems put on them from external sources - a methodology doesn't just introduce good practices it helps you protect them. It is much easier to maintain good practices under stress when you're consciously doing them otherwise they can rapidly get squeezed out.

I don't think you necessarily need a formal methodology - but every team needs some sort of pattern (not necessarily repeating, it could be event driven) to their work to be effective IMHO.

Improve this answer
1
  • 3
    +1 All teams use a methodology, whether it be formal or not, or whether it be working or not.
    – Michael K
    Nov 5, 2010 at 12:36
4

If you have no problem to solve, lucky you.

I've seen many teams (especially in very small companies) working well without any defined methodology.

Implementing a methodology (or technique) because it's fun or because you read that blog post on the internet is very dangerous.

If you are fine, don't change anything. Just try some optimizations when you can.

Improve this answer
3

There are a vast array of methodologies out their, some quite sensible, some bordering on the insane. They all seem to codify common sense, give them a funny name, then sell a lot of books/seminars/etc.

Now if your management, or indeed your team, are lacking in common sense, and do not organically have their own sensible methodologies in place (whether consciously or unspoken), then they may be worth study and then taking on board the parts of the methodology relevant to that team's experiences.

Blanket imposition of the latest <insert-buzzword-here> working practices is liable to cause more confusion than it aims to solve. But typically can provide lots of checkbox metrics that a non-coding line manager can tick enthusiastically.

Improve this answer
1

Maybe you didn't call it agile or scrum but that does not mean you had no process and were not using it.

Just like software development itself. You will probably be using several design patterns even though you do not explicitly think about them by their names.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.