Is Your Agile Software Development Truly Agile?

If you ask any developer, team lead, or project manager today, “What is your approach to software development?” the most common answer that you will get is, “We do agile software development.” Some may tell you that they are using “Modified Agile.” Seriously, how can you modify something that hasn’t been defined?

If you dig in more and ask how they follow agile, people will usually talk about the Scrum framework, various artifacts and roles present in Scrum, and how their project matches Scrum. This is where the problem lies. People don’t fit the Scrum framework into the project according to its needs but rather fit projects into the Scrum framework in the interest of following a standard which is hot in the market. This can end up creating unnecessary work and making things more complex than required.

But this is not agile software development; agile doesn’t talk about sticking to a standard, and even the Scrum framework doesn’t tell you to follow it blindly. Only a few people will talk about actual agile software development, because there are very few people that are doing it in its true sense.

Agile is all about allowing companies to innovate and evolve their products more quickly. In terms of Scrum, these are called “inspect and adapt cycles.” So one of the things that agile software development is truly all about is following those inspect and adapt cycles. An inspect and adapt cycle requires a retrospective review of the process followed during each iteration and modification of the process if required for the next iteration.

This means your agile development teams get better and more efficient with every iteration. These inspect and adapt cycles are at the heart of the agile software development process. Yet they are frequenty the most ignored aspect of agile software development and are sometimes completely missing. Now, one can imagine what kind of software development happens using a process which either doesn’t have its heart or its heart doesn’t beat properly. I will be sharing in brief some of my past experiences from different projects in which I have worked just to emphasize the importance of these inspect and adapt cycles.

There was a project in which we used Scrum, and used the concept of the post-mortem after every iteration to discuss lessons learned. In a usual post-mortem, all teams (development, testing, product & operations) were invited to discuss what went well and what did not go well. Usually, in such post-mortem meetings, teams tried to highlight the mistakes and shortcomings of other teams and the good things about themselves. The funny part was, different teams highlighted the same shortcomings of the same other teams repetitively in subsequent post-mortem meetings but every time in a different manner. This showed that teams were making the same mistakes and facing the same problems in each delivery cycle but not improving them, in turn reducing the overall efficiency of teams. This was because no discussion happened regarding what should be done to remove those shortcomings in those post-mortem meetings. So we were only inspecting the things but not adapting them for next cycles. Apart from this, just think about the resources that were used in those meetings. Did we really follow Scrum?

In another project, which was stable, we never did post-mortems after an iteration. We were doing development from one delivery cycle to the next and were blindly following the same process again and again. The process which we followed had one flaw, i.e. the concept of “pre-existing issues.” These issues are those which already existed in the system and were unveiled in the current development cycle. Such issues were usually marked “out of scope” due to time constraints or other factors. New developments were usually performed on top of these issues. Though such issues were logged in JIRA for later consideration, this supercharged the technical debt unnecessarily. To justify the action as “deferring the decision to last responsible moment” would be the wrong usage of the terminology here. Initially things worked well, but after a few development cycles team velocity started decreasing and fire fighting crept in to every cycle. Later, it was observed that the team was spending a good amount of time and effort identifying whether an issue was pre-existing or not. If we had followed inspect and adapt cycles, then the problem caused by the concept of “pre-existing issues” could have been identified earlier and would have saved lots of time and resources.

It is not that my experiences are filled with subpar projects. I have worked on projects in which inspect and adapt cycles were present. On the basis of these cycles some bold decisions were taken which made those projects really successful. These projects helped me in understanding the importance of inspect and adapt cycles in agile software development.

To give you an example, I was involved once in a project that had very stringent timelines, frequently changing requirements, and a client that wanted very frequent deployments on production. We started with our general way of working using Scrum. After a couple of iterations, however, it was identified that we were behind schedule. It was later observed that this happened due to a lot of discussions between testing and development teams even when requirements were frequently changing. So, a decision was taken for not involving testing team (to avoid a lot of back forth discussions) at all in the project and making the development team solely responsible for everything from deployment to production. This decision actually resulted in drastic improvements, with ahead of time deployments on production along with great appreciation from the client in the end. Similarly, in another project, a decision was taken for removing the dependency of the testing team on the operations team for deployments. The testing team was made capable of doing deployments for their testing, although operations team was there for helping them out if need be. To support this, the operations team shared the knowledge of deployment tools and utilities with the testing team, which resulted in the timely completion of test sprints.

In short, to follow agile in its truest sense is to evolve and innovate with time, requirements, and environments.