The Monaco intellectual property division was looking to simplify administrative procedures and provide businesses and individuals with a more efficient service. To that end, we decided to redesign our system for managing industrial property documents (trademarks, patents, designs, and models) with Jouve.
The initial plans were to conduct the project in the customary manner based on a V-model. It was Jouve that recommended taking an agile approach. Firstly, I familiarized myself with this method and the potential risks entailed. I was sold on one of the main benefits of this method – the ability to change our approach mid-project.
We have switched from a project to product management culture. In contrast to traditional projects, the agile method requires our participation throughout the project. This constant involvement in a schedule of regular events has proven positive. We are required to attend planning meetings and demonstrations and answer questions.
Although it takes time for this process to gain acceptance, it is nevertheless simple and affordable. A full range of materials focusing on practical examples is readily available and there is now even an ‘Agile for dummies’ guide for learning the basics. Some priorities are obvious such as eliminating a risk for a technical or operational component. The aim is to focus on the backbone of features and build on it. I was constantly asking myself questions such as: ‘What do users need?’, ‘What are the operational priorities for the product?’, and ‘Is there anything we can do without?’.
Yes. Transparency is vital to a project’s success. It is the key to a trusting relationship between the development team and myself. Burndown Chart 2 gives me an exact picture of how the team are progressing, so I know whether the team are ahead or behind. Transparency is also enhanced by demonstrations performed at the end of each sprint, providing us with a partial yet operational product, and eliminating the ‘tunnel effect’ of waterfall methods.
For me, the most important aspect is the peace of mind this technique gives you. There are no surprises with this method of cooperation. Generally, functional discrepancies and overspending are a manager’s main concerns. Major functional discrepancies are unlikely with the approach we have chosen. If a feature does not meet user requirements, all we need to do is revise it in the next iteration. The ‘balance of changes’ provides this flexibility and is also an essential tool for monitoring (and communicating on) budget changes. The outcome would have been very different if this project had been traditionally managed. We would not have had the same end product. There were some major changes in direction as a result of the iterative approach, which is based on genuine user requirements. We watch the system develop and become fully familiar with it before it is delivered.
Product Owner for the INPACT 1 project, gives us his feedback on the ‘Management system redesign’ project conducted using agile methods (Scrum) with the Jouve Group.
The Monaco intellectual property division was looking to simplify administrative procedures and provide businesses and individuals with a more efficient service.
This post is also available in: