Which programming methodology would be a good fit for us?

Question

Unfortunately, somebody has taught our upper management the word "Agile" and now they want us to move towards it. I have a peripheral understanding of agile (in principle) but have never used it in practice. From what I know, it will not be a good fit for our organization. Right now, things are pretty grungey. Here's how it is;

We're a very small team - two developers, one DBA, one designer. The company I work for makes a disproportionately large amount of money relative to its size, and nearly 95% of that is pure online sales.

From a development perspective, we are subjected to many desk invasions during a typical day (we're tech support as well as dev), work can regularly just fall out of the sky at a moments notice if a sales team member promises something to someone. We do undertake larger projects too, and they're a nightmare with the constant interruptions. Some of us are starting to tear our hair out! Project plans are drawn up by non technical managers in excel spreadsheets, where they try and break the task down into bite-sized sentences that they can understand and put a date beside each one. These dates are always hideously unrealistic and often missed, and our meetings (which we have around weekly) are regularly filled with awkward moments with people asking "why hasn't this been done yet".

I am pretty sure Agile isn't the one for us. Now, given that (and i have tried) this company will not change its ways, and only the dev team is willing to change, is there a development methodology that we could adopt which is a good fit for just saving us some sanity?

Answer 1

Agile was actually designed to address many of the exact problems you are having. If management has truly bought in and won't pervert the process, you could see a big improvement. Let me address your issues point by point. My experience is with scrum, so I'll talk from that point of view, but I'm sure other implementations have similar benefits.

• work falling out of the sky These stories get put on the bottom of the backlog until the product owner and team can meet to agree to move it up. Its priority gets determined relative to all your team's other commitments, and that priority is visible to every stakeholder who is interested to look. It should be extremely rare to add a new feature in the middle of a sprint, and only the highest priority bugs should be allowed to interrupt a sprint. It's amazing how many "emergencies" can wait until the end of next week when that is made a regular expectation.
• undertaking larger projects You will have the visibility to show how short-term priorities impact your long-term projects. If people continually move user stories in front of your long-term projects that's okay, but in order to make that decision everyone will know the impact it will have on the long-term project's schedule.
• project plans are drawn up by non technical managers User stories are supposed to be written from a non-technical point of view, but your scrum team should be empowered to make estimates and determine implementation details.
• dates are hideously unrealistic Your team handles all the estimates, because you are the ones who know what you're doing. If those estimates aren't acceptable to the business, they must decide how to prioritize the features. If they need more work than you can handle, the need to hire more people will be clearly visible.
• dates are often missed First, your estimates will be more realistic, which should help. Also, you're biting off smaller chunks and actually finishing them, which helps the business feel like you have produced something useful even if not feature complete.
• meetings filled with awkward moments Agile has more visibility and a much quicker feedback cycle, with a product owner heavily involved. Your blocking issues and reasons for delay should not be a surprise.
• also doing tech support Contrary to popular belief, agile is not incompatible with a divided schedule. Scrum factors in your interruptions into your team's velocity. If you normally spend half of your time doing tech support, you will simply have half the velocity.

What mangement and sales must realize is that agile isn't a way to exercise tighter control over the development team, it gives the team more autonomy to do what they're good at while helping the business realistically consider all its priorities whenever assigning work to the team.

Answer 2

I would say take advantage of your managements whims! Sounds like they are doing you a favour and giving you some leverage to improve your working methods.

Say to them OK we will go agile it requires among other things:-

• a separation of development and support
• a formal requirements gathering process -- under control of the IT team. "Stories" etc. sounds all very vague -- but its actually a "formal" method dressed up to look informal.
• scheduling is under control of the IT team.

If they don't accept this then tell them you cannot go agile.

Answer 3

Agile isn't a programming methodology, Agile is a project management methodology. If upper management really want you to try this new buzzword that they've found, they need to be able to understand that the Agile method starts from the top and involves the management through every step of the way. If you need to give them a hard dose of reality, maybe organise a 30 minute Powerpoint presentation about Agile to give them a bit of education. Managers love Powerpoint.

However if, as you say, the dev team are the only people willing to change, then no development methodology will be able to help you. Without an alleviation of the rest of your duties, interruptions will continue to happen and you will continue to be asked to meet deadlines that you simply cannot meet.

My advise in this scenario is to educate, not berate, management as to how it really is on the front lines.

Answer 4

No software development and project management methodology can help in an organization where sales people dictate the day to day schedule. How are you supposed to manage a project amidst such a chaotic and distraction ridden work week?

So many upper managers see the value of Agile and want the benefits of it but they almost never are able to make the internal changes necessary to make sure the move is successful. The only successful Agile shops I have known of had started out that way. I can't recall a single instance in my professional experience of a sales managed or waterfall software development shop making the move because it requires a fundamental change in culture.

Is this change in culture possible? Yes, but in your case almost certainly not.

A change in culture is usually necessitated by a competitor threatening the existence of the company or a make or break situation or some other similarly involved situation to justify a re-org. In your situation, your company is at the complete other end of the spectrum where money right now is easy and everybody is getting fat.

Companies NEVER change from within when the money is easy. Why should they, they are successful despite the software development failures, not because of software development successes.

My final advice is that if I were you I would look for something better. People on here have great advice but I have seen this song and dance before and it just doesn't work in your situation.

Answer 5

look at extremeprogramming.org - XP is a form of Agile with easily understood aspects which you can pick and choose a la cart; a very good place to start

the customer commitment to not change their minds during an interation would be a good starting place for your environment, from the sound of it ;-)

Answer 6

If one considers the landscape of methodologies, both traditional and contemporary, one would realise that "Agile" is more of an "anti-methodology" than a methodology. Patterns aim to portray the "best-case" solution to a given problem within a particular context. Attempts to directly violate such a solution or pattern, are generally referred to as "anti-patterns" or worse-case practices. Likewise, while true software development methodologies attempt to prescribe best-case practices in developing solutions, "Agile" (Scrum, XP, etc.) attempt to directly violate any and all structure within the software development process, in favour of a haphazard, chaotic approach - which (of late), also seems to demand applause from (naive) onlookers.

With that said, it is appropriate to bear in mind the context in which the Agile philosophy arose. Although sophisticated iterative methodologies (e.g. Unified Process) existed at the time, the primary methodology was still the old waterfall approach, which prescribed a "best-practice" of complete requirements analysis, then complete design, then develop/code the solution, then implement the solution. Clearly, this engineering approach to software development was ill-advised - and resulted in heaps of paperwork before (and sometimes without ever) seeing an executable solution.

However, it still does not warrant the throwing out of the baby with the bath water, as was the case with the conjurers of Agile. The Agile approach almost enforces a direct negation of anything that was used prior to it - except maybe the actual coding of the solution. Clearly, this is an indication of limited insight on the part of its originators, or maybe it's simply a case of "there are none as blind, as those who do not want to see".

Nevertheless, the merit of agile is that it encourages streamlined processes and focuses on executable code - which is inevitably your ultimate deliverable.

NOW, to answer your question more directly:

Given your overview of your environment, I suggest you firstly select an Agile implementation (i.e. Scrum, XP, etc). Then customise the approach to suite your environment, delineating a clear process of how your team will be working, e.g.:

• Receive request from user(s);

• Prioritise user requests;

• Gage impact of enhancement on the existing system (maybe during your daily/weekly stand-up meetings);

• Estimate the development time of each enhancement - and communicate these back to various requesting users;

• Perform actual enhancement(s) on existing system (i.e. coding).

• Conduct user testing - and get commitment from the users (e.g. via email) that the requested changes has been successfully implemented.

This should provide some structure (and order), whilst also maintaining some semblance of an Agile approach.

With the above said, remember that the old English figure of speech, "As Agile as a monkey”, was not coined without reason!

Answer 7

I would say you need a methodology such as Agile is essential for your team. As your company is so disorganised you need to be more organised within your own dev team. I dont think however your non technical managers should have anything to do with it.

If your going to push back on your sales people and demand realistic deadlines you need to justify that with organised plans.

Also on a seprate note if they come to you with estimates without consulting technical then just refuse them point blank.

Answer 8

Perhaps focussing on the incremental/iterative aspects is what both your team, and the fall-out-of-the-sky stakeholders need to be able to deliver regularly and consistently. Over time, the sales team and management will gain faith in that when they put in a new feature request, they can be sure your team will deliver in a suitable timeframe.

Of course, you need to invest in unit/system/regression testing, automated builds, dogfooding, etc, to get there if you're not there already.

Answer 9

First I'd suggest gathering some data. Sit down at a quiet time and figure out what the status quo really is- how things get done. If management is hell-bent on implementing something they can call agile, then figure out something that would work for your team, draw up a document, slap "Agile" on the name and you're good to go. Keep in mind that the only thing they really know about agile is the word, and some vague association with quickness for its usual definition in English. So what I'm advocating is that your team gets out in front of the issue, finds a flavor that works for you, and then presents that to your management as the Agile(tm) way. Otherwise some PHB is going to pick up a book and try to fit the square peg into the round hole and no one will be happy.

If you go with a "pure" form of agile it may be tough with your team having to fulfill the support role as well. Let's face it, your boss may find it difficult to accept members of your team responding to the help-desk requests by saying "let me create a backlog item, I'll get to that in (time to end of sprint) weeks."

The biggest hurdle is the money one. If everything is green gravy, it is much harder to say something is wrong and needs to change.

Best of luck.

Answer 10

On the contrary, it sounds to me like an Agile method is exactly what you need in order to deal with missed deadlines, unrealistic expectations, and poorly planned projects.

Your management have indicated that they are interested in this new Buzz word. Most likely they will want to use it to hype up the marketing of your products. this isn't necessarily a bad thing, but it will need to be managed very carefully if you want to make an Agile method work for you.

Half the battle is getting buy-in from management. Having them receptive to the very idea of Agile is most of the battle. The rest is to make sure that their expectations are managed so that they continue to want you to be agile, and to avoid them becoming disenchanted when and if your managers feel as if their control over project management is largely slipping through their fingers.

Before your company decides anything, I would recommend getting in an Agile coach to do a half day seminar and workshop. Get you all thinking as a team - managers and developers alike - about what it is about Agile that you feel will work for you, and what you feel won't. If on the other hand the management trust your judgement, then you will need to become very familiar with a number of Agile practices and Methods, and create a seminar or your own. Personally, I'd steer towards getting an experienced coach in, so that you don't waste a lot of time, and to maintain the momentum. In the meantime, grab a copy of a couple of good Agile books as references, read them thoroughly, but also leave them hanging around your desk where management can see them. Subliminal psychology can work wonders in a situation like the one you've described.

I'd recommend at the very least to read the following:

• Lean Software Development - Mary & Tom Poppendieck
• Agile Software Development - Robert C. Martin

and for extra credit (because I think it's a great companion for the other books I mentioned):

• Clean Code - Robert C. Martin