AGILE OUTSIDE THE SOFTWARE’S WORLD

Until some time ago, AGILE was often considered as something relevant only to the world of software development. Now things are not like that anymore. Even in the new version of the SCRUM guide (November 2017) a new extended definition of SCRUM is given:

A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value

AGILE has many different meanings. For me it marks out a way of being that is a way of thinking, how you act and what you do in your daily practices and this can be valid on a personal, a team and/or an entire organization level.

If you consider AGILE from this perspective there are no side-effects in trying to use it especially in all those situations where conventional approaches, given the high level of uncertainty, are vulnerable and don’t allow you to adapt and respond quickly to change.

There is no single recipe on how to start being AGILE, but there are some “ingredients” you need to let you inspired:

In my experience, there must be the idea of making the flow of value more efficient – from the idea to the moment in which the results are collected (in terms of money) of the same “from Concept to Cash” under the guidance of only one Business Manager, who has the responsibility and autonomy to define the Value interventions the team will have to work on.
To achieve this, we often need to set up a single cross-functional Value team by breaking down the silos of the organization as much as possible – for example by mixing together Marketing people, SEO/SEM experts and social campaigns, Business Operations people in the same team and, if it was necessary for the type of activity to be carried out, even those who develop softwares.
The team works following an Empirical and Experimental approach and the way they work must be carefully structured also from the point of view of the physical working spaces – physical positions of the team members in the same area, space available for the preparation of a physical Kanban board on which to report all the various phases of the activities.
The empirical and experimental approach is followed both from the point of view of the business goals and from the point of view of the team’s way of working.
a. a. The team works in iterations (few weeks, from 2 to 1 months) which include: a Planning phase of what to do during the iteration (Business Planning), the work and the collection phases of the results gained from the started actions (Execution), a phase in which the goal achieved are reviewed (Business Review) and it is decided what to do in the following iteration, starting again with the outermost cycle. During the Business Planning phase, starting from the business goals described and detailed by the Business Manager, the team analyzes possible Options on how to achieve them. For each Option the team also identifies the individual actions to be done. At the end of the session, the Business Manager chooses and assigns a priority to the Options/Actions. The actions to be done thus become the individual tasks, which the team will have to complete during iteration.
b. With regular intervals, the team has moments in which they reflect and analyze the way they work and define the actions or changes agreed to be experimented to try to increase their effectiveness and efficiency. After the first learning period of the process, the changes can also be quite impactful and can relate to any aspect of the work.
Last but not least, have a support and a mentor to guide this change by suggesting how to build the knowledge base necessary to start this kind of initiatives, prepare the launch phase of the initiative and what to study, explore and analyze to get ideas for experimentation.

Behind these items there are some inspiring principles:

Have clear, shared and common objectives within the whole company.
Have a complete vision, not only partial of your Silos! If your Silos is efficient, the company can’t get the expected results.
Increase Collaboration and Confidence between individuals and between different teams.
Share information and knowledge.

In conclusion, starting to be AGILE is a challenge which must be understood by the company and its leaders, first of all. Do not equip yourself with emerging skills, tools and practices to carry out your job as best as possible. It’s like clipping someone’s wings, which could put at risk even the survival of the company itself. We must explore change by studying.

Daniela Cecchinelli is an IT engineer who has been working in the Digital field for almost 20 years, mainly dealing with the development of Java and Mobile & Apps services and solutions. He began his career in “being Agile” as a Product Owner of a Scrum team in 2010.
In the last few years she has worked on Agile Trasformation. He currently works as Agile Consultant in Herzum Software.