🍃 Leaf

Agile Software Development

If agile methods have a motto, it is embrace change. If agile methods have a strategic point, it is maneuverability. (Craig Larman, Agile & Iterative Development)

Agile Software Development (or just Agile) is a mindset aimed to quickly deliver value to the customer by responding and adapting to change while keeping focus on the people doing the work and how they work together. It is defined by four core values that rule its twelve principles manifested through practices.

What drew me to Agile in the first place was the high commitment to discipline over ceremony. (Uncle Bob)

These practices are a set of methods and methodologies that address all of the areas of traditional software engineering, making teams think more effectively and work more efficiently, developing evolutionary software solutions through the collaboration between multiple self-organizing and cross-functional teams.

The Agile Manifesto

We are uncovering better ways of developing software by doing it and helping others do it. (The 17 attendees of The Light Weight Process Summit, 2001)

Agile Values

Agile Development … is adaptive rather than predictive … is people-oriented rather than process-oriented. (Martin Fowler)

While there is value in the items on the right, we value items on the left more:

  1. Individuals and interactions over processes and tools.
  2. Working software over comprehensive documentation.
  3. Customer collaboration over contract negotiation.
  4. Responding to change over following a plan.

Not to be confused with the values named by Kent Beck: courage; communication; feedback; and simplicity, later adopted by Extreme Programming, which also included respect. However, those values are still relevant for Agile Software Development.

Individuals and Interactions Over Processes and Tools

Agile works because people makes it work. (The Art of Agile Development)

We can go wrong when we blindly follow a process. A great tool can sometimes help us do the wrong thing faster. The software world is full of great practices: not all of them are appropriate for every project and every situation. However, it’s universally important to understand the people on the team, how they work together, and how each person’s work impacts everyone else.

There are many practices that support this value (or actually, the individuals), like daily standup meetings, retrospectives, and user stories. Practices meant to listen to everyone to see what lessons can be learned. Is not enough to have the “correct” process or “best” practice. That’s why it’s always important to recognize that we’re working with a group of people that have their own motivations, ideas, and preferences.

Working Software Over Comprehensive Documentation

Agile teams show progress with working software, not documents. (The Art of Agile Development)

There is too much that can be documented. Even worse, it’s often difficult to predict what’s going to be useful, and what will gather dust. Because of that, some teams will decide on a comprehensive approach, where every little thing must be documented. On the other hand, we have the working software, the software that adds value to the organization who will use it to work, or sell it to make money.

For a project to add value, it needs to deliver or save more money than it cost, as value usually comes down to money. Documentation is only a means toward that end. It does not mean that we should not document. Good documentation is a positive contribution. In fact, there are practices that produce documentation that’s embedded in the software itself, like test-driven development, in which a test can serve as documentation, because it tells developers what the software is supposed to do.

Customer Collaboration Over Contract Negotiation

Agile says people are the most important factor in software development. (The Art of Agile Development)

Contract negotiation may sound like we are talking about consultants and contractors, but it’s all about teams of programmers, testers, business owners, and managers that work within a single company as if they were working on a contract. They even discuss service-level agreements to reduce any risk of getting in trouble. This is highly counterproductive. Developers will stop trying new ideas, new ways to collaborate and innovate because they are constantly trying to protect themselves.

To prevent the teams from feeling under pressure and consequently trying to delegate responsibilities (losing then the sense of ownership over the software they produce), agile solves this problem by adding to the project a product owner. A product owner is a member of the whole team that attends meetings, contributes ideas, and most importantly, feels ownership for the final product, usually communicating customer needs (as requirements) to the rest of the team with user stories.

Responding to Change Over Following a Plan

Learning and responding to change are at the heart of what Agile is all about. (The Art of Agile Development)

There is an old saying among project managers: plan the work, work the plan. Sadly, if we work the wrong plan, we’ll build the wrong product. That’s why we should constantly look for changes. We often resist the change, change could require redoing a lot of work (like breaking tasks down into smaller ones and making estimations). We always need to respond fast because it will be much harder to make changes later on.

A task board is a planning tool in which user stories are attached to a board and categorized into columns based on their status. Nowadays we can use software tools, but people usually find it more effective to do it physically because standing in front of the board, talking, gesturing, and interacting is a much richer form of communication.

Agile Principles

  1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
  2. Welcome changing requirements, even late in development. Agile processes harness for the customer’s competitive advantage.
  3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter time scale.
  4. Business people and developers must work together daily throughout the project.
  5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
  6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
  7. Working software is the primary measure of progress.
  8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
  9. Continuous attention to technical excellence and good design enhances agility.
  10. Simplicity (the art of maximizing the amount of work not done) is essential.
  11. The best architectures, requirements, and designs emerge from self-organizing teams.
  12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

The Iron Triangle

It is an unassailable trade-off between four constraints, it rules the attributes for any kind of project: Good, Fast, Cheap, and Done, however, only three of them can be chosen. We can’t have them all at the same time. Let us assume that Done is (obviously) always picked, then we need decide which of the attributes left to abandon between Good, Fast, and Cheap.

For example, Done, Good, and Fast, could produce quite expensive software, or Done, Fast, and Cheap, it won’t be a high quality product at all. The Iron Triangle is one of the Agile practices that help developers and managers execute an appropriate approach to their context (or at least to have the commitment to try it).

The reality is that a good decision is made when we understand that these four attributes have coefficients. The only thing we need to do is to drive a project to be Good enough, Fast enough, Cheap enough, and Done as much as necessary.

Understanding the Elephant (and Agile)

The way a team works is far more important than any process. (Don Wells)

There’s a useful metaphor that can help us get a better handle on what it means to have a fractured perspective, and why that leads teams down a less effective path.

It’s the story of the Blind Men and the Elephant:

Six blind men were asked to determine what an elephant looked like by feeling different parts of its body. One by one they described: the leg felt like a pillar; the tail like a rope; the trunk like a tree branch; the ear like a hand fan; the belly like a wall; and the tusk like a solid pipe. Finally they were told: All of you are right. The reason every one of you is telling it differently is because each one of you touched a different part of the elephant. So, actually the elephant has all the features you mentioned.

Adopting agile will not guarantee success for a team that, even before doing it, was already experiencing some problems, not the crisis kind of problem, but the ones that cause friction and discomfort. When developers think about developer stuff, project managers think about project manager stuff, and so on. This is what “fractured perspective” really means. Everyone is really busy thinking about their own work.

This attitude divides the team and kills collaboration. Leading to teams really functioning as individuals working separately toward compatible goals, not as a team. However, teams that get better-than-not-doing-it results from agile are often the same teams who are already able to get software done reasonably well, even before starting with agile, and were hoping that adopting it would lead a good project to be even better.

So while the agile “elephant” is made up of many great practices, it’s much bigger than just those practices, it’s even greater than the sum of the parts. Adopting agile practices individually will definitely improve things because they are really good, but not good enough to be agile on their own. A team that follows agile practices but ignores its principles will always have a fractured perspective. Values and principles emphasize the important interactions and collaboration between individuals, the power of agile.

Reference: