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.

Mahesh Yadav

Mahesh Yadav

Module Lead

Mahesh Yadav is Module Lead at 3Pillar Global. In his current engagement he works for a client which serves some of the leading names in the Pay TV circuit and are considered to be global leaders in Advanced Advertising solutions. Mahesh has almost 4 years of experience in designing and development of web applications using JAVA, Spring, JPA, Web Services and big data technologies like SOLR, ElasticSearch, and Cassandra. He started his career with 3Pillar Global itself and has keen interest in big data technologies.

Leave a Reply

Related Posts

Costovation – Giving Your Customers Exactly What They ... On this episode of The Innovation Engine podcast, we delve into “cost-ovation,” or innovation that gives your customers exactly what they want – and n...
AI & Machine Learning Will See You Now, and Other Takea... A 3Pillar team and I spent a few days in Santa Clara recently for the 12th annual Health 2.0 Conference. As usual, we spent some time after the confer...
DevSecOps – The Latest Trends in Application Security ... I spent a very rewarding couple of days at DevSecCon in Boston recently. The conference focused on DevSecOps, which is a catch-all phrase for addressi...
Designing the Future & the Future of Work – The I... Martin Wezowski, Chief Designer and Futurist at SAP, shares his thoughts on designing the future and the future of work on this episode of The Innovat...
Selecting The Minimum Viable Toolset for Product Managers Recently I was attending a machine learning conference and during a break, found myself deep in conversation with fellow product managers. As is typic...