Are you an agile/pragmatic developer in a waterfall organization?

Question

If so, how do you deal with things that just don't "feel" right such as:

• not writing unit tests
• not having a continuous build
• not refactoring
• not having a team coding standard
• not pair programming
• not doing iterations
• no daily standups
• no retrospectives

Now, some agile organizations do leave out some of these practices, but most successful ones incorporate most of them.

What do you do to deal with the seeming chaos of the traditional development processes?

Answer 1

Why are these practices incompatible with waterfall? As far as I can tell almost all of these if not absolutely all of them are possible with a waterfall approach. There is no particular reason waterfall development has to be chaotic. It may have other drawbacks/challenges but chaos is not likely to be high on the list.

Answer 2

Actually, I'm a Waterfall developer in an Agile organization.

Things that don't "feel" right to me include:

• Starting work on a project with barely any idea what it should do.
• Documenting the processes, but not the products; being unable to get information without having to go talk to someone. All I should need is a Requirements document, a Design document (which I may write myself), and Google.
• Spending more time in meetings than coding.
• Spending more time coding at home than at work.
• Having no idea when the project will be done.
• PM's being useful in any way.
• Having a meeting to prepare for a meeting to prepare for a meeting where somebody else logs onto a server and copies a file; thus spending six hours on a process that takes six minutes
• Multiple checkouts
• Knowing how something should flow, but not having actual requirements.
• Developers' unique skill sets are downplayed or outright ignored as they make the developer non-interchangeable.
• When there are no stories remaining... nothing to do... just kinda sit there... Could be adding a new feature; may not be needed but the time isn't being wasted...
• Every six months when I change contracts, I have to adapt to a new coding standard? By the time I get used to it, I'm already looking for my next contract.

Answer 3

Firstly, Agile methodologies emphasize on these practices but they have not introduced them. They have been there in software development process well before Agile came in. So simply saying that if you are not using Scrum/XP/RUP then you are not following these practices is plain wrong. If you are a professional software development organization, these practices will exist in one form or other.

Secondly, whether you are an agile developer in a Waterfall organization or vice-versa, you can not do much, at-least not effectively or significantly. What development 'culture' the organization has is a function of the commitment and focus of the management and executive. If that does not exist, you can do your 'bit' but you will lose out in the end. That is the reason Agile fails in many organizations when they transition to it, because they are unwilling to make the cultural change.

Answer 4

I'm in a pseudo agile organisation and here's my responses to those points you raised:

• not writing unit tests: I'm a believer in 100% coverage. And yes it is easy to say you can have 100% coverage and write really bad tests, however, any new code I write, I do my best to have acceptance or integration tests and have 100% coverage for what I work on. In the build, I have put in a coverage check to make sure it doesn't drop below the current limit.
• not having a continuous build: Because of the way everyone has worked prior, most people run the build without the coverage check and therefore can willy nilly check whatever they like in without it being tested. Not to mention the continuous build sometimes seems to be on and sometimes seems to be off. I am very close to just setting up a CI box of my own.
• not refactoring: I refactor whatever I can so I don't throw up when I see that same class again.
• not having a team coding standard: The company has a coding standard, however, there are many things that are wrong with it. Therefore I do my best to bring things up with those higher up to get it changed. It hurts sometimes to code the way they think is right. e.g. putting huge java comment section headers for the public, private, protected, fields, constants etc throughout your file. I believe this was done once upon a time because classes got so out of control (e.g. thousands of lines long) that they needed section headers so you could find where your public methods started and where your private methods started(!!)
• not pair programming: Fortunately I have someone who thinks like me sitting behind me and we turn our chairs to talk and discuss ideas as often as possible to compensate.
• not doing iterations: We have 3 week iterations, but it feels very ad hoc. There is a cleanup/review week in between each iteration which makes it theoretically a 4 week iteration. I can't do anything else about it. It's hard to convince them to make those iterations shorter because the code is so bad is actually takes 3 weeks to write something that should take only 1 week.
• no daily standups: We have standups.
• no retrospectives: We have retrospectives.

Answer 5

Seriously, if your organization is as chaotic and amateurish as you describe, I would start looking for another job before they go under. As Martin Fowler once quipped

If you can't change your organization, change your organization

If, on the other hand, you feel like they can change, then I'd make an attempt to start that change by introducing retrospectives before anything else on your list. If you can get people talking to each other and starting to identify the waste that goes on, and someone involved has sufficient mandate to listen to that feedback and make changes, however tentative, you'll be on the right track.

All of the other practices you've identified are techniques for eliminating particular types of waste - writing unit tests, for example, to reduce the waste of fixing defects later in the project. By holding retrospectives you'll shine a light on these wastes and give people a space do decide they might like to do things more professionally.

In the end, it's about self-respect: yours, your colleagues, and the organization as a whole. Are you satisfied to just muddle along the way things have always been, or do you want to try to be as good at what you do as you possibly can be?

Good luck!