Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I work for an engineering consultancy who do a combination of industrial design, mechanics, electronics and software. By their nature - or perhaps simply by history - the overall development philosophy has been waterfall. But when I joined I was surprised that Agile, which I would now say is an industry standard, had barely been heard of. For me, whilst I remain skeptical of Agile, I recognize its benefits for both developers and clients, and have been keen to promote its use.

It seems clear to me that you can't build hardware in an Agile fashion. It's just too time-consuming and expensive to "refactor" a physical thing. This means we are moving towards being software-Agile and hardware-Waterfall, and the Project Manager is struggling to make the two work together. Worse, it becomes difficult when we are faced with providing clients with a definitive cost for a project. Agile doesn't do uber-plans, and velocity projections require a project to be up, running and a few sprints to have passed to be meaningful. This means we tend to over-estimate as contingency, driving up our prices and our competitiveness goes down.

Seems to me then that either

We sell Agile explicitly to the client, and get their buy-in to receiving new software iterations per sprint, being able to add to the backlog and prioritize the next tranche of work. We persuade them that this is a no-bullshit way of working, and that waterfall is unrealistic and results in overspend. The Product Owner is from the client in this model. How then do we approach contracts, saying how much we charge for the software? How do we avoid the impression that this is an open-ended revenue stream in which it is in our interests to take as long as we like?

We adopt Agile internally only. The Product Owner is one of our guys / girls. The client just gets an alpha/beta/release version of the software as in waterfall. If we're over time, do we then fudge the slippage in the final phases? Is this even Agile?

In short, having a contract between us and a client seems a very un-Agile way of doing things. And yet waterfall is doomed to fail in an environment where we see every day that not only do we not understand the problem domain on day 1 of a project, neither does the client. And how do we do Agile for software and waterfall for hardware - is there software that can handle both under one umbrella? How do we marry these worlds?

share|improve this question
    
What do you think "Agile" means? –  pdr Aug 5 '13 at 13:48
    
I think it means delivering software to clients in a number of short bursts rather than large chunks, and allows the client to adapt the software to their evolving understanding of the problem domain. Thus amortising some of the risk that a Waterfall uber-plan would introduce. I see Agile as one way of embracing the iterative nature of software, rather than fighting it. –  Julian Gold Aug 5 '13 at 13:55
3  
That would be Scrum -- or, more generically, Iterative Development. Agile is a much wider net (more a philosophy than a methodology) and you're not going to unconfuse your situation by using terminology incorrectly. –  pdr Aug 5 '13 at 14:03

3 Answers 3

"If you only have a hammer, then every problem looks like a nail".

Agile is a very good methodology that has gained (with good reason) wide acceptance within the developer community.

However, it's not the only game in town and it's not always the right answer. (Code for deep space probes and avionics come to mind).

Is Agile an industry standard in your industry? (Not development in general, but the specific business you're in). It sounds like that may not be the case. Your customers aren't asking for it and the hardware guys don't want it or need it. (Agile requires additional effort from the client that may or may not be available).

If you're going to adopt it, make sure you're doing it for the right reasons & not just because all the kids on SO or P.SE are doing it.

If you decide to move forward anyway, take it slow, start using it internally only, and build up a track record. Adopting a methodology is a corporate culture change and those never happen quickly.

Be patient.

share|improve this answer
    
Thanks Dan. To be fair, I am quite new to this branch of industry so can't really comment on what is standard practice. Whilst I am quite aware of the Golden Hammer Anti-Pattern you quote, I'd wonder what the alternatives are - Agile Hammer vs Waterfall Chainsaw? Waterfall failed because it was inaccurate and was inflexible to changes in requirements (both as a necessity of development and from the client's perspective). So either I'm missing something, or these are - broadly - the only shows in town? –  Julian Gold Aug 5 '13 at 14:04
1  
Waterfall works great for Mars probes. It fails when you try to use it in a high-change business environment where either the specs are constantly changing or the client doesn't know what he wants (which ultimately is the same thing). Do your specs change often? –  Dan Pichelman Aug 5 '13 at 14:12
3  
@JulianGold remember, agile is not a methodology, it is a set of principles from which one can form their own methodology, or use other methodology's that were formed to attempt to meet. If you don't understand the principles, chances are you'll use one of the methodologies based on them incorrectly, so learn the principles from agilemanifesto.org first to avoid implementing halfarsedagilemanifesto.org –  Jimmy Hoffa Aug 5 '13 at 14:15
    
@DanPichelman our experience is that, at the start of a project, the clients think they know what they want, but towards the end they realise they don't and that's when the goalposts start shifting. Whilst it's not true for all clients, it's true for those with the larger projects from startups who come to us seeking to implement their Big Idea. –  Julian Gold Aug 5 '13 at 14:33

I think you need to investigate the "type" of Agile you need to adopt. Scrum is one form of agile that adapts well to software development when there are new features to be developed. Kanban is another form of Agile that sometimes applies better to groups who can't commit to a fixed interval to solve problems like maintaining developed code with mostly bugfixes. That's only two types of "agile" and there are more you can investigate. From what others have answered before, agile is designed to help you adapt a flexible process to your company's needs.

Our company has put both software and hardware teams on scrum. I can't comment on how it's going for the hardware team, but it helps the software guys on scrum to line up their schedules.

share|improve this answer

The model of Agile you use should always be tailored to the environment, so that the process delivers tangible value to the client. A key benefit of Agile is that value is delivered early, and clients like that. After seeing it in action, they start to accept the approach.

In your case, the hardware guys will only deliver working kit on day X. What happens before day X? If you were working on a waterfall approach, when do you start code design and construction? How do you test code before the h/w is built? Do you use an emulator?

Go slowly, using Agile internally. Not every client will want to be part an Agile "experiment" (as they would see it). Build up a track record of sprints and velocity. With known velocity, new projects can be estimated more accurately than previously. Then the company can sell the Agile approach to interested clients. Agile requires extra commitment from the client, and not all clients will want to be in it, until they see what the cost difference will be.

share|improve this answer
2  
sprints and velocity are part of scrum not agile. agilemanifesto.org –  Jimmy Hoffa Aug 5 '13 at 14:11
    
Keeping it internal for now makes most sense. But: a problem we faced was when a client asked to see "The Software Plan" or "The Architecture". I am sure they were not tech-savvy enough to understand the details, but being a bit Agile we had avoided such uber-designs, and found ourselves bullshitting our way through these conversations. –  Julian Gold Aug 5 '13 at 15:58
1  
Agile is NOT an excuse for not having a plan, or not having an architecture. If you find yourself having to bullshit your way through a design conversation it should be a huge red flag to you that something has gone wrong. –  Vicky Aug 5 '13 at 16:36
    
@Vicky I don't quite understand what you mean. The Agile Manifesto asks us to value working software over documentation. Any a priori plan is therefore relatively meaningless, and if it weren't, we wouldn't have to do Agile, we'd just be back to Waterfall. –  Julian Gold Aug 7 '13 at 8:36
    
The Agile Manifesto tells you to value working software over comprehensive documentation. Firstly, that doesn't mean not having an architecture that has been properly thought through; and secondly, it does not mean that the documentation has no value at all - just that is has less value than the software itself. –  Vicky Aug 7 '13 at 12:43

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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