Agile for all industries – not just Software

Introduction

The ‘Agile’ concept originated from software development, but now Agile practices and tools are available to all industry sectors; from innovative services to heavy industries and large-scale manufacturing.

Project management evolution

Project management as a discipline has evolved. Its first expression put forward the techniques and tools of network diagrams, critical path analysis, Gantt charts and cascade models, driven by the need to increase productivity in manufacturing. Theories were proposed by Taylor and put into practice by Ford in the 1930s for automotive manufacture. In a drive to master quality, the 1970s saw refinements to PM systems that included ISO quality certification, Continuous Improvement and 6 Sigma, and other methods to address matrix management structures.

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

  • Innovative projects (product, service or process), in their early stages, with creative challenges
  • Projects having many uncertainties, which always run late - for no reason
  • Complex projects, having multidisciplinary teams, that are multicultural, multisite – too unwieldy for any Gantt chart to handle well…

Agile can answer these industrial needs

Who we are

SolidCreativity: Veterans in Agility, pioneers of the industry adaptation

Video game veteran Pascal Jarry (20 years to manage creative teams in 3 languages on 3 continents) was one of many original architects of Agile,  before he created SolidCreativity in 2002. Agile concepts and tools came 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

Agile applied to industry

Dictionary definition: Agile (adjective), Agility (noun)

    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; thus outside its original domain of software development.

Where can Agile fit in industry?

    Agile Early phases of physical and tangible projects.

    Agile R&D, research or innovation programmes.

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

    Agile Multi-sites, complex or innovative projects.

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


Why Agile?

If your projects are on time and on budget, and if your teams are well motivated: then there’s NO NEED for Agility.

Agile can be valuable if you notice that:

    Agile Gantt charts are ‘fake news’ from 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 techie and costly parts but no fresh ideas.

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

    Agile Failures with a 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 a true Agile company (with a pilot-project and team to start….).

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. As early as possible, the first reflex is to plan for everything:

    Agile Descriptions 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 safety 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 could possibly go wrong?

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

Advantages of waterfall model

The advantages of a predictive approach, waterfall and similar, are attractive: It's easy to turn into a contract; the team faces its responsibilities. The team will have to endorse any mistake in evaluation, analysis, 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? Is it good for EVERYONE?)

 

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 deal with them before the project starts? Maybe we should only start the non-risky projects? What happens if a problem occurs and it was not previously recognised as "risk with solution" item?*

    Agile For some projects, listing all the features and functionalities from day one is not that simple. It does not seem reasonable to start a waterfall without a solid definition of what we'll do.**

These projects are not appropriate for traditional project management; they would however benefit highly 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 in theory manage any and all projects with Agile yet 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). Understanding Agile will allow you to use it for the right projects (innovative, creative, complex...), 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 (aspects of diverse locations, different cultures, multi-sectors make management beyond a single mind-view).


Agile management: How to apply?

For such projects, Agility brings 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 cycles, generally represented with circles and spirals, represent the real pulse of a small creative team without any constraint. Agile has structured these practices to provide the same benefits to larger teams. Circle and spirals show the rhythm, but it is important to remember that Agile projects also have a start and an END! It can be considered as 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, and the collection of the whole makes the project become characteristically Agile.

(c)Agile Methodology. Cycle Agile Industrie

History of Agility

History

Agility is not the invention of a single consultant guru, but rather the formalisation of good practices noticed in small creative teams, self-organised, working in the computing industry in the 1980s. The complete history of Agility is available in sources such as Wikipedia. We focus here on its progression since the software development era.

 

The little (hi)story

Pascal Jarry, founded SolidCreativity in 2004 after he spent 20 years developing and managing video game development teams in 3 languages on 3 continents. He 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 SolidCreativity specifically adapted the Agile techniques and tools to all sectors with creative and innovative stages.


Is 'Lean' Agile?

Many Continuous Improvement 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 claim that Lean is Agile (we don't). Remember though that Lean techniques are designed to improve predictable or repeatable actions: it is straightforward to apply to a production process. Where projects are being well managed with traditional project management (waterfall, V...), Lean is an ideal approach to improve the process further, eliminating wasteful inefficiencies. Agile however works better for innovation projects and original creation, not so easy to control in a repeatable way. And just as we cannot ‘Lean’ everything, so we also cannot apply Agile everywhere, every time.

 

Adaptation of Agility outside the software development world

From as early as 2002, SolidCreativity has studied the modifications to adapt Agile methods such as SCRUM (100% software oriented) toward other industries. Our findings were that Scrum (with our fine-tuning) can be used effectively under the right conditions:

    Agile Project must be appropriate (innovative, R&D, early phase…).

    Agile It cannot be a project you've already completed successfully many times (because a valid process will already be existing for that).

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

    Agile It may need some effort but you won't regret it.

 

For the organisation coaching the company:

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

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

    AgileWith the work-teams, you need an experienced and engaging trainer to explain (and not just present) the concepts, limits and advantages.

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

 

Agile in other industries: Is it a trend?

When Agile first hit software development, some commentators claimed it would just be a passing trend.  Today, all the major software development companies use Agile.  Now Agile is flourishing 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

Note

All the themes in this table must be introduced and explained in turn, directly to all the team members; Agility concepts are not easily understood or accepted when first met, neither by management, nor by the work- teams... 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

Working on things that are not related to the global objective, without vision

Motivating and efficient risk-management, suitable to innovation projects

Risk management that blocks or restricts effort, based on the fear to start the project

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

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

Self-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 matching the team working methods that can become ISO-certified easily

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

Empowered motivated teams

Demotivation, under exploitation of high-performers

Early detection of problems, allowing solutions to be found collectively

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

And, also, a good fit with modern working practices:
- Multidisciplinary team mates
- Multi-sites and multicultural teams on the project
- Shared time and involvement across projects

Theoretical organisation, just 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 demonstrate what Agility brings to the project and the team in project:


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*)


*Sources

  • 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?

Drawbacks of faulty agility in software development

In computing engineering, where Agility originated 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 reference-point for Agile, people tend to accept things without understanding why it's there, and it becomes catastrophic when they decide to adapt Agility to their "need". Important parts are removed for no other reason than "I don't like it" or "it takes time" and the result is a fake Agility: roles become unclear and not respected, meetings lose their purpose and become useless, user stories are no longer objective-oriented but simple tasks... Often one witnesses a team running a cascade structured project with Post-Its, and then some say that Agile does not work... a shame, as it misses the essence of real Agility.

Differences with software development?

Of course, many companies use Agility efficiently and reach their objectives (hence the positive study results). For those practising an efficient Agile approach with computing engineers and wishing to extend it other industries, they must understand the radical differences for 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 one program in the same office… 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 tends to appear easily, e.g. 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

Suitability?

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 such as:

    Agilite_necessaire Kind of project

    Agilite_necessaire Development phase

Once Agile is confirmed as suitable project management practice, then you can start introducing it to a particular team and project, and then eventually promote elsewhere in the company.

 

Applying Agile outside computing engineering

Agility in computing has its own language, 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".

 

Even so, 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 the industry sector, company, teams, other services, production rhythm, processes...

Rolling out Agile in your company

Rolling out Agile in a company needs companywide coaching and targeted training.

Company wide coaching

From decision to success, coaching can enable a company to go through the key 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. We consider 3 levels of action:

    Agility_needed Project and project team (Agility)

    Agility_needed Project management (Agile management)

    Agility_needed Project management management (strategy, deployment, portfolio, MULTI teams [locations / projects / cultures], Scale, framework / SAFe)

 

Audit

With a coach or on its own, the company may be evaluating the necessity, suitability and drive to introduce Agility. It's a big move (but really worth it!) and an external perspective may help.

Audit méthode Agile

Self-diagnostic

To reflect on, 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 Agile 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 by SolidCreativity but this is not essential.

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

 

Training

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

Formation Agile Teams from any industry can be trained to understand when, where, why and how of 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 close to Agile projects (Management, QA, services...) 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, Promote and Evaluate Agility in your industry (French description of the English training).

Formation Direction Agile For directors and board members, willing to consider Agile at a strategic level: Manage and promote Agile in your project portfolio (French description of the English training).