Agile is Fragile

Handle with Care. Agile is very easy to Break, very hard to Nurture and Preserve.

Six years since Agile was born, when I revisit the original Agile Vision and Values, it feels nostalgic. The Agile Paradigms that literally caused a revolution in the way people build software today seems to be begging its communities to realign.

Many in the Agile Community today, have lost sight of the original Vision of Agile and have got caught in deep theology conflicts as we see it in emerging practices and trends in Agile, loosing its “focus and alignment” to the basic Values and Principles enshrined in Agile.

I keep asking myself “Is Agile today really Agile? “ Join me in evaluating what people are doing, when they claim that they are practicing Agile.

Here are some real-life examples of Agile Methodology Practices implemented as Agile, which are completely out-of-sync with the original Vision and Values of Agile:

1. Agile Software Development is done through Fixed Bid Contracts. (some Agile Methodologies like Scrum are coaching organizations how to build such contracts for Agile Projects)
2. Agile Software Development is done on a set of defined process framework. (some Agile Methodologies like Scrum have been very prescriptive and lay down rigid practices as rules of the game)
3. Agile Methodologies are offering Certification Programs for individual and organizations for conformance to the processes and practices that they define.
4. Customers are not educated on the Agile Values and therefore they do not actively collaborate and participate along with the team in their software development endeavors. Agile teams to overcome this create a Proxy Product Owner who finally is unable to fill in for this purpose and the project fails.
5. While Agile Values in principle can be nurtured only in collocated small teams, organizations scale up Agile to distributed not collocated teams, without due regard for its implications and finally blame Agile for their failures.
6. Management of Software Development Organizations do not change their traditional polices and are unable to nurture the Agile Team Values due to which the agile teams become inefficient and unproductive
7. Managers of Agile Software Projects do not understand the principles of Agile Project Management and try to manage Agile Teams with their traditional ways of formal command and control style of management.
8. Management does not provide the open-space work environment that the Agile Teams need for nurturing face to face informal communications and information radiators are missing.
9. Management does not take enough care when composing cross-functional Agile teams, due to which the teams lack the spirit of integration and team work and are not able to implement the Agile Engineering Practices well due to inherent skills lacunae.
10. While many Agile Teams are serious about Agile, the Manager, the Management and often Customers too, do not keep up their commitment for collaboration, trust, empowerment and support to the team, and become the reason for teams’ failure to deliver value to them.
11. I have seen software organizations implement Agile in a CMMi style and expect the Agile Teams to create their Agile Practices within the framework of the CMMI process.
12. Agile Methodologies like Scrum is inculcating a spirit of conflicting stance into Agile Teams teaching them skills to guard themselves against the Management and the Customers. This totally goes against the imperative Value of Collaboration, Transparency and Trust in Agile. (the Pig and the Chicken story is a misnomer paradigm reinforced by the Scrum Master being labeled as a person who protects the team from outside adversaries like the Customers and the Management)

What pains me is the way our community is innovating new principles and practices in Agile that are simply not aligned to the original Agile Vision and Values. They seem to make their “Branded Practices” more important than the Principles and Values that drive Agile. In the processes such branded practices are becoming rote, as they seem to have forgotten to align each of their new found practices to the original principles and values in Agile.

For those who are new to Agile, I would like to recall what Agile was meant to be.

Agile Vision

To create a new alternative set of paradigms that can help people build good software and deliver true value to customers, in the face of volatile scope and unpredictable development environments

Agile Vision Rationale

The software industry was going through a crisis as many software development projects were failing to deliver “Value to Customers” (refer Standing Survey Reports), in the face of fast changing technology environments, volatile requirements scenarios, ambiguities in our ability to predict people capabilities and the need to build better software, faster and cheaper, to make best use of business opportunities that had really small and shrinking time windows.

Agile Values

The Agile Values were a set of paradigms that could reinforce the deficiencies in the then methods for software development and still enable them work in such situations.

They were created as a set of strategies to beat the problems of uncertainties and volatilities in software development environments

1. Customer Collaboration (over contract negotiations) : By actively collaborating with the customers in jointly developing software together, the inherent weaknesses in the development system could be curtailed to a large extent. The weaknesses could include those that are caused through formal documentation (translation errors) and due to poor communication and interactions with the customers in eliciting their true needs, clearly, completely, correctly and consistently. It was also known that the developers would lack the business domain competence and the customers would be ignorant of technical implications of technology choices and therefore, when both would work collaboratively and jointly, these weaknesses could be overcome. Such collaboration with customers, necessitate changes in the way development organizations decide their business policies and customer management practices for providing their services to customer organizations. So contracting with customers on fixed terms was not possible in such situations.
2. People Interactions (over processes and tools) : Software Development needs extremely high levels of creativity, innovation, commitment and discipline. Knowledge workers cannot bloom in a strictly defined process environment. They need a degree of interactions, informal face to face communication with stakeholders, ability to change directions midway, learn through the way and build the best possible solution in a given context. For such activity to happen, teams have to be cross-functional, empowered and self organized through empirical process and tacit collective wisdom. They work as a team and compliment one others skills and competencies, learn faster and contribute better in an environment of high team morale and individual motivation. To succeed, they need to nurture team values of trust, transparency, commitment, honesty, respect, courage, discipline and proactive and informal communication both ways. This enables teams produce highest value to customers. The premise is that subjecting knowledge workers to a set of defined processes and controlling them over a set of assigned tasks through automated monitoring and tracking tools, does not produce good results. It was therefore imperative that Management of Development Organizations have to make serious paradigm shifts and create revised organizational structure and management policies to manage their people, processes and projects to stay consistent with Agile Values.
3. Working Software (over comprehensive documentation). The traditional contemporary software development and project management practices were built over predictive planning and structured management control systems. It was based on process maturity models and believed in the verification approach to quality ( do things the right way, right things well get automatically built). In an unpredictable situation, this would not work. Agile Values brought about a Validation Approach to delivering Quality, and Quality was defined as Customer Value. Agile innovated new paradigms for a Validation Approach to software development through empirical process that adaptively evolves through contextual feedback and learning. ( find the right ways to build the right thing and keep iteratively validating if right things are being built)
4. Responding to Change (vs following a plan) To compliment the above Values and implement true Agility, the Agile Community embraced Incremental and Iterative software development paradigms in an informal context to help them learn and validate faster and allow for adaptive and iterative planning to meet the Project Goals more efficiently. This was to replace the sequential predictive ways of software development (like Waterfall Model, V Model, Incremental Model) which did not have the ability to keep the cost of change curve flat. However this way of developing software iteratively and incrementally, needed software programmers to learn new software engineering skills that includes the “how-to” of Incremental Architecture, Refactoring, Evolving Design, Test Driven Development, Continuous Integration, Test Automation, Test Refactoring, Coding Standards, without which they will not be able to build working software consistently.

I wonder what we could do to bring back Agile Methodologies on the right track all over Again ?