2

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?

Improve this question
3
  • 1
    What do you think "Agile" means?
    – pdr
    Aug 5, 2013 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, 2013 at 13:55
  • 4
    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, 2013 at 14:03

4 Answers 4

Reset to default
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.

Improve this answer
4
  • 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, 2013 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, 2013 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, 2013 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, 2013 at 14:33
2

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.

Improve this answer
6
  • 2
    sprints and velocity are part of scrum not agile. agilemanifesto.org
    – Jimmy Hoffa
    Aug 5, 2013 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, 2013 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, 2013 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, 2013 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, 2013 at 12:43
2

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.

Improve this answer
0

At SKA Observatory (SKAO) we have decided to move to agile software development based on the Scaled Agile Framework (SAFe®). The reasoning to go with such a model is that it allows for integrating both agile and non-agile developments (mostly suppliers) to be integrated, and that is was just based on Scrum.

There are many consultants around the world that can provide SAFe training, and for an international organisation such as ours that was a major influence, together with the established Glossary, that allows for a shared vocabulary across all participants and organisations.

The work that needs to be done to deliver the SKAO telescopes is quite diverse, and goes from concrete foundations for the SKAO dishes, to understanding the ionosphere behaviour, together with the many disciplines related to radio astronomy engineering (electronics, signal processing, interferometry, high-performance computing, control systems), and then the scientific interpretation of the results.

However, we did not just start with all teams from the start, but we devoted around 2 years prior to the start of construction to train some core people, that later become trainers for others, but also started with just 4 teams in our first Program Increment (PI1) in December 2018, while our next PI planning (PI14) will take place in March 2022, with more than 20 teams distributed across 3 Agile Release Trains…

We even managed to get our stakeholders to do major planning simultaneous to PI planning, but the overhead was too big for them, and now we will revert

The main success factor for agile is delivering working software (or other kind of engineering artefacts, or products, if you go beyond software), but that is only achievable through interaction, and Plan-Do-Check-Adapt cycles.

As long as you define a cadence, plan the work for that timeframe, execute the work, and then check what went well and what not, and adapt to that, you will keep improving your delivery.

Maybe you could find useful the article we wrote exactly on how we apply those agile principles to our software (and systems) engineering: Scaling Agile for the Square Kilometre Array.

Improve this answer

Your Answer

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

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