A few years ago I faced a rather difficult task. Unlike the many software development projects I had previously managed, this time the goal was to build a new system from scratch, but with two critical points: the project lacked of a set of defined specifications and, even worse, didn’t have enough support from stakeholders (just think that I was only allowed to access 1/6 of the estimated total budget).

 Given these premises, the probabilities of failure were very high and the classic PM analysis / design / development / testing / release approach would only increase these probabilities.

I then decided to follow a very different approach, the basis of which would have been caution: There are no clear and complete specifications? Then we develop only the parts that are known. There is no trust on the result? Then we produce intermediate working releases (though obviously limited) to let the product be seen first hand.

We compiled a list of needed features, giving priority to each of them according to the end user's point of view. I used the month as a time reference: every four weeks we would achieve some of the functionalities present in the list, selecting them according to a criterion of homogeneity, in such a way that put together constituted a functioning subset of the overall system.

At the end of each month we would have released a product update, available to everyone as if it were really in production.

After a few months I was able to organize demonstration sessions where you could see a product that is certainly still limited, but already functional and, very importantly, usable in production. This increased the confidence of the stakeholders on the potential of the system and, consequently, their support for the project.

So it was that all the main heads of the company departments were involved in the project, by contributing in terms of ideas, changes, improvements or even just reports of anomalies. Naturally, I maintained the "development month" approach, so that external contributions to the evolution of the product could receive feedback quickly, thus generating a circle to the full advantage of the system and its effectiveness.

Today that system is in production and plays a key role in the provision of services to the customers of a large Italian company, used by thousands of users to plan and report on their business travels.

When a year ago I took the challenge of SoundsOfThings, I asked myself what would be the best approach to manage this very difficult project. Exploring the various techniques of Project Management available, especially those most used in the world of startups, I came across Scrum, a process framework based on the principles of the Agile Manifesto. To my great surprise I found in Scrum some of the key principles of the personal and craft approach I had used years before, such as the concept of Sprint: "a time interval of one month or less during which an increase in the product is created and is potentially releasable "(The Scrum GuideTM).

By looking deeper into Scrum I have rediscovered the key points that, I also tried to use in the described experience. The following in particular, I consider of great importance:

• Clear identification of a person who assumes the role of Product Owner, whose responsibility is to maximize the value of the product for both stakeholders and users.
• Continuous and constant involvement of all those who are part of the project, regardless of their role through specific scheduled meetings (sprint planning, daily scrum, sprint review, retrospective sprinting).
• Retrospective analysis of the results obtained in each sprint, so that the team can identify the necessary interventions for the benefit of the subsequent sprints.

Adopting Scrum is certainly challenging, but the results can be really interesting.

I do not think there is an optimal approach for any type of project; the choice must be made each time according to different factors such as context, objectives etc. My experience, however, tells me that Agile methodologies have an edge, so what really matters is not to use Agile but to think Agile.