Doing Agile versus being agile.

Ask someone who is talking about Agile as to what are they trying to accomplish by "doing Agile". They only seem to have "motives", they do not seem to have "goals". If they were trying to achieve something by being agile, they would be more focused and be able to figure out how to use agile concepts to their advantage in accomplishing their goals quickly.

Being agile is a default start-up culture. More often than not, larger enterprises are more comfortable making a mockery of it and are unable to figure out the common sense behind agile.

Agile concepts tell us how to beat complexity, unpredictability, volatility and risks in software development, in an imperfect world. The agile strategies are very straightforward :

1. Increase Employee Engagement: so that we are able to create an environment of trust and empowerment, so that people enjoy what they do and therefore increase their "productivity" in whatever they do. This this the theory of what is called "positive psychology" , "happiness advantage" or "flow". It is like a "commando culture", who are willing to risk their lives for accomplishing their goals.

2. Accelerate Learning : while working in an imperfect world, we need to learn to build our capabilities fast, to do the right things right in a given context. We need to therefore learn to manage our learning, so that it happens quickly. Collaboration, the PDCA loop, Retrospectives and Fast Feedback are key to fast learning. This should result in a true Inspect-Adapt culture working in an imperfect world.

3. Incremental Innovation: Accelerated learning should result in enhanced capability that enables us to cause continuous improvements to the ways we do what we do, by learning and discovering newer and better ways to do the right things right the first time.

4. Increase Speed: All the above should enable us to increase our speed of continuous delivery of value to our customers, thereby increasing the ROI of our work. We also on a continuous basis learn to identify and eliminate waste to prevent us from slowing down.

As far as Agile is concerned, if we see the above results in a project endevour, they would surely be harnessing agile concepts to their advantage. If not they would be doing Agile as a ritual, a dogma process, without knowing why they do, what they do, the way they do it. 

That's the unfortunate part when instead of being agile, they are doing Agile.

Resume Driven Agile

A couple of years ago, we had an evening talk on Agile by Venkat (Dr.Venkat Sumbramaniam) that was organized by ASCI (Naresh Jain and group) at Bangalore for the local Agile User Group. The topic was "How to approach Evolutionary Design". We were fortunate to have sponsored that talk.

During the session, I was fascinated by a term he explained in humor - RDD - Resume Driven Design - where Architects play around more with power point than code and implement technologies for the customers based on what they would like to carry on their resumes.... not what the customers need.

Our recent discussions on the APM forum on whether hacking (coding) should be a competency in Agile, motivated me as much. Many respondents especially from the "Certified Scrum XOs" felt that Agile Coaches and Agile Trainers need not know software development as in coding, testing, refactoring, CI etc. I am shocked by their understanding of Agile Software Development and its rationale, in terms of what is carried in the Agile Manifesto and Agile Principles.

The reason our software development industry has had the highest records of project failures (source: Standish Chaos Reports) is that people who manage software engineering process, quality assurance and quality control have rarely understood the intricacies involved in programming and design. By my own experience, more than 95% of the managers, leads and staff involved in Process Engineering, Quality Assurance and Quality Control in our software development industry have never written productive software ever that was paid for.

We cannot carry the same burden into Agile. My response to a post where someone questioned if coding should be a competency required to work in an Agile environment, I answered :

".....I did not say that we want a hard rule that Agile Coaches should know coding as a mandate.

However what I see in real life is that when Teams transit to Agile from Waterfall, they have to learn new evolutionary design engineering and programming skills, which may not have been necessary in waterfall.

Since they have to code in an IID environment, they need skills to code with TDD kind of a strategy, they need to set up a build pipeline for CI, they need to understand the need for and implement a continuous refactoring of design, code and tests as requirements evolve over each iteration. They need to set up automated testing environmentfor continuous, repeated regression testing with every build, that happens multiple times a day.

I see most teams stuck on these, and the Agile Coaches are not able to help them resolve these competency gaps. Otherwise we need an Agile Process Coach and an Agile Engineering Coach for the teams helping them at least in the initial phases of learning and development.

I therefore felt that if you have only one Agile Coach, he should be able to play both roles well, which otherwise will call for a supplementary coach as in Cricket. We have a bowling coach, batting coach, and fielding coach and the main coach.

However inside the Cross Functional Team, I would still insist that everyone is a "combatant" as in a commando team. If you cannot use a revolver to defend yourself, you cannot be in a commando team, lest other members in the team spend more time defending you than working towards the team goals."

In serendipity I found a new acronym for the context.

I am now pleased to coin a new acronym for the Agile Community (especially for the Scrum Community). RDA - Resume Driven Agile - for those who wish have agile certifications but do not wish to know, understand and appreciate how software is engineered and built in an Agile Software Development Environment (Incremental and Iterative)

Scrum for Waterfall

I have been hypothesising on some ideas to create a modified version of Scrum for teams in larger traditional software product organizations who could use Scrum practices in waterfall-incremental software development scenarios in a more fomal manner. This may not be Agile but would still follow Scrum Practices with modified Scrum Principles.

You can find my blogs on this thread at http://scrumforwaterfall.blogspot.com

Flip Scrum and wow ! you have a new Product

Flipping SCRUM upside down may lead you to innovate and discover new features, advantages and benefits from SCRUM that was never intended of it.

Many times people find unexpected advantages and benefits from Product features which was never intended in the product design. You may not call it by-products but they may deliver great value in specific contexts.

To illustrate this, let us consider Beer as a product. People consume beer for health and happiness!!! But I have also seen my wife using beer on her head to condition her hair. I have used beer as a great nutrient on my orchids. People use beer in a shallow bowl in their gardens to trap snails too. I am not sure if people who designed and produced beer as a product, intended to offer these advantages and benefits from beer as a product. They were “discovered” by innovative users in need of solutions to their problems.

We all know the features, advantages and benefits of SCRUM as it was designed for. Managing chaos and minimizing risks through iterative development in the face of volatile requirements and a high degree of unpredictability in a software solution development environment. SCRUM was intended to be a carefully crafted strategy to help teams “inspect and adapt” in fast changing volatile situations. This was expected to be achieved by empowering a cross-functional self-organizing team and supporting them accomplish a set of defined goals in an empirical process environment, incrementally and iteratively.

For this strategy to succeed, organizations implementing SCRUM had to invert their pyramid structure, nurture and reward team-work and group accountability through a management process driven by “servant leadership”. This would entail management stakeholders to empower and support a cross-functional team, provide them the right work environment, leadership and motivation to enable the team self-organize themselves through collaborative leadership and accomplish their goals.

Who flipped SCRUM ?

Software Product Organizations embracing Scrum in a distributed product development environment found exceptional benefits from it when they applied it on Product Engineering Teams innovating and evolving their product through iterative Systems Engineering. Such teams were highly mature, motivated, proactive and disciplined. Through this they were able to manage the evolution of their product vision and architecture iteratively and in much less time.

This helped them discover the power of Scrum. They now took this to the development teams in a distributed development environment, gave them a clear set of requirements, a clear product design and expected them to use Scrum to build the product as per specifications. They found that if they had these development teams implement “30 day Iterations” and hold “daily stand-up meetings”, they could monitor the progress of development more effectively. They also found that using Scrum, the development teams could escalate the issues affecting their “productivity” timely to the management which helped them take timely corrective and preventive action. This enabled the management reduce the cost and time of development significantly and generate a higher degree of assurance and predictability of the product development phases (coding, testing, integration and release management)

The Product Development contexts here were very stable, with Product Requirements and Product Architecture well understood and meticulously planned and designed for its integrity, performance and quality. They were only aspiring for ways to have it built most efficiently, with least cost and time.

Product Managers found that wrapping Scrum practices over the existing traditional management and engineering practices of their development organizations, helped them micromanage development teams and their productivity. This also reflected in a set of clear results for them and they found that by keeping both the teams and their managers on their toes, every day, every iteration, they were able to save on costs and time significantly, as also generate an ability for them to track the progress of development with each iteration. This gave them confidence, predictability and assurance of the progress in product development so crucial for Product Release Planning and Product Management. They had flipped Scrum and made it work for them.

Why Flipped Scrum ?

The implementation of Scrum in the development environment was different. Teams were not empowered and self-organizing. Managers were micro-managing the team and were necessarily not servant-managers. The process formality was high and clearly defined. Productivity and Progress was tracked by the team, by the managers and by the product management stakeholders fervently and metrics generated to prove results.

Teams were told what to do, how and when based on the predefined release plans and individual productivity metrics (team velocity). They were managed, supervised and controlled by their managers who were held accountable for the execution of the Iteration Plans and the Release Plan as per baselines approved. They did that, it worked and they called it Scrum.

They had Product Managers playing the role of Product Owners cutting, copying and pasting “stories” into the product backlog from clearly inspected, approved and baselined Product Requirements Specifications. The stories reflected the development of each Feature based on clearly inspected, approved and baselined Product Architecture and Design Document. Many stories actually looked like “Tasks” well defined, coordinated and structured for the teams to implement and build them in the 30 day iterations.

Project Technical Leads were appointed as Scrum Masters to supervise the teams on a daily basis and escalate to the management the issues reported by the team members in daily stand-up meetings. The Scrum Masters were made accountable and responsible to ensure that the team delivers the features given to them for development for one iteration, at the end of the iteration.

Product Managers, acting as Product Owners, thus would receive the features developed by the development teams incrementally and they could send these deliveries to the Product Testing teams for validation. Bugs reported by the Testing Teams would be sent back to the Development Teams as new stories added into their Product Backlog. Not to mention that this enabled the Product Managers and the Development Managers to track the quality of work being done by the development teams in terms of bugs per stories and haul them up for it. Real tight control over the scope, quality, time and cost of product development was achieved in a distributed off-shored environment.

Teams here religiously perform all the Scrum Ceremonies. Iteration Planning is done by Scrum Masters in line with baselined Product Release Plan. They hold daily stand-up meetings in lieu of filling timesheets. They are encouraged to report or escalate issues they face in doing what they are doing. The progress in compiled by the Scrum Masters and reported to their Management on a daily basis. Scrum Masters maintain the Sprint Backlog, create and assign tasks to team members, update it on a daily basis based on reports at stand-up meetings and populate the burn-out charts. Scrum Masters take timely corrective and preventive actions to ensure burn-out charts are burning out correctly.

Product Managers give the Scrum Masters the Baselined version of Product Requirements Specification Document and the Product Architecture and Design Document. They are asked to convert this into stories and populate the Product Backlog for the team as per the agreed sequence in the pre-defined Release Plan.

Teams are brought in into Sprint Retrospectives after each Iteration Delivery and Scrum Masters along with Management Stakeholders tell the teams what went right, what went wrong and what they should be doing in the next iteration to ensure that the next iteration is always better than the previous one. And so goes the continuous improvement in software development.

They love this type of Scrum and so do I. It adds value to the Product Management Stakeholders in Micro-managing product development efficiency in a distributed product development environment. It helps all of them to save more money and more time. So why not let them use Scrum this way.

Let me call this new product “ Scrum-F ” to mean Scrum that has been flipped. This may be the best discovery and process innovation of the decade we are in. We already have Scrum-A, Scrum-B and Scrum-C defined and published by Jeff. So Scrum-F should be able to live undisturbed.

Have a great time flipping SCRUM !!!

As long as it adds value to you, it should be a great thing to do.

Credit Crisis ? or is it a Credibility Crisis

One hour past midnight, I get an emergency call from the hospital where my father was in the Intensive Care Unit after having suffered a massive heart attack a few days ago. I rush to the hospital with my brother-in-law. My father, who is a doctor himself, has revolted in the hospital ICU. He tells us to move him out of this hospital immediately, as he feared that the specialist doctors attending on him have been grossly negligent, complacent and self-serving. He said this may eventually kill him. We stayed with him till day-break, discussed his concerns with the doctors and moved him out in an ambulance to another hospital, where he eventually recovered.

Looking in hind sight, we wondered how my father, being a doctor himself, could question the integrity of senior and experienced specialists in a reputed hospital. Simple ; he knew the trade and the trade secrets; the good, bad and the ugly faces of the medical profession.

The “Credit Crisis” the world faces today, which is now snow-balling into a historical world wide economic recession, is the handiwork of a few greedy bankers who wanted to make a quick buck, hook or by crook, taking the economics of the whole world for a ride with them.

Kent Beck, the father of Extreme Programming, talks about four new Values for Agile to work. He calls it a customer value focussed “Responsible Development”

• Responsibility
• Accountability
• Transparency
• Relationships

Does this ring a bell? If the American Bankers were Responsible, Accountable, Transparent and Honest, we would never have had this Credit Crisis nor suffered the irreparable damage it has caused in inducing a world wide economic recession and the untold suffering it will cause to “Mankind” for years to come.

Do we learn a lesson?

The only way to survive this mess is for Organizations and Entrepreneurs to build a new set of business rules that goes by the Kent Beck’s four values for Agile.

This will surely help build a more realistic and responsible market place, a more accountable corporate society and an honest, transparent world that can prosper eternally.

This was never difficult, but today it has become an “Imperative for Survival”. We can still choose to hide our cupboards full of skeletons, but for how long can we do this?

Thanks Kent Beck, for your courage in bringing the harsh reality of our ignorance to the fore. May be one day the world will see the truth behind the “Agile Values” proposed by you.

Harnessing the Power of Agile

I am not sure if we all have heard of a Tetrahedron. It is a solid object with four sides, each side is a triangle. Something like a Pyramid. Here is one I found on Wikipedia (click on the image to see it in a 3D motion on the original site)

I am using this object to illustrate how one can understand and harness the power of Agile in a Software Development Organization's context.

If we expect Agile to deliver Value both to our Customers and Ourselves, we need to understand the rationale behind "How Agile was Designed to Work". In the absence of this understanding, implementing it anyway convenient, may actually land you " from a frying pan to fire". This has been my experience so far in about a decade practicing, coaching, training and consulting with organization in the implementation of Agile.

Here is how I choose to represent the core architecture of "Agile " using the concept of the Tetrahedron.


Software Organizations, before jumping into the Agile Bandwagon, should understand its implications to enable harvest the full potential of Agile in their enterprises. Here are some tips to make this journey comfortable and fruitful. Profitability and Customer Delight are imperative outcome, if you undertake this journey in a well planned manner.

Agile is our destination (Our Goal, Aspiration or Ambition). To reach this destination, one has to choose the right vehicle to ride on, to enable us reach our destination, safely, comfortably and efficiently, while we may also wish to enjoy the journey enroute.

What I see in most cases where Organizations decide to embrace Agile, undertake to travel to Agile, on vehicles that have one, some or all of their tyres punctured. I am using this metaphor to illustrate a "Strategy for this Journey to Agile"

The vehicle you travel to reach Agile has four wheels. You have to ensure that all the four wheels of your vehicle is in good shape, for you enjoy the journey and move forward. Even if one wheel is deflated or is malfuctioning, your have a breakdown and you cannot move forward. This situation is far from reaching the destination or anywhere close to it, which usually will remain an unfulfilled aspiration.

In the Agile Pyramid illustrated above, there are four sides to this Tetrahedron. Each side is equivalent to one wheel on the car, that has four wheels. Your organization has to travel in this car to reach your destination, Agile.

Check your First Wheel : Software Engineering in IID

Your organization's competence in building software using the Incremental and Iterative Development Method (IID). This method was originally innovated by Tom Gilb (http://www.gilb.com/) and he called it the Evo Model (Evolutionary Model). This may also be the first station you have to reach on your journey to Agile.

This is pure Software Engineering Competence. Your ability to build software incrementally and iteratively. Four key software engineering skills that you may need competence in your team to do IID right are: (1) Incremental Architecture and Evolving Design (2) Refactoring (3) Continuous Integration (4) TDD : Test Driven Development.

Get this right first before you attempt to embark on your journey to the next station. With this wheel in place, and the tyre inflated, you can start your journey and at best you may be able to reach the first station en route.

Check your Second Wheel: Agile Leadership

The next leg of your journey could be very demanding. It involves a cultural change in the way you manage your business and your people. Find out if you are ready for it.

In this culture, you have to trust your customers and your customers have to trust you. You have to trust and empower your people and your people have to live up to this trust. Your people have to work in Teams and not as individuals. You have to learn to structure your organization to harness the power of Team Work. You may need to change your business policies, your management policies, your people policies in the way your recognize and reward teams and not individuals. You have to empower your teams, support them do their job and empower and guide (lead) them to directly deliver Value to Customers.

Your have to "invert" your pyramid structure. You have to understand "how to build and nurture high performance self organizing cross functional teams" in your company. You have to have the commitment, courage, tenacity and determination to undertake this cultural change in your enterprise. You have to learn to manage uncertainties through Adaptive Planning.

Only then can you reach your next station enroute your journey to Agile.

Check your Third Wheel: Self Organizing Teams

The third imperative in Agile are your Teams.

There are the guys who will ultimately help you conduct your business and its profitability. They have to be the right guys, working together as a team of commandos, delivering Value to Customers, incrementally and iteratively in the most volatile conditions full of uncertainties.

They have to plan to deliver value in short iterations, planning for it adaptively and iteratively. They have to be self-organizing to be able to know "how to do" the right things in building the software in a given context. They have to learn to empirically evolve the way they do what they do, and keep improving it on a continuous basis through structured retrospectives at the end of each iteration. They have to be self-motivated, Work as a Team, dissolve hierarchical egos and have the skills to manage themselves through collaborative Leadership. They learn and amplify learning in the team. They are proactive, they are committed, they enjoy working in the team, and they are competent as a Team.

They communicate, collaborate, create and innovate as a Team. They are your COMMANDOS on a mission to DO or DIE. (Their mission : Anticipate, Understand, Meet and Exceed Customer Expectations. To Deliver the right Value at the right Time to their Customers and help build a set of Delighted Customers for your Enterprise).

With such teams in place, you may aspire to reach the third station enroute your journey to Agile.

Check your Fourth Wheel: Customer Collaboration

Now you go find the right Customer to work for.

Someone who values money, who is interested in making money, some one who values ROI (return on investment) and who knows the Value he can get from Software. This person is sure to Collaborate, Communicate and Trust a good Vendor who can deliver Value for Money.

He should understand and know how you plan to deliver value to him through the Agile Strategy.

He should be ready to "contribute value" to enable you to "deliver value" to him. He understand that he can receive the highest Value for Money in a project, only by aggressive collaboration, cooperation, support and co-creation, treating the Vendor Organization as his partner in business. He is able to anticipate, understand, meet and exceed the legitimate expectations of his Vendors, and helps them serve him better.

Customers who are interested in spending their budget allocation and buy software development projects only to expend their budgets for the current year ARE NOT SUITABLE TO BE AGILE CUSTOMERS. I learnt this the hard way, so you need not suffer reinventing the wheel. Get the right Agile Customer for an Agile Project. If not, you cannot reach your destination.

Having said all this, I would like to end by annotating the CLIMAX of your journey:

YOU JUST GOT THE RIGHT CAR, THE RIGHT CUSTOMER (A PASSENGER) FOR YOUR CAR, WHO IS WILLING TO PAY YOU TO FERRY HIM TO HIS DESTINATION.

Who drives the Car ? Your CEO !!!

He is the guy who has to make money for the enterprise and pay dividends to his shareholders.

The fare he collects from the customers to ferry them to their respective destinations is his sales revenue.

The money he saves after expenses he incurs to maintain his "Agile Car" and the fuel, is his profits.

If he is able to earn a good reputation of reliability and credibility in delivering good value to his customers, he may be able to build a good set of loyal and delighted Customers who help him continue running his business profitably, by regularly patronizing his "Agile Car"

I call this car, the "AGILE CAB"

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 ?