Are you Agile or Pseudo-Agile?
Today, every organization expects its projects and processes to be Agile-driven. It becomes the manifesto of top management to be strictly Agile in their processes. However, somewhere the organizations end-up following the scrum rituals more literally then actually implementing, executing, or rather administering them in their processes. Scrum is not limited to merely following the tradition of performing the scrum meetings, daily stand up meetings, and other ceremonies as a time-boxed event. Instead, it is intended to support the agility of “change” that slowly creeps into the project and their deliverables destroying the timelines of scheduled events that were expected to happen. It results in “Pseudo-Agile” practices and processes where the team members follow the scrum ceremonies as a stereotypical practice but still for deliverables adhere to follow the waterfall principles. It is a dangerous situation that needs to be identified and enacted upon. Sailing on two boats can be futile.
Scrum, by the definition from the dictionary, implies a set of practices used in an agile framework emphasizing daily communication and the flexible reassessment of plans that are carried out in short, iterative phases of work. So, to imbibe scrum it is important to note that the agile framework should be well-adopted and practiced within the organization. Let’s get deeper into our understanding of the organization to get versed in its framework requirement. An organization can be either product-based or service-based. Product-based like Oracle, Apple, etc. are those who develop products for customers while Service-based like Wipro, TCS, etc. are those who provide services to work on these products for their client.
In Product-based organizations, it is easier to follow the Agile framework as the top management can change the processes and the principles to be followed from product designing to product delivery and post-support. However, in Service based organizations it entirely depends on the client being served. The project delivery cannot follow the agile framework if the client doesn’t follow them. At ground reality, the deliverable has to have a “user acceptance” which if has a scheduled date from the onset of the blue-printing phase of a project with no revisions possible then the “agility” was never ought to exist. In such a situation portraying being Agile-based becomes a dangerous game as then the project follows the path of becoming “Pseudo-Agile”.
It doesn’t mean that Product based have won the trophy of being “Agile” while Service based are still running in for the game. It simply means that in case of Service based organization there’s an extra entity “client” which plays an equal or rather most important role when following an agile framework. Thus, both service, as well as product-based organizations, are running for an altogether different game. The service-based organization runs more of a relay race where synchronized coordination between the client and their service provider is needed to win. While for a product based organization it is a long-run where the decision-maker and its vision play a pivotal role in structuring the policies and processes within the enterprise and its subsidiaries to maintain the longevity in the game to support the momentum.
After coming on terms with the kind of organization and the commandments or principles outlined in agile it is important to understand the delta changes that could commence the pseudo-agile journey. Let’s look into these multi-faceted key points:
* Welcome change even in late development: Welcoming the change does imply that the client/customer will be happy as his opinion is being valued with helping the agile process at the proper place. However, every change might not reach all the intended users, instead it may reach only certain “categories” of users. Thus, if looked upon strategically this slight miss will call for another iteration of changes to reach the left-over users or maybe rollback of all the changes. This could lead to multiple pitfalls like recursive unintended changes and/or rollovers, unstable products, and many others.
* Deliver working software frequently: It happens many-a-times that this block-delivery of working software is a façade chosen by Scrum masters (or sometimes maybe the product owners) to shows that there is a continuous change in progress. But instead, those changes are nowhere in sync with the strategic goals of the project charter. When the workforce does not turn the changes into concrete work-item and is over-looked by the management on strategic vision, pseudo-agile creeps in easily.
* Sustainable development maintaining constant pace: ‘Gold-plating’ is a common term in project management but widely misunderstood in an Agile-driven process. In agile, the teams are supposedly empowered to change the requirements based on the feedback by the end-user but the requirements should not lead to scope-creep or maybe not felicitated with the intention of gold-plating the customer. This vision is vital and is required to be manifested by each of the team members.
* Documentation: How much documentation is good-enough depends entirely up to one’s prerogative. It can differ from person to person of how mature understanding the process guideline maker has about the agile process and its methodologies. Documentation is one of the major and most misunderstood stumbling blocks. The comprehensive documentation is essential within any process but an “unfinished” understanding of agile may compel for a shallow or restrictive resultant. Such a discursive course for the contextual change is non-remedial and not easy to detect.
* Value-oriented vs Metrics-intensive: Last but not the least, a transition from being metric-intensive to value-oriented is not a straight road. It’s a journey that everyone has to traverse while formulating the equation towards agile. If the metrics are the final goal to achieve then it is confirmed pseudo-agile. Metrics help us with value-oriented vision providing us clarity on our limits and our expectation. They are not the goals instead they are the goal-keepers who help us to not fall on procedural blind-spots. If instead of becoming value-oriented the process guidelines are misinterpreted as metric-intensive, then the descent from ‘doing-agile’ to ‘being-agile’ is unavoidable.
There could be several other factors that could account for being pseudo-agile but these are the most common key-factors faced by organizations. It is important to understand that it is always better to know what you do not know than to pretend to know it. It is very well said by one of the renowned author Richelle E. Goodrich “Lies don’t fit snugly into disguises. Eventually, the cloak falls off and you’re left staring at the naked truth which is always an uncomfortable situation.” Let’s hope this article helps to identify the danger before it jeopardizes our process guidelines in the strategic run.
Link to my other article: https://medium.com/@agreta.gupta/in-agile-do-we-need-managers-or-leaders-ddca9c81f598