Are Agilists the only ones who are Agile?

The Software industry has been talking about Agile for more than 15 years now. A lot of people still confuses being Agile with practicing Agile. Some identify Agile mostly with Scrum practices. But a larger group of developers isn’t explicitly working in an Agile environment: does this mean that they are working in Waterfall? Maybe not.
I started working in the software development field in 1980; developed software both on customers’ request and for my own products and as a hobby. In the early years, projects were small, and requirements were collected in a couple of pages; the same for proposals. I didn’t go into deep details, usually a turnkey proposal was enough to get into an agreement to start the project.
But soon projects became larger and more complicated. Collecting requirements became an important part of the job! The temptation and the fascination of having all the requirements collected and analyzed in great detail was very strong. This was, of course, a very time-consuming activity, which led me to produce large documents that tried to predict every aspect of the software we were about to develop.

Maybe you’ve heard this story a number of times, with the same ending: the project failed. But not all was wrong. We did do some things right, even back then.

Discuss and collaborate with the Customer

My first important projects were for a customer that was continuously asking for updates on the progress of the project. Over time, I turned this micromanagement into an advantage for me, as I had more and more opportunities to talk with the customer about the project.

These regular meetings and updates suddenly became a way of working, and I extended this to all my customers. The framework was well defined:
1. collect the requirements – including interviewing end users;
2. analyze the project with my team;
3. write an analysis document to discuss with the customer (the hidden, untold goal was as simple as: Do I understand what you as a customer want?) until we both agree on the content.
Keep in mind that in those day it was not simple to change the development direction along the way. Back then a good start was far more important than it is with today’s technologies.

Choose the most suitable framework for the project, and don’t be afraid of change

After this initial process, my team and me started developing. We talked about almost everything: techniques, patterns and frameworks, tools and languages, etc. Even in this respect luck was on my side: my customers did not impose on me, the let me free to develop the software without imposing language, tools, frameworks etc. That was great: having no technical limitations meant we were able to use the tools we were used and experienced to work with, usually achieving a good velocity in our work. We were able to quickly prepare prototypes and demos, and presented those to the customer in the very early days of the project. This allowed us to understand if we were progressing in the right direction.

But we did not keep the conversations to ourselves. As our focus was delivering working software. In the process, we discussed a lot with the customers, showing them prototypes, demos, staging environments to test new functionalities and so on… We were not afraid of developing software that wasn’t exactly what was agreed with the customer at first glance. We were open to even last-minute changes, as our main goal was to deliver software suitable for the customer, even if it meant adjusting what the software was supposed to do. Of course, being used to face this kind of situations we learned to develop software in a way that allowed us to quickly and reliably change the software. It is harder to prepare the software for constant change, but it is worth the effort when you must accept and accommodate late changes.

Take care of the individuals, to get the best from the team

Achieving this tight cooperation within the team and with the customer was not luck, of course. Keeping a tight-knit team is daily work. We constantly try to identify each person’s individual value and preferences to get the most out of each team member. For example, you have to keep people focused on the projects they’re working on, but at the same time give them some freedom to discover new ways to develop and – in general – to work. You also should manage conflicts so the team morale remains high. Conflicts are normal in highly motivated individuals, especially with larger teams.

You may be Agile without knowing

As a developer, all that you read so far may sound familiar to you. In that case you are likely to be working according to Agile values and principles without knowing it. Maybe you even started working this way before Agile was even a main stream topic, and continued this way without deploying any Agile Framework like Scrum, XP or Kanban.
The 4 Agile main values are:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

and most or all of them are probably already part of your daily work. You may not use a framework to enforce the adoption of Agile in your team and in your company, but if you are implementing these values you’re already on the right track, you are Agile.

About Enrico Di Cesare

Always interested in improving the quality of the software produced for himself or for his customers, Enrico became an Agile enthusiast as soon as he discovered it. With extensive previous experience as a Project Manager and Coordinator, Enrico works as an Agile Coach, Scrum Master and Product Owner, introducing, mastering, facilitating and refining the adoption of Agile with new collaborative tools.