Agile Methodology - Agile applied to industry
Be in sync with your objectives wihtout wasting time and money with heavy procedures and costly processes
Agility is not reserved to software industry, Agility does exist outside computing companies and it can you can master it. scale and SAFe
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 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:
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.
Dictionary definition: Agile (adjective), Agility (noun)
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; thus outside its original domain of software development.
Early phases of physical and tangible projects.
R&D, research or innovation programmes.
R&D / R&T teams, having 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 your teams are well motivated: then there’s NO NEED for Agility.
Gantt charts are ‘fake news’ from 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 techie and costly parts but no fresh ideas.
Ideas arrive too late in the project to be included.
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….).
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:
Descriptions 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 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?
Terms vary from one company to another (conception / production...)
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?)
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 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?*
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.
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:
Design of products or innovative services
Creative and innovative projects (R&D, design office, research…)
Complex projects (aspects of diverse locations, different cultures, multi-sectors make management beyond a single mind-view).
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:
Incremental (repetitive cycle)
Iterative (adding content)
Iterative incremental (mixed with our smart risks management)
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.
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.
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».
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.
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:
Project must be appropriate (innovative, R&D, early phase…).
It cannot be a project you've already completed successfully many times (because a valid process will already be existing for that).
Domain is irrelevant (heavy industry, research, journalism…)
It may need some effort but you won't regret it.
For the organisation coaching the company:
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.
You must adapt your pedagogy and examples, as we did, to transpose Agility for other audiences.
With the work-teams, you need an experienced and engaging trainer to explain (and not just present) the concepts, limits and advantages.
Agility is not only about Scrum; you must illustrate a holistic Agile approach (hybrid / mixed project management for example, not just tools/artefacts/meetings).
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.”
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 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: |
Theoretical organisation, just looking good on paper: |
Well documented research studies demonstrate what Agility brings to the project and the team in project:
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*)
*Sources
Book about Agile success in software development: Succeeding with Agile
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.
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:
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:
Kind of project
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.
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.
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.
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 the industry sector, company, teams, other services, production rhythm, processes...
Rolling out Agile in a company needs companywide coaching and targeted training.
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:
Project and project team (Agility)
Project management (Agile management)
Project management management (strategy, deployment, portfolio, MULTI teams [locations / projects / cultures], Scale, framework / SAFe)
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.
To reflect on, 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 Agile 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 by SolidCreativity but this is not essential.
Agility is not about the tools but about the practices.
Trainings and coaching are available in French, German and English languages.
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.
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).
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).