This document discusses Taller Technologies' experience with implementing an ISO 9001 quality management system while also adopting Agile practices. It describes Taller Technologies' focus on simplicity, flexibility, and continuous improvement in its quality system design. Key lessons included designing processes that allow each project to define how it will work, keeping processes and documentation simple, and conducting peer reviews instead of traditional audits.

1. ISO 9001:2008 and Agile
Our Experience

2. Contents
1. About Us
2. Why ISO 9001
3. What is ISO 9001?
4. What is Agile?
5. Strategies
6. Design
7. Lessons Learned

3. About Us

4. Taller Technologies Argentina is a company which
provides customized high-quality software development
services.
We support our international clients with the following
services:
▪
▪
▪
Development of embedded and real-time software for
mission-critical and high-availability systems
Mobile application development for both Apple iOS
and Android operating systems
Development of web applications and services
About Us

5. We have achieved successful results both in demanding
high-quality environments applying rigorous engineering
practices, and in high-volatility businesses where
flexibility and time to market are crucial.
These are some of our clients: Intel (USA), Manpower
(USA), INVAP (Argentina), MercadoLibre (Argentina),
CONAE (Argentina Space Agency), Kohl's (USA) and
Harley-Davidson (USA).
More than 60 employees work at our offices in Córdoba
(Argentina).
¿Quiénes somos?About Us

6. We adopt a working model in which we prioritize:
Transparency, so that customers know who they are
working with, how the job is carried out and the actual
progress of the project.
Regular delivery of a working product to obtain feedback
in a fast way, validate ideas and determine whether the
chosen course of action is appropriate for that project or
product,making decision based on actual results.
The customer and our teams work together collaboratively
with fluid communication in order to make the biggest
impact on the business.
We have experience working with the following
technologies:
About Us
▪
▪
▪
C and C++ for Linux RTEMS (real-time operating
systems) operating systems, and X86 and ARM
platforms.
Objective-C for iOS and Java for Android.
J2EE with Spring, Hibernate and other frameworks for
the development of web applications and services.

7. Why ISO 9001

8. ▪
Meet customer requirements
New customers
Understand and communicate our processes
Meet Software Regulations
Working culture
Consistency in operations
Improvement in efficiency
Worldwide reputation
▪
▪
▪
▪
▪
▪
▪
Why ISO 9001

9. + quality
Quality: the totality of features of a product or service
that bear on its ability to meet a stated or implied need.
ISO/IEC 8402
Why ISO 9001

10. What is ISO 9001?

11. What is ISO 9001?
ISO 9001:2008 is an international standard which sets
out the requirements to implement a quality management
system of the processes in an organization.
It sets out all the elements that the management system
needs to have in order to ensure an effective system to
manage and improve the quality of the products or
services.

12. Product
Realization
Quality Management
System
product
customercustomer
requirements
satisfaction
complaint
▪ Quality policy
▪ Quality objectives
▪ Plan
▪ Metrics
▪ Continuous improvement
Resources
Purchasing
▪ Review
▪ Infrastructure
▪ Training
▪ Workplace

13. Quality Management
System
requirements
Product Realization
Requirements Design Development Provision
Plan
V&V
▪ Continuous improvement
▪ Metrics
▪ Records
AUDIT

14. Quality Management
System
Resources
Purchasing
▪ Review
▪ Infrastructure
▪ Training
▪ Workplace
The characteristics of product and process
conformity are outlined, and corrective
actions are taken to eliminate
nonconformities.
Preventive actions are taken to avoid
potential nonconformities.
Product
Realization
requirements
AUDIT

15. AUDIT
Quality Management
System
Management review. Quality of processes
and products, compliance with objectives,
customer satisfaction, results of audits,
continuous improvement, complaints are
reviewed with the metrics analysis of
process and product.
Process B
Process
requirements
Process A
Process B1 Process B2
Preventive Action
Corrective Action
Nonconforming
Product
Nonconforming
Process
Sub-process
Corrective Action

16. What is Agile?

17. Requirements
TRADITIONAL AGILE
BASED ON ADDED
VALUEBASED ON
PLAN
Resources CalendarFIXED
FunctionalityResourcesESTIMATED Calendar
Agile is, chiefly, a paradigm shift. In the traditional paradigm, the customer's requirements are comprehensively determined at the
beginning of the project. Then, the necessary effort and calendar for the project are estimated based on a plan and taking into account
the size of those requirements. Problems in projects arising from wrong estimations are not uncommon.
A project team is set up and the spans of work times are defined, estimating which functionality can be delivered, based on the added
value that said functionality provides to the customer.
What is Agile?

18. Manifesto for Agile Software Development
We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value...
Manifiesto
http://agilemanifesto.org/

19. Individuals and interactions
over processes and tools
http://agilemanifesto.org/
Manifiesto

20. Working software
over comprehensive documentation
http://agilemanifesto.org/
Manifiesto

21. Customer collaboration
over contract negotiation
http://agilemanifesto.org/
Manifiesto

22. Responding to change
over following a plan
http://agilemanifesto.org/
Manifiesto

23. ▪
Changing requirements are welcomed
Fast deliveries
Ongoing customer feedback
Software working soon
Early testing
▪
▪
▪
▪
Manifiesto

24. Strategies

25. Strategies
Bottom-up:
Processes show what is being done
Take advantage of what we have
First version to test
We set out to design the management system bottom-up,
taking advantage of the processes that were in place.
The main processes arose from the analysis of what was
being done.
We also decided to design a simplified version of the
processes, and to start using -and reviewing them- as soon
as possible, even if not all of them had been defined yet.
One of the first processes was Recruitment.
▪
▪
▪

26. Avoid recipes:
One of the most frequent problems encountered in the
implementation of a quality management system is the
use of predefined recipes.
If a design was successful in a company, others attempt to
copy the processes because they were "successful" in the
certification.
It has been decided to outline the process to improve
what was being done, and, even though recommendations
were adopted, "packaged" implementations were not
copied.
Strategies

27. C1
p1
p2
p3
▪
▪
▪
C2
p1
p2
p3
▪
▪
▪
Avoid common mistakes:
Not all companies are the same
Not all projects are the same
Besides avoiding copying what other companies used, we
made emphasis in the need to be able to design a process
of "product realization" which would be flexible enough to
be used in most cases.
Another common mistake is to implement a unique, and
generally inflexible process for all the projects, regardless
of their size, type, and complexity.
▪
▪
Strategies

28. Strategies
Simplicity:
Processes were designed to be as simple as possible.
The idea was: to build a first fast version and make it
evolve through continuous improvement.

29. Estrategias
Not step by step:
In creative, innovative activities which need abstraction,
design and interaction between people, it is not possible
to determine, step by step, what has to be done in order
to obtain a product.
It is a traditional mistake in software development
processes to outline, in great detail, all the tasks that need
to be done. This, along with the "recipe" idea tends to lead
to failure.
Processes are defined by setting guidelines, mandatory
elements and focus is placed on the outputs which should
be obtained in each process.
Estrategias

30. Strategies
Peer review for audits:
In order to implement audits, a peer review outline was
designed, in which some reviewers carry out the review
from the point of view of the management system, and,
hence, of ISO 9001.
This is based on the peer review concept with different
perspectives or viewpoints.
The other peers review from another point of view. For
example: design, person in charge of processes, internal
customer of a process, etc.

31. Strategies
Paperless
In many of the solutions of the "packaged" type, papers
are misused to show evidence.
Besides being a myth, this is inefficient, unnecessary, and
environmentally-unfriendly.

32. Strategies
Improvement:
We want to improve
Flexible milestones based on actual
improvement
Review early
As one of the objectives was to improve
operations, a road map with flexible
milestones was outlined in order to
quickly show improvements and to review
the continuous improvement.
▪
▪
▪
Plan
Do
Act
Check

33. Design

34. Design
Simple processes:
Pre- and post-condition
Guideline; it is not step by step
Flexible definition for product realization
Agile
The definition of processes outlines the elements that
need to be ready at the beginning, those which will be
finished at the end, and a process execution guide which
does not dictate the steps in detail.
▪
▪
▪
▪

35. Design
Unconventional:
Very few minutes
Project defines how to work
Agile mindset
Peer review for audits
Avoid redundancy
The (mandatory) elements which must be defined were
determined. However, each project has to specify how this
will be carried out.
The use of minutes was kept to a minimum.
Redundancy of information was kept to a minimum.
▪
▪
▪
▪
▪

36. Design
Continuous improvement:
It is not a specific process
It is carried out in all processes
Agile mindset
There is not a specified process for
improvement
Continuous improvement of processes
and products is embedded in all the
processes of the quality management
system.
Quoting the agile philosophy, “At regular
intervals, the team reflects on how to
become more effective, then tunes and
adjusts its behavior accordingly.”
▪
▪
▪
Plan
Do
Act
Check

37. Design
Kanban:
Human resources
Management
Quality
IT & Facilities
Projects
Many process flows are implemented with Kanban boards
Most of the projects use Scrum and/or Kanban
▪
▪
▪
▪
▪

38. Lessons Learned

39. Product
Realization
Lessons Learned
product
customercustomer
requirements
satisfaction
complaint
▪ Quality policy
▪ Quality objectives
▪ Plan
▪ Metrics
▪ Continuous improvement
Resources
Purchasing
▪ Review
▪ Infrastructure
▪ Training
▪ Workplace
SYSTEMIC
VISION

40. Projects:
Not all projects are the same
Designing flexible processes in which the project has to
define how to work was the right choice
Lessons Learned

41. ▪
Do the basics:
Software engineering
Configuration management
Peer review
Automation
V&V
Architecture
Good practices
▪
▪
▪
▪
▪
▪
Lessons Learned
The maturity of the engineering practices was key for
the strategy we chose.

42. Lessons Learned
Simplicity:
The current versions of the processes are simpler than the
first ones.

43. Lessons Learned
▪
Reviews:
Peer review instead of audits
Participation in meetings
Participation in reviews
QMS viewpoint
Agreement and discussion
Established criteria
Continuous improvement
▪
▪
▪
▪
▪
▪

44. It was very important to have an
external review before the certification
Lessons Learned

45. In God we
trust; all others
must bring
data”
EDWARD DEMING
“

46. Review plan applying Kanban implemented
in Trello.
It features plan, calendar, criteria, results,
actions, report, etc.

47. Development and maintenance of the
quality management system applying
Kanban implemented in Trello.

48. Version Author Date Description
1.0 Alvaro Ruiz de Mendarozqueta Jul-06-2015 First version
Version