Agile Understanding the mindset

There is no single Agile definition. Ask 40 Agile practitioners how they would define Agile, and they would come up with 40 different definitions. Beyond the initial Agile Manifesto which was written in 2001, it has evolved, grown and adapted beyond a single concept.

The very heart of Agile is that it is a mindset. It is something born out of experience and frustration. It is an attempt at improvement, but without being constrained by the words which define it. A key concept espoused by Agile is adaptability and change. It also leaves things to the implementation to define, including concepts like “done”.

Agile Definition – Every Detail Outlined

The starting point of studying Agile, something like Day 1, or Ground Zero, is the Agile Manifesto. However, most people who study only Agile, do not have an appreciation of the manifesto beyond the words expressed. They value the words more than the spirit of where it came from. This is a paradox of Agile, which is a case where the documentation is more important than the work done.

An understanding of Agile cannot be achieved without understanding its cause. The cause is the whole list of what it tries to solve. It tries to address the issues of traditional project management. Without understanding the motivation behind the Manifesto, there are only the words of the Manifesto.

This all goes back to Agile as a mindset. It is not the Manifesto. The Manifesto is what the signatories want to happen. It is ideal. It is not a plan, it is not a framework. It is ideal. But it is the only way to understand the past pre-Agile, its effect on Agile, and the current state of Agile.

The Agile Manifesto

The Agile Manifesto is composed of 4 core values and 12 principles for software development. These serve as the foundation of Agile. These are concepts which are more easily understood without the baggage of waterfall project management.

Agile Manifesto

Agile Values Explained

The four values are:

1. Individuals and interactions are more important than processes and procedures.

There are several reasons that processes and procedures are followed, instead of emphasizing personal interaction. Processes and procedures can be documented and followed regardless of the persons working on them. The persons are considered as roles, with responsibilities and accountabilities. If a process is put into motion, there will always be an expected outcome. If the procedure is not followed properly, there will be an error. It is easier to audit processes and procedures because these can be done objectively. This was the traditional way of doing business, with the goal of a financial bottom line.

Putting interactions and individuals in the forefront change the dynamics of project management. It addresses the additional dimension of multiple corporate bottom lines. It also ensures that there is a continuing relationship between the buyer and the vendor regardless of the project outcome. Companies and organizations concerned with delivering the project would be better able to proceed in other avenues during and after full consultation with their counterparts from the customer side.

2. The project aims to have a working software and not comprehensive documentation of creating the software.

For those who are familiar with waterfall project management, the documentation comes first. It is important to set the parameters of the project before doing anything. By putting in a lot of work into the documentation, there would be a clearer definition of the work to be done, as well as the requirements for both vendor and customer. With well-defined goals, it is easier to sign off on the project because it meets these requirements. If it does not meet the requirements, then the programming team rectifies. With a well-laid out and approved requirements, and design documents, the customer has to accept the project once the requirements and parameters have been met.

The testing and acceptance documents limit themselves to defined outcomes after every action. In this manner, fixing the software is easier. Typically, there are only two revisions needed before acceptance. The amount of work put into the documents do seem insane especially considering that these would not be used after the project has finished. The user manual and training documents would also be voluminous, but also rarely used. In case of any problems, the documents would not be read. Instead, the developers would be consulted. After the project has been delivered, the customer will use the software, but not the documents.

Agile makes use of documentation but not to the extent that it is the law. The aim is to develop working software. To that extent, the development aims to deliver the software in increments. This results in fast and regular delivery of product iterations. The software is used much earlier, tested in the field, and revisions, fixes, and corrections are fed back into the development process. The documentation does not become the focus. The developers are always looking at how to get the iteration “done.”

3. Customer collaboration is better than contract negotiations.

Traditional software development works because it is treated as a business activity. There is a product which needs to be done, and there are developers. The customer has a fixed budget for the project. In most instances, what is not discussed is the limited timeframe and manpower to do the project. The cost of the project stretches according to the duration of the project.

Even before the project begins, there are contract negotiations. If there’s any revision to the requirements, the parties sit down to contract negotiation. Both parties resort to a contract negotiation because there is a contract which is based on the documentation. Both parties are bound to the contract, which in turn is based on a project document. 

Agile Customer Collaboration

If the documents’ assumptions and underlying parameters have changed, the parties have to meet at the table and discuss what they should do because the contract needs to be changed, to include the changes in the project parameters.

An example of a change in parameter would be if the project were to handle a database of 12 million unique objects or IDs, and then a merger occurred and overnight, there is a need for storing 25 million unique objects or IDs. Adding more storage is the knee-jerk reaction. However, this usually creates other problems, and more equipment is needed. Before the additional equipment is added, the parties have to consult and decide on the purchase of equipment, delivery, contracts, and changes in the documentation.

Another example would comply with regulations, where a step is needed to be recorded as part of a transaction. Adding the transaction would require a validation, procedures for data capture, expansion of the database design, and the additional storage, as well as ramifications on other procedures. Before these changes are included in the development, the vendor has to make it clear that there is an additional cost, and that the customer is willing to pay the cost. In both examples, the project might go to a standstill, while the changes are ironed out.

In Agile, personal interactions can help the cause with the developers continuing development, and the documentation or hardware acquisition is set aside as a separate project. The project does not need to suspend while revisions and contracts are worked out. Not everything has to go through contract negotiation. The negotiation process is an almost daily thing and it avoids surprises.

4. It is better to respond to change, than following a strict plan.

A constant in any software development is change. The motivation for the project is a change which requires the new software. Change is a continuous stream of events, and while the software is being designed and bid out, the requirements are already changing. It is not uncommon for the real-world requirements to have changed sufficiently that the final output is already obsolete.

Some would say that in a competitive environment, the act of releasing a software signifies that it is already obsolete. The improved version or competitor software is already in the pipeline, with requirements and features better than the just-released software. In manufacturing, this is a form of planned obsolescence. Products have a lifetime because improvements are already being developed. The more complex a product is, the faster it becomes dated.

Plans are made to ensure that the project is insulated from change. The project was developed at a point in time, and the requirements at the time become features of the software. Unfortunately, even as the software is being developed, the changes in the requirements also need to be implemented. In traditional project management, the change requests would only be entertained after the software has been submitted, or a negotiation ensues which would impact the project costs.

In Agile, these changes are expected. A mechanism is included in the methodology to include the changes. Plans are still included but these are expected to be followed up to a certain point. In Scrum, the detailed plans are for the duration of a sprint. In Kanban, the plans can be changed at any time because it allows the introduction of change at any time, at any point in the process.

Agile Principles Explained

The 12 principles of Agile software development are based on the above core values and expound on the above values. Some are counter-intuitive and would require some explanation. There are others which can only be explained with other principles.

Agile Principles Explained

According to the Agile Manifesto, the 12 principles are:

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

The aim of software development is the delivery of the finished software. Traditional project management dictates that the software is delivered at the end of the development as one complete system. Each of the steps is done sequentially and the development does not move forward until a step has been completed. At each step, the customer has to sign off and approve on the pertinent document. After the design implementation or coding, quality assurance and testing are done according to the approved design documents.

Even a modular approach would still deliver the software in big chunks of working software. After all the modules have been completed, the modules have to go through integration testing. This would require a separate system acceptance for the whole integrated system.

This puts a lot of strain on the developers, the customers, management, and stakeholders. The customer would have nothing until the end of the project.

Agile prescribes continuous submission of smaller chunks of working software. This ensures that the stakeholders see that there is actual work being done. The project is moving as seen by the continuous delivery of the software. This results in less stress and pressure as well as higher customer satisfaction.

2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

Change is a constant. Agile has processes which accept late requirements. Agile presumes that not all requirements are discovered at the beginning of the project. The whole project begins with only a partial list of the final requirements, environment, and other factors. These will be discovered during the development process and incorporated as they are discovered. In this development environment, changes are expected and considered as part of the project.

3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

With change being imminent, there is a race to develop and finish something working before any change or revision arrives. This forces the team to deliver in short bursts or durations. It also implies that the project is being accepted often and continuously. Any change is included as a matter of doing business.

4. Business people and developers must work together daily throughout the project.

In a traditional project management setup, there are two sides to the table. There is the project manager for the developers and their counterpart on the customer side. The developer has regular meetings and status reports to customer project management.

In Agile, the two parties work together with an immediate transfer of information. One of the roles in Agile is that of the product owner. This role is uniquely that of a customer representative. The product owner informs the team of any changes and revisions in the environment, requirements, and other variables, as they occur.

As a part of the project, the product owner is in close contact with the team and is expected to attend the daily stand up meetings.

5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

There are more roles in a structured development effort. There is a clear delineation of responsibilities and accountability. In Agile, there are a limited number of roles. It is expected that these are motivated individuals committed to developing the software in different capacities. The project proponents are given a simple rule: find motivated people, and get out of their way.

6. The most efficient and effective method of conveying information to and within a development team is a face-to-face conversation.

There is still the necessary documentation, however, to better explain the project, the developers meet with the users, and the people who know the system or will be using the system. The developers will take note of the use case, and stories. These are the foundation of their coding work.

7. Working software is the primary measure of progress.

Software engineering has shown that even with the use of higher-level languages and tools, the programmers of today are still as “productive” as the programmers of 50 years ago. They are still at 10 tested lines of code per day. It is hard to measure progress in terms of programmer productivity. Additionally, there is no correlation between effort and productivity.

Ultimately, progress can only be measured from the point of view. Instead of programmer KPI, projects can be measured in terms of tested and done software submitted to the customer.

8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

Programming effort in a project has its flow. Daily flow of work can hit highs and lows. For large projects with long durations, the cycles also take a long time. Sustainability in software development aims to keep the programming effort at a continuous regular clip. In Agile, development is time-boxed in small chunks between 1 to 4 weeks. Due to this, there is a sense of urgency to finish tasks in the given time frame. The developers are not allowed to cram nor to slacken. They are better able to budget their time.

9. Continuous attention to technical excellence and good design enhances agility.

There is an emphasis on quality. This is best shown in Kanban where everyone has the authority to stop the flow for quality reasons. Quality assurance is included in the process and is not a separate step conducted by dedicated QA personnel. QA is a constant concern.

10. Simplicity–the art of maximizing the amount of work not done–is essential.

To meet the requirements of a time-boxed iteration, the development team has to determine which tasks are important and which can be left out. Simplifying the whole process creates a shorter task list which can be delivered within the time allotted. By having a shortlist of activities, there is a greater degree of success in delivering a done product. At the same time, the deliverables are of better quality.

11. The best architectures, requirements, and designs emerge from self-organizing teams.

Team members know their strengths. During the iterations, they also gain knowledge about their capabilities. After a few iterations, they would have a better understanding of the project complexities, and the task difficulty. They are also able to improve on estimation and prioritizing the items on the task list. They are not dependent on a single architect, analyst or project manager for the task assignments and priorities. This results in better delivery times.

12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Reflecting on the missteps is a necessary part of improving the system. It also allows the members time to realize where they failed and how they can overcome these failures. This introspection lets the members take time for learning.

How Agile Works

Project management started as an engineering discipline. It was later on adapted to software development because most projects at the time were engineering in nature. Up to the 1970s, most programmers were engineers or mathematicians. They brought along engineering concepts to programming.

Agile Workflow Explained

The early structured programming and design methodologies borrowed the wholesale from engineering concepts. This was not necessarily a good fit because some of the engineering concepts of tangible objects did not apply to software development. In building a bridge, when the project is getting behind schedule, more men can be brought in to help. A bridge can be made faster, within certain limits, by adding resources. This concept, variously called “Chinese Army” or “Mongolian Horde” theory does not scale well for software development. It has been proven that in software, adding more people to a late project makes it even later.

Agile is a mindset which keeps in mind these pitfalls. It also takes into account learnings and realities about traditional project management. As a mindset, it teaches practitioners a new way of thinking without the baggage of learning waterfall project management concepts.

Agile is people-centered. It relies heavily on face-to-face communication for information passing. It requires team members who are motivated to develop quality software. People are not constrained into traditional roles. There are only three roles: Scrum Master, Product Owner and Team Members. The Scrum Master is also expected to be a team member and has coding tasks. The different Team members also do traditional roles including backend, frontend, project management, documentation and quality assurance.

It focuses on delivering on time, within budget, via continuous submissions of working software. The iterations improve on these submissions until the final product is achieved. This practice keeps the development focused on the primary measure of success: the delivery of working software.

The various software development activities are not considered as discrete and one-off. Instead, the activities are continuous and iterative. Analysis, testing, design, and coding can occur all at the same time. Development is iterative. Every iteration results in working software. Features are added on every product iteration. The product improves and there is transparency allowing the product owners to decide when they can release or start using the product. In the meantime, further, development continues. This means that the software can be used much earlier, and feedback from real-life use can be used to further improve the product.

Planning is not a one-off separate activity. Every iteration involves planning. Part of the planning is in deciding what to include in a particular iteration. These are priority items which are developed for the iteration. Other features may be deferred, or they may be left out in the final product.

Revisions and changes can be incorporated at appropriate times depending on the development team. These changes are expected and there is a mechanism already in place to process and include these changes. The development relies on these changes as they come or is discovered.

For somebody steeped in waterfall project management, the hardest part of Agile to fully understand is that the scope can vary. Agile is time-boxed and strict about the product schedules. It strives to work within the budget by strictly following the time constraint. The team members are intent on the quality of the deliverables. However, due to the way that requirements are discovered, as well as the expected changes which are accepted into the development, the scope will vary.

Ready to increase your work productivity?

#1 rated scrum tool

Try Monday Now Project Management Tool

  • Proj​ects and Tasks Management
  • User Stories & Sprints
  • Users Roles
  • Scrum & Agile Methodology
  • Time Tracking and much more...
Close Menu