Agility for all industries (not only software)


Agile concepts come from software development but Agile practices and tools are now available to all industry sectors: from innovative services to Heavy Industries.

Project management evolution

The need to increase productivity, theorised by Taylor and applied by Ford in the 30's, formalised the flow-chain work, Gantt charts and waterfall model (cascade or even V models). Then, the urge to master quality, structured since the 70's with ISO or 6 Sigma, brought Continual Improvement Process and Matrix Management.

Unfortunately, these approaches are no longer enough to tackle today's challenges:

  • Innovative projects (product, service or process) / early stages, creative challenges
  • Projects with many uncertainties / Projects being always late (for no reason)
  • Complex projects (Gantt chart too unwieldy) / multidisciplinary teams, multicultural, multisite...

Agility answers these industrial challenges and needs

Agile applied to industry

Agile in the dictionary: adjective

    Agile 1: Able to move quickly and easily.

    Agile 2: Relating to or denoting a method of project management.

What does "Agile" mean for industry?

This website is fully dedicated to Agile project management applied to industrial projects; this means "Agility outside its original domain: software development".

Where can Agility fit in industry?

    Agile Early phases of physical and concrete projects.

    Agile R&D, research or innovation programmes.

    Agile R&D / R&T teams, multi-projects, multi-disciplinary teams.

    Agile Multi-sites, complex or innovative projects.

    Agile Hybrid development methodology, mixing Agile and traditional methods...

Need for Agility?

If your projects are on time and on budget, and if the teams are motivated: NO NEED for Agility.

Agility can be necessary if you notice that:

    Agile Gantt charts are fake and false since day one.

    Agile Most of the project are late, and delays are discovered late in the project.

    Agile The setup (or attempts) of burdensome procedures actually delay the project even more and/or harm its quality.

    Agile 'On-time' projects are managed by small fighter teams only, in specific conditions.

    Agile Your talent-pool doesn't like to be told HOW to do its job and you finally lose common communication ground with them.

    Agile Teams are snowed under, with too many projects, bad priority management and so many changes.

    Agile Projects include many techy and costly parts but no fresh ideas.

    Agile Ideas arrive too late in the project to be included.

    Agile Failures with traditional project management approach…

Identify projects that could benefit from Agility and evaluate the benefits of Agile project management in your industry. We will help you to evaluate the means and skills to develop to become an Agile company (starting by a pilot project and team?).

Traditional project management

Fundamentals of project management

Project management is the practice of initiating, planning, executing, controlling, and closing the work of a team to achieve specific goals and meet specific success criteria at the specified time (Wiki). As early as possible, the first reflex is to plan for everything:

    Agile Description of what we need to deliver

    Agile How we'll achieve the result

    Agile List of risks and problems that may occur, and ways to sort all this out

    Agile Precise date of many events to commit to (with some security margin)

The waterfall approach (V / cascade model) is very suited to a predictive mindset (we plan for everything early on, and then we just stick to the plan) : we can list the tasks to do (WBS) and we establish a schedule (Gantt Chart). Then, we can start with the certainty of being on time... what can go wrong?

Cycle en V
Terms vary from one company to another (conception / production...)

Advantages of waterfall model

Advantages of a predictive approach, waterfall and so, are attractive: Easy to turn into a contract, the team faces its responsibilities. The team will have to endorse any mistake in evaluation, analyse, production and any problem occurring during the development time (whether its fault or not). Management and client think they love this (but are they right? Is this realistic? Is this good for the company, the team, the product? Good for THEM??)


Limits of predictive approaches (waterfall, cascade, V...)

Anticipating everything, planning everything from day one... this is attractive but is it always possible and/or beneficial?

    Agile Risk management: Is it possible to foresee all the risks and try to cover them before the project starts? Should we only start the non-risky projects? What happens if a problem occurs and it was not listed as "risk + solution" item?*

    Agile For some projects, listing all the features / functionalities from day one is not that simple (maybe impossible). It does not look suitable to start a waterfall without a solid definition of what we'll do.**

These projects are not appropriate for traditional project management, they would highly benefit from an Agile approach.

* Sometimes, trying to prevent ALL the problems is not helping and, to quote Megginson, "According to Darwin’s Origin of Species, it is not the most intellectual of the species that survives; it is not the strongest that survives; but the species that survives is the one that is able best to adapt and adjust to the changing environment in which it finds itself". In our vision of Agile we propose a flexible and efficient way to MANAGE the risks (not run away from them).
**Agile is perfectly compatible with innovation teams, where knowledge and content grow and improve during the project.

Agile project Management: What projects? How to apply?

Suitable projects for Agile Management

We could manage any and all projects with Agile but it would be a big mistake to do so: traditional project management (waterfall / cascade / V) is most appropriate in many cases (e.g. repetitive production). Managing Agile will allow you to use it for the right projects (innovative, creative, complex...) and at the right time (early phases or during hybrid project management). Simply put, Agile is very suitable for projects you cannot fully define on Day One:

    Agile Design of products or innovative services

    Agile Creative and innovative projects (R&D, design office, research…)

    Agile Complex projects (when one brain is not enough because of complexity: multi-sites, multicultural, multi-sectors…).

Agile management: How to apply?

For these projects, Agility will bring flexibility and the right amount of process to achieve objectives (instead of random unrelated tasks). This is done by iterations:


Iterative incremental for Agility

Incremental (repetitive cycle)

Agile itératif


Iterative (adding content)

Agile incrémental


Iterative incremental (mixed with our smart risks management)

Agile itératif incrémental


We adapted this iterative incremental paradigm to industry

Iterative incremental development cycle, generally represented with circles and spirals, represent the real pulse of a small creative team without any constrain. Agile has structured these practices to provide the same benefits to larger teams. One thing though: circle and spirals show the rhythm but don't forget that Agile projects also have a start and an END! Actually, it's more about having a succession of small waterfall projects. Small enough to be easy to set and to achieve, large enough to demonstrate progression and allow driving correction.. Every single iteration is a mini V-model project adapted to Agile, the whole project can become Agile.

(c)Agile Methodology. Cycle Agile Industrie

History of Agility


Agility is not the invention of a consultant but the formalisation of good practices noticed in small creative teams, self-organised, working in the 80's in the computing industry.
You'll find the complete history of Agility on Wikipedia; we'll focus here on its progression since the software development era.


The little (hi)story

Pascal Jarry, founder of SolidCreativity in 2004 after he spent 20 years developing and managing video game development teams in 3 languages on 3 continents, remembers: « we were conversing with other managers during international conferences and we all had the same problems: Teams were growing, projects and technology were more complex, each attempt of structed organization was a disaster (yes, we tried the waterfall model on video games) and we were killing creativity, team motivation, gameplay and Xmas release dates... Adding structure at bad places, using V model for example, was really detrimental. We were also debating what was working for us and, guess what, it looks like Agile ;). So when our industrial clients were struggling with innovation projects, we decided to adapt our knowledge to their specific needs».

    Agile Agile tools and concepts first came from software development processes but SolidCreativity adapted the Agile practices to all creative and innovative sectors.

Is Lean Agile?

Many approaches are designed to improve project management (and some do, in specific conditions). Lean, for example has similarities with Agile (visual management…) as they share a common ancestor; some people even announce that Lean is Agile (we don't). We must remember though, that Lean is designed to improve predictable or repeatable actions: you can Lean a production process. This makes Lean the perfect candidate to improve efficiently the projects being well managed with traditional project management (waterfall, V...); Agile works better for innovation projects and original creation.


Adaptation of Agility outside the software development world

If we can't Lean everything, we also can't apply Agile everywhere everytime. As early as 2002, SolidCreativity studied the modifications to transpose The Agile method Scrum (100% software oriented) toward other industries. Our conclusion is that even Scrum (with our fine-tuning) can be used under some conditions:

    Agile Project must be appropriate (innovative, R&D…). Absolute condition: it cannot be a project you've already completed a thousand times.

    Agile Domain is irrelevant (heavy industry, research, journalism…)

    Agile It needs some effort but you won't regret it!


For the organisation coaching the company:

    Agile They must UNDERSTAND Agility, they must not stick to the dogma. Some parts are kept, some are adapted, and some are discarded

    Agile You must adapt you pedagogy and examples, as we did, to transpose Agility for other audiences

    Agile With the teams, you need a strong educator to explain (and not just present) the concepts, limits and advantages, and pray to exit the training room alive ;)

    Agile Agility is not only about Scrum; you must introduce a global Agile approach (mixed project management for example, not just tools/artefacts/meetings).


Agile in other industries: Is it a trend?

When Agile hit software development, some claimed it would be a trend. Today, all the major software development companies use Agile.
Since then, Agile has flourished outside the software industry and has proven its efficiency in many other sectors, as stated in this Forrester Institute study of 2013:

“Agile is not only used in several of the world’s leading companies now but is being applied in areas beyond software development. (…/…) some companies are applying Agile to areas within the organization such as, portfolio management, project management, vendor management, contracting, etc.”


Many industries are satisfied by Agile

Companies like Google, Apple or Microsoft are Agile, of course, but many more companies such as ArcelorMittal or Airbus as well. This is the Airbus testimony on they innovation project method called SPRINT: Read the article and read their feedback on our Agile training.

Agile comparison


All the themes in this table must be introduced and explained one by one, directly to all the teammembers; Agility concepts are not easily understood or accepted when first met: Not by management, not by the teams either... this is very DIFFERENT from what we usually do.

What Agile brings Problem it corrects or situation it covers

Real time visual management

Administrative reporting

Shared objectives reached

Unrelated things to do, without vision or objective

Motivating and efficient risk management, suitable to innovation projects

Blocking risk management based on the fear to start a nex project

Iterative incremental progression between secured milestones, developing the project, the development process and the team each time

Waterfall / V model for all the projects, despite low compatibility, making teams guilty and hesitant

Auto-adaptive project management, aiming towards improvement

Rigid project management, well documented but impossible to apply and not serving the project or the team

Self-organised motivated teams

Infantilised team members always depending on management.

Project management adapted to the team working methods that can become ISO-certified easily

Standard, onerous ISO project management, even if it does not meet your needs

Empowered motivated team

Demotivaton, under exploitation of high-performers

Early detection of problems, allowing to found solutions collectively

Late detection of problems, killing the messenger and searching for the guilty

And, also, adaptation to modern teams:
- Multidisciplinary team mates
- Multi-sites and multicultural teams on the project
- Shared time and involvement across projects

Theoretical organisation looking good on paper:
- Open space without team work consideration
- Closed drawer policy
- Matrix management with no decision making

Agile applied to industry: What Agility brings

Well documented research studies show what Agility brings to the project and the team in project management (productivity, cost, motivation and time to market).

Increased productivity

4 studies show that Agility increases productivity:

    Agilite_necessaire Productivity gain of 16% (QSMA*)

    Agilite_necessaire 82% note a gain in productivity (DDJ*)

    Agilite_necessaire 23% say productivity increased significantly (VO*)

    Agilite_necessaire According to the University of Calgary*, Agility reduced the need for overtime work by 2/3.

Cost reduction

2 studies show that Agility reduces development cost:

    Agilite_necessaire 32% note a cost reduction, 5% a significant cost reduction (DDJ*)

    Agilite_necessaire 30% note a cost reduction, 8% a significant cost reduction (VO*)

Better motivation

15 months after adopting an Agile method, Salesforce found that 86% of its employees were having a "good time" or a "best time" working at the company. Measures were at 40% before Agile.


Faster time to market

    Agilite_necessaire 64% note a faster time to market, 23% a significant improvement (VO*)

    Agilite_necessaire 37% note a faster time to market (QSMA*)


  • QSMA (Michael Mah 2008) : Rigorous comparison of 26 Agile projects to a database of 7,500 primarily traditional projects. Agile projects ranged from 26–1,000 people
  • David Rico (2008) : Survey of 51 published academic and research papers
  • VersionOne [VO] (2008) : Opt-in online survey of over 3,000 people
  • Dr. Dobb’s Journal [DDJ](2008) : Opt-in online survey of 642 people

Book about Agile success in software development: Succeeding with Agile

  Contact form

Can we use the same Agile Method as computing engineers?

Often a faulty agility in software development?

In computing engineering, where Agility comes from, Agile is often reduced to Scrum method where people think that enough Post-Its on a board make a project Agile. When Scrum is the only Agile reference, people tend to accept things without understanding why it's there (what it corrects and how it fits in the whole), and it becomes catastrophic when they decide to adapt Agility to their "need". They remove important parts for no other reason than "I don't like it" or "it takes time" and the result is a fake Agility: roles are not clear anymore, not respected, meetings lose their purpose and become useless, user stories are not objective oriented but simple tasks... Most of the time you witness a team running a cascade structured project with Post-Its ;(. it's a shame and this is why some people say that Agile does not work... Sure, but have you tried real Agility?

Differences with software development?

Of course, many teams use Agility efficiently and reach their objectives (hence the positive study results). For the people practising an efficient Agility with computing engineers and willing to tackle other industries, they must understand the drastic differences with the other industry sectors, including:

  • In other industry sectors, the end-product is not often software, so iterative incremental progression is not about adding a function or code lines.
  • In other industry sectors, teams are not only programmers working full time on a program on a plateau… They are MULTI!
  • In other industry sectors, risk management is not only about starting (or not) a project, you must link it to the project life.
  • In other industry sectors, the huge variety of expertise and domains makes the "right quality" very difficult to reach (over-quality tend to appear easily, for example an extremely costly mechanical system to cover a faulty electronic).
  • In other industry sectors, the diversity of trades (including contractors) makes everything more complex, especially estimation, commitment and responsibilities.

The good news is that solutions exist and we'd be very happy to introduce Agility to new industries, to explain how we address their specific needs while keeping the Agile spirit and efficiency...

Agile project management for industrial innovative projects


While Agile is the "default" project management approach for software, this is not the case in other industries. Before considering Agile for your project(s) you can evaluate parameters like:

    Agilite_necessaire Kind of project

    Agilite_necessaire Development phase

When Agile is identified as suitable, then you can start introducing it, to a particular team / project and then eventually spread to services and other company locations.


Applying Agile outside computing engineering

Agility in computing is littered with specific wording, methods, cycles, processes, trades, tools... As in many things we had to master them deeply and adapt to other industries..


Example: Differences between developing software and conceiving an airplane

It's difficult for a person in charge of developing an airplane, to learn that Agile delivers several "plane" versions during the conception process, with different levels of completion. In the mind and in the reality of this person, a plane flies (with all certifications) or not, there is such thing as "half a plane".


Anyway, Agility expects (in an iterative incremental development mode) to develop and release several incremental versions... So how can we solve that contradiction? You need to operate paradigm changes:

- A release can be partial; it isn't only for the final client (not only the "ready to sell" product)

- We can deliver a functional cockpit when another team is still developing some other gear, the 2 teams and projects progressing differently but with interactions.

- Yes, we can deliver a cockpit by stages, first release being for example a cardboard cockpit with a PC joystick and an office chair, if it demonstrates something important for this new cockpit. Between this first stage and the finished cockpit (and even the finished plane) is will be a series of releases, showing team progression and project direction (allowing validations and improvement) following the Agile process.

    Agilite_necessaireIterative incremental WORKS on physical system!


Other adaptation examples of Agile principles

We can, for example:

    Agilite_necessaire Adapt team size and profile to the reality of the company

    Agilite_necessaire Manage the diversity of skills (not only programmers) and the impact on scheduling

    Agilite_necessaire Agree to change the meeting-rhythm

    Agilite_necessaire Consider shared resources

    Agilite_necessaire Ease the multi-sites work (instead of theoretical plateau requirement)

    Agilite_necessaire ...


Characteristics of 'Agile' people in industry

Agility promotors within a company, being internal (extended team members) or external (coaches or consultants), whether during introduction or after spreading Agility, must not be some ayatollahs of Agility or "black belt certified gurus" of the #agilechurchofbeleiveitornotIknowbetterthanyoualldo. This is not needed, and is generally a show-stopper.

Dogma cannot overrule logic and ground realities. We must be smart and adapt to: industry sector, company, teams, other services, production rhythm, processes...

SolidCreativity and Agility

Veterans in Agility, pioneers of the industry adaptation

Video game veteran Pascal Jarry (20 years managing creative teams in 3 languages on 3 continents) is one of many people creating Agile (understanding and formalising good practices) before he created SolidCreativity in 2002. Agile concepts and tools come from computing, and SolidCreativity has been working since 2002 to make Agility available to all creative sectors and innovative companies, to R&D practitioners.

Testimonies about Agility from SolidCreativity clients

Airbus Agile
« Best training ever had! »
Agile pointer

Secafi Agile

« Structured way of working »
Agile pointer
WireSolutions Agile

« It's a success »
Agile pointer
IMV Agile
« Gains in productivity »
Agile pointer

Rolling out Agile in your company

Rolling out Agile in a company needs a company wide coaching and targeted trainings.

Company wide coaching

From decision to success, a company can be coached to go through the main steps (audit, initiation, training, coaching, roll-out, follow-up). The coach(es) will setup KPIs (suitability, acceptability, team, project, integration of the method...) to drive the adoption-journey efficiently.



With a coach or on its own, the company may be questioning about the need, suitability and will to introduce Agility. It's a big move (but really worth it!) and an external eye might help.

Audit méthode Agile


Amongst other points:

    Agilite_necessaire Do I have a project management process? Is it giving me what is expected?

    Agilite_necessaire Are the team satisfied when in a project? Is motivation helping the project?

    Agilite_necessaire Are the projects we run: repetitive or innovative. Is Agility possible?

    Agilite_necessaire If we had to introduce Agile in the company, where would it fit?

    Agilite_necessaire What project would make a good pilot project?


Setting up tools

After some training, when you know more about Agile, some tools (single or multi-location, software or paper based) can be setup but this is not crucial.

    Agilite_necessaire Agility is not about the tools but about the practices.



Trainings and coaching are available in French, German and English languages.

Formation Agile Teams from any indystry can be trainied to undestand when, why and how managing projects with Agile (or part of projects for a mixed approach). A 2 day training is enough if followed by some coaching. SolidCreativity proposes this exclusive Agile Training.

Formation Audit Agile For people around Agile projects (Management, QA, internal coaches...) we propose a 1 day training to understand what to expect (and not to) from Agile teams and projects, and how this fits your industry : Manage, Favore and Evaluate Agility in your industry.