Improving the Continuous Improvement

I always see people go gaga over agile development methodologies. While I agree that agile has its own advantages, I disagree on the fact agile is an all-powerful and does it all kind of methodology. However, if executed right, agile does have the capability to be an all-powerful methodology. Although the advantages outweigh the perils of agile, the perils if not properly addressed can put the business value and relevance of the solution at risk.

One of the dangers of agile is the assumption that agile practitioners make. Agile assumes that the business users have a thorough understanding of what system needs to deliver and relative priority of all the features and hence these business users are often left alone to make these decisions. Agile also assumes that the business users are objective enough to see beyond a software solution and change/challenge the existing process. However, more often than not, most of the business users are aware about their part of business and their perspective of the new software is to make their work easier. Seldom do they have the time to ponder where their current business process is lacking. Rarely do they reflect on the implications of their processes on the overall business, improvements in their own process or even when software is not the effective solution to the problem. Moreover, the agile team (developers and testers) are solely reliant on these business users to accurately contemplate overall business needs and their priorities. And hence the agile development team only comes to play once they have a prioritized list of requirements. This leads to the agile team having limited knowledge about business processes and rules, which in turn deters the team to challenge the business users. 

The fact that business users get minimal support in requirement identification and prioritization puts the agile project in jeopardy.

Agile practitioners are proactive in dealing with such situations. One key advantage agile provides, over traditional development methodology, is the continuous improvement over each iteration. Hence, we have retrospectives. These retrospective sessions, I have observed, are unappreciated by the agile development team and are underutilized by the business users. The purpose of retrospectives is to figure out activities (and people! Yes, you read that right) that went well/needs to improve. However, the problem with retrospectives is that the focus is too narrow and the team often discusses improvising of already agreed processes rather than challenging the very existence of certain processes or the scope. Moreover, the team never questions if the business user, they are working with, is objective enough to look beyond the current set of business processes and practices. The team never questions if the features they are building provide the best solution to meet the business requirements.

Agile practitioners are constantly trying to improve the practical implementation of agile in software projects. However, a Google search for better agile methods or agile systems will lead to hundreds of books and blogs emphasizing on improving agile practices to provide better software solutions. We will hardly find any material where agile teams are encouraged to challenge the business case (including the money) for a requirement or challenging business user’s logic for prioritizing requirements in a specific way. It is assumed and expected that the business user has to independently figure out everything right from creating the business case, to getting the funding for developing the requirements, from collaborating with all the stakeholders, to gathering and prioritizing the requirements. When a single user has so many important decisions to make, there are chances for the things to go wrong. And for software projects, it is widely known that if anything has a slightest chance to go wrong, will go wrong. Agile teams need to extend their support to business users to deal with such situations, and from what I have observed over the years is that the business users highly appreciate such help and more often than not business users are likely to include the viewpoints of agile teams in planning the iteration, scoping and prioritizing. And if this happens once, it happens again and again and it forms a cycle.

So, how do agile teams extend their support to the business users? How do agile teams ensure that they challenge the status quo of requirement prioritization? How do agile teams ensure that they question the already set stubborn business process? How do agile teams improve the continuous improvement?

One simple answer to all of the above questions is to have a proficient agile business analyst in the team ;)


This article is based on the book "The Power of Agile Business Analyst" by "Jamie Lynn Cooke".


Author: Saurabh Shah