Agile Project Management Questions Answered, Part 1

In response to an earlier post on agile project management for MES and MOM deployments, readers had a number of questions about putting this process into practice. Luigi de Bernardini's new blog on Automation World

Last month I wrote about how an unconventional, agile approach can be crucial to the success of a manufacturing execution system (MES) or manufacturing operations management (MOM) project. I did not expect all of the interest that has been expressed on the subject. Many people commented on LinkedIn, where the blog was reposted, requesting explanations and insights, in particular: "How it is possible to estimate a project with this approach?" and "How can one manage the changes of scope that may occur during the various sprints?"

In this month's column I will address the first of these questions; next month I'll tackle the other question. Obviously, I do not presume to know all of the answers, but I offer food for thought and discussion from my experience with Autoware.

Estimating a software project is always a complex task. Much theory has been developed in an attempt to bring the estimating activity to a quantitative algorithmic approach. However, since the software development process is fundamentally creative, no approach has, in my opinion, actually been shown to produce an estimate sufficiently correct to be more effective than experience. This is especially true in the case of development projects, where the variation occurring among projects can be extremely high.

Choosing to manage a project with the agile methodology adds a further element of complexity because the high flexibility offered by the agile methodology corresponds to an uncertainty of the final result to be obtained. How can I then make an estimate of the resources required to achieve something that is not well defined and specified?

When we need to define the commitment necessary to develop a new project, we address the problem by following these steps:

Define with the client the approximate boundaries of its desires and map the macro requests to as many macro areas of our experience as possible. This helps us to identify, at least crudely, the problems and to understand from which set of experience draw information to try to bring the requests back to something already known.

Develop a macro architecture of the technological solution to be used as a reference, taking into account the project complexity. This architecture provides a defined common element to refer to in any later interaction with the client.

Identify how much of the requirements set is comparable to standard features or to components already developed for other projects and how much is different or outside the sphere of experience available in the company.