Menu

Getting Started 101 - Process, Agile or Lean?

Over the years, different terminologies have come into existence, which are considered as the new way of doing things. In theory, it means that people have identified the weaknesses of the way they are working and are therefore trying to find a new, more successful approach. In reality, it appears that the weaknesses due to misunderstanding and misapplication of basic principles have led to results which are very different from what was originally expected. We then get a group of people who believe that the new approach is the solution to all their previous problems and start following it with religious fervour, throwing out anything which does not correspond to the new vocabulary and focusing only on applying what they have understood from what they have read in a book - soon they are producing the same mistakes as previous generations and it becomes time for someone to re-create the basic ideas...

Within the software engineering world, we appear to have two clear groups who believe that they are in conflict with each other: the process people and the agile people. And, yet...

  • The process people push the concept of measurement and analysis, combined with root cause analysis. The main focus is to identify where time is being wasted, where the cost is greater than the value. This is one of the basic principles of lean management.
  • The agile requirement to plan a whole release, including multiple sprints or iterations is what the process people call project planning.
  • The process people want requirements definition, prioritization, management and control. This corresponds to the practices of the product and spirint backlogs. The assignation of the backlogs to subsequent sprints is what the process people call assigning the requirements to components.
  • The creation of user-stories in agile methodologies correspond nicely to what process models would call utilization scenarios and scripts.
  • Continuous integration can only be performed with the background of solid configuration management.
  • Retrospectives, post-mortems, lessons-learned sessions are aimed at identifying what went wrong in the activities that were performed and how the standard process can be improved in future projects.
  • All the methodologies require the planned and managed interaction of stakeholders, including the customer, the management team, the engineers, the marketing and legal people, the suppliers, the maintenance people, etc.
  • At the beginning of a new project or release, there is a meeting of the team to define what is the best approach to take, to decided on how the standard process will be tailored to the specific needs of the project based on their documented past experiences.
  • A key discovery of the agile folk was the creation of the "scrum", an integrated, cross-functional, self-organizing team which sought to define the way they were going to work, resolve any issues or impediments they encounter and work together, as a team, with continuous communication and mutual support. This sounds very much like what the US Department of Defense called "IPPD" in 1996 and was integrated into the CMMI.

I am not saying that all these practices are identical and that nothing has been created, however, I do feel, as I listen, read or see these new methodologies and principles, I find more and more that I am going back to the future. What would be nice would be if engineers and management started actually trying to understand the meaning of the techniques being proposed, the origin of the words being used and stop throwing everything away because a new word has appeared in conferences and litterature.

Leave a comment

Make sure you enter the (*) required information where indicated. HTML code is not allowed.

back to top