Agile concepts come from software development but Agile practices and tools are now available to all industry sectors: from innovative services to Heavy Industries.
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:
Agile in the dictionary: adjective
1: Able to move quickly and easily.
2: Relating to or denoting a method of project management.
This website is fully dedicated to Agile project management applied to industrial projects; this means "Agility outside its original domain: software development".
Early phases of physical and concrete projects.
R&D, research or innovation programmes.
R&D / R&T teams, multi-projects, multi-disciplinary teams.
Multi-sites, complex or innovative projects.
Hybrid development methodology, mixing Agile and traditional methods...
If your projects are on time and on budget, and if the teams are motivated: NO NEED for Agility.
Gantt charts are fake and false since day one.
Most of the project are late, and delays are discovered late in the project.
The setup (or attempts) of burdensome procedures actually delay the project even more and/or harm its quality.
'On-time' projects are managed by small fighter teams only, in specific conditions.
Your talent-pool doesn't like to be told HOW to do its job and you finally lose common communication ground with them.
Teams are snowed under, with too many projects, bad priority management and so many changes.
Projects include many techy and costly parts but no fresh ideas.
Ideas arrive too late in the project to be included.
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?).
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:
Description of what we need to deliver
How we'll achieve the result
List of risks and problems that may occur, and ways to sort all this out
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?
Terms vary from one company to another (conception / production...)
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??)
Anticipating everything, planning everything from day one... this is attractive but is it always possible and/or beneficial?
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?*
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.
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:
Design of products or innovative services
Creative and innovative projects (R&D, design office, research…)
Complex projects (when one brain is not enough because of complexity: multi-sites, multicultural, multi-sectors…).
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:
Incremental (repetitive cycle)
Iterative (adding content)
Iterative incremental (mixed with our smart risks management)
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.
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.
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 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.
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:
Project must be appropriate (innovative, R&D…). Absolute condition: it cannot be a project you've already completed a thousand times.
Domain is irrelevant (heavy industry, research, journalism…)
It needs some effort but you won't regret it!
For the organisation coaching the company:
They must UNDERSTAND Agility, they must not stick to the dogma. Some parts are kept, some are adapted, and some are discarded
You must adapt you pedagogy and examples, as we did, to transpose Agility for other audiences
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 ;)
Agility is not only about Scrum; you must introduce a global Agile approach (mixed project management for example, not just tools/artefacts/meetings).
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.”
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.
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
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:
Theoretical organisation looking good on paper:
Well documented research studies show what Agility brings to the project and the team in project management (productivity, cost, motivation and time to market).
4 studies show that Agility increases productivity:
Productivity gain of 16% (QSMA*)
82% note a gain in productivity (DDJ*)
23% say productivity increased significantly (VO*)
According to the University of Calgary*, Agility reduced the need for overtime work by 2/3.
2 studies show that Agility reduces development cost:
32% note a cost reduction, 5% a significant cost reduction (DDJ*)
30% note a cost reduction, 8% a significant cost reduction (VO*)
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.
64% note a faster time to market, 23% a significant improvement (VO*)
37% note a faster time to market (QSMA*)
Book about Agile success in software development: Succeeding with Agile
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?
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:
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:
Kind of project
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.
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..
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.
Iterative incremental WORKS on physical system!
We can, for example:
Adapt team size and profile to the reality of the company
Manage the diversity of skills (not only programmers) and the impact on scheduling
Agree to change the meeting-rhythm
Consider shared resources
Ease the multi-sites work (instead of theoretical plateau requirement)
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...
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.
Rolling out Agile in a company needs a company wide coaching and targeted trainings.
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.
Amongst other points:
Do I have a project management process? Is it giving me what is expected?
Are the team satisfied when in a project? Is motivation helping the project?
Are the projects we run: repetitive or innovative. Is Agility possible?
If we had to introduce Agile in the company, where would it fit?
What project would make a good pilot project?
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.
Agility is not about the tools but about the practices.
Trainings and coaching are available in French, German and English languages.
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.
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.