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

Posted in: Agile Methods
Like this article:
  7 members liked this article


osjo73 posted on Tuesday, January 31, 2017 5:43 PM
This article articulates the "problem" with agile practices in real world situations. The reality is software delivery projects are judged based on short term goals. The incentives in organizations is to create "something" fast, with least amount of "friction", cheapest amount of "labor", faster, and better. Well the ability to deliver software faster and more easily has been achieved. The challenge is not to delivery software so fast, ignoring the analysis piece because it is so easy to delivery software. And the thinking is once the software is delivered we can fix things later in another sprint. You don't have to go with 2 years up front analysis before you start development...but you also dont have to start development 2 weeks before the project starts. But like I said, the incentives are set to deliver software quickly. And the support of that software will have to deal with the consequences of the decisions made later. I think Agile is pushing software development too far in the direction of code now fix later. It works better when users know exactly what they want. If users, like we all know, don't really know what they want, how to articulate what they want, nor have the time outside of their day jobs to analyze their business processes to ensure the decisions they make are sound for the present day as well as the future.
Only registered users may post comments.



Copyright 2006-2024 by Modern Analyst Media LLC