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.

2 thoughts on “Are Agilists the only ones who are Agile?”

  1. Hi Enrico.
    good considerations: maybe on the most part of my experience i’ve notice what you’re described in a very simple way
    For the most part of situation i’ve seen,
    the steps to introduce an Agile approach to management of activities passes anyway
    from some an overview of the behaviour of actors involved (from developers to Clients).
    Definitely, the best thing i’ve seen succeed is the capacity of a Team to understand how to valorize his strenghts,
    regardless of the formal method adopted or imposed (….).
    And, almost naturally (and this is the ‘magic’ of Agile), we have experienced the advantages.
    On the other hand, how most coach and Scrum Master knows,
    this is the best way to introduce effectively the mindset Agile, a team level, Workgroup, and Enterprise.
    Thanks for your article.

  2. Enrico, your background was like mine, except I did Maintenance Software. I was constantly talking to the customer, focusing on what they wanted the fix to contain, taking proposed solutions to final successes. Iterating through the fixes that were needed. I found Agile and I found a home. I was agile before agile was around. I just didn’t know it and now that I have found it I am upping my game. Thanks for the positive reinforcement.

    Charlie
    http://www.linkedin.com/in/charlesbrown3rd

Comments are closed.

Get The Booklet!
How to deliver on time and eliminate scope creep By scoping projects around outcomes and impacts, not requirements!
Get the Product Owner Booklet!
Avoid scope creep! And learn to scope projects around impacts and outcomes, not requirements!
Get These Valuable Lessons Today!
Down-to-earth, hard-earned Scrum Masters lessons and the Tips from the Trenches e-book table of contents, delivered by email
Enter e-mail to download a clickable PO Cheat Sheet
This handy Coach Your PO cheat-sheet includes questions to help you define the problem, and links to handy, easy techniques to help you coach your Product Owner
Enter e-mail to download a clickable PO Cheat Sheet
This handy Coach Your PO cheat-sheet includes questions to help you define the problem, and links to handy, easy techniques to help you coach your Product Owner
Enter e-mail to download a checklist to help your PO manage their time
This simple checklist and calendar handout, with a coaching article will help you define the minimum enagement your PO must have with the team
Enter e-mail to download a checklist to help your PO manage their time
This simple checklist and calendar handout, with a coaching article will help you define the minimum enagement your PO must have with the team
Internal Conference
Checklist
Internal Conference
Checklist
Download a detailed How-To to help measure success for your team
Motivate your team with the right metrics, and the right way to visualize and track them. Marcus presents a detailed How-To document based on his experience at The Bungsu Hospital
Download a detailed How-To to help measure success for your team
Read about Visualization and TRANSFORM The way your team works
A moving story of how work at the Bungsu Hospital was transformed by a simple tool that you can use to help your team.
Read about Visualization and TRANSFORM The way your team works