NAME workshop Bolzano October 17th 2002

1
NAME workshopBolzanoOctober 17th 2002

• The agilengineering experience
• Ing. Maurizio Tripi
• CEO Ca.St. srl and founder of agilengineering
• mtripi_at_acm.org

2
The Purpose

• Agilengineering is a division born in the end of
  the year 1999 as a community of practice inside
  an IT Company (CaSt srl)
• 3 main aims
• Excellence center for OO methodologies
• Learning center
• Software Production center
• Experiment new ways for speeding up knowledge
  transfer, research and development

3
The wrong way

• A division organized the same way the company
  was.
• Too rigid, too expensive,
• People from the old production system
• Hard to force people to change the good old way
  of doing
• Then its difficult to teach them a new way
• Learning by courses in classroom
• Not practical, not effective, time consuming

4
The chosen way

• A new structure based on AGILE principles for
• Organization
• Production
• Learning
• Some experienced professionals with
• A proved track in Software engineering
• Willing to change the wheel
• A strong leadership
• A lot of newcomers free of biases

5
The Principles

• Organizational Principles
• Collaboration first
• Adaptability
• Light structure
• Leadership

• Learning Principle
• Learn by doing
• Communication
• Individual matter
• Trust

• Production Principles
• Produce Value and Quality for customers
• Methodology over Technology

6
How to follow those principles?

• Production based on Agile Methodologies (AM)
• Learning based on the concept of Community of
  Practice (COP)
• Organization based on Adaptable Organizations
  principles (AO)

7
Three ideas same concepts

• Collaboration
• Leadership not command
• Trust individuals
• Welcome change
• Self organization
• Share common values instead of rules
• A vision and clear objectives
• Continuous learning
• Plan a little, act, sense and react, cycle

8
Clear Past and Future, what present?

• In the beginning we knew about XP, Scrum and FDD,
  but few had a practical experience
• We also knew about RDD, OMT, Booch, OORam,
  Syntropy, Fusion, Catalysis, OPEN and RUP
• How to choose best practices from both worlds?
• Leave the method cookbook approach
• Use what you know best
• Change your mindset not your techniques

9
A method per project

• An adaptable approach!!
• Sticking to a single AM is like following blindly
  a recipe. Instead you have to refine and follow
  your taste
• An evolutionary approach instead of big-bang
  approach develops your sensitivity, culture,
  experience and belief
• Agile methods require much more discipline and
  responsibilities than Heavy Methods

10
The transition

• First of all change your point of view
• Each project required a method customization to
  follow technical and contractual characteristics
• Each project tried to introduce a new set of
  techniques, practices and tools
• The final judgment was quality and customer value
  gain (vs. internal performance and costs)
• Each innovation was spread by legitimate
  peripheral participation (situated learning)

11
Internal Problems

• Its hard to learn by doing without the knowing
  all
• Show an overall picture, let them hit problems,
  give enough tools, let them do the job, refine
  the picture
• Waterfall is THE natural way of thinking
• Everybody thinks Evolving artifacts is harder
  than doing them well the first time (but see
  Brooks)
• A lot of methods urge you to do something when
  you havent enough information
• Dont stop and dont influence your solution with
  arbitrary choices but do everything you can to
  proceed

12
External Problems

• Bigger customers want you to develop their way
• They have their processes (always Heavy), their
  metrics and their techniques
• When you show them an alternative way they
  unlikely believe you or unlikely commit to the
  change
• Smaller customers enjoy your flexibility
• But you are warned they will introduce so much
  chaos in the process that you have to be VERY
  agile!!
• Contracts are well suited for Heavy Methods
  approaches
• Sometimes to find a flexible contract is the
  hardest part of all

13
Results

• Unpredictability is the key word expect
  everything can change
• Build to change
• Dont overwork artifacts (but be disciplined)
• Every plan can be wrong (but use timeboxing)
• Agile is not the same of poor
• If customers (or you) need DocModels make them
  the same way you make code changeable
• With big projects bet on collaboration not on
  ceremony
• Build a basic set of tools for editing, building,
  testing, CM and documenting never under use them
  
• Our choice is Open Source (Netbeans, Ant, JUnit,
  Jboss, )

14
A plain example

• A small customer required a system with Web GUI,
  complex domain logic, open to future integration
  with an unknown workflow engine, geographically
  distributed, scalable, portable and reliable
  obviously as soon as possible.
• We did it on budget and on time with
• EJB technology (with clustering) and web services
  
• Adapted UML CBD Tech for Modeling
  (CheesmanDaniels)
• Scrum for project control (adapted for UML
  components)
• Open Source (Netbeans, CVS, ANT, JUnit, JBoss,
  Linux.

15
Research

• We tried to integrate Techniques and Practices
  from several HM and AM (a methodologist job)
• We used an alchemical approach. But we have to go
  ahead we must find the laws of nature
• Discovering the very essence of the Agile
  approach will lead us to the way that works for
  sw development
• With the Fusion, Syntropy and Catalysis heritage
  we need an AM for CBD with formal specifications
• It seems an impossible target because formal spec
  are quite resistant to change and waterfall prone.

16
Conclusions

• Agility is in the Control of the project
• Take Tech Practices you absolutely need then
  choose the control process and then add the Tools
  Tech you like that let your process manageable
• Agility is a way of life Project Management
  discipline must be renewed
• Face up the real problem, dont hide behind an
  overwhelming structure so nobody can tell you
  missed something a mouse can still beat your
  elephant
• WARNING dont be too Agile (balance!!!)
• This can lead to an insecure instability
  (sustained oscillations)