6 Reasons Agile Value is Different?

A few weeks/months ago there were some posts related to the importance of value in the Agile world and also some discussions of whether it should be mentioned in the Agile Manifesto. So the question that I had at this moment is how is agile value different from the value delivered by other approaches. These are the 6 reason I can think of to justify Agile value is different:

1. There is a focus on delivering what the customer needs

Waterfall relies on the customer specifying exactly what they want at the beginning of the project. Dealing with changes later is very expensive because the cost of change is high in a waterfall approach (based on Barry Boehm's famous Cost of Change of curve). Agile, on the other side, acknowledges that what the customer is expecting is difficult to express in words/models and can probably change during the duration of a project. Therefore, Agile welcomes change, even late in the development process and adapts to fulfill the customers expectations.

How is this achieved? With communication, collaboration and a lot of feedback. There is a lot of communication and collaboration during the whole duration of the project. The customer actively builds value with the development team. And the development team builds what the customer wants. Conversations don't stop with producing a requirements document or the best model. Conversations continue permanently because conversation adds context to the information. Grasping the business knowledge needed to deliver a product that provides value is really difficult and relying solely on written words is really risky. To allow for more and better feedback, software is delivered in increments, where each increment finishes with running tested features that the user can experiment with. This allows the user to really understand how the product is going to be useful and make decisions based on a working product.

This focus on the customer needs wants to be pushed even further. I read a couple of tweets a few ago where Cockburn was presenting some possibilities for the creation of a User Manifesto (http://alistair.cockburn.us/User+Manifesto). I understand this manifesto as the need to further think on the needs of our customer, on trying to solve their problems better, on fulfilling their expectations with a great piece of software.

2. Creativity and innovation is increased

The interaction among all members of the team (product side and development) added to the freedom people have in self-organized teams boosts creativity and innovation in ways that would be impossible to other approaches. Highsmith states that "one of the tenets of adaptive organization is that innovation emerges from the interaction of diverse individuals, each with it own ideas, who bring information and insight to the development process". Cockburn calls software development "a game of invention and collaboration". The interaction between produt experts and technology experts is what produces this synergy. Business experts provide the input necessary to build a product that adds value and technology experts fix the boundaries of what's possible and suggests other paths that would help create the same value.

It is important to note the difference between a waterfall approach and an agile approach in this regard. While in waterfall, all the innovation happens at the beginning, when the system is being architected and designed, in Agile there is a big leeway to innovate and create during the development process. Added to this, the change from a command and control structure to a self-organized team structure unleashes the creativity of all members (I still remember having heard at University that developers don't have to "think" much. They received the designs and just have to translate those designs into code.. Sounds easy, doesn't it?)

3. Processes are focused on delivering value

Mary and Tom Poppendieck talk about the importance of decreasing the time it takes from the moment where someone has an idea until that idea is converted to a product, something that adds value. From concept to cash.. what's in between? The Agile world has been greatly influenced by these ideas.

The ideas the Poppendiecks brought to the Agile world come from the Lean concepts that Toyota uses in their Toyota Production System (not a good moment to say so?). Lean has 7 principles, of which the first one is "Eliminate Waste". Waste is everything that doesn't add value to the final product. Eliminating waste leaves us with the useful things: the things that add value to the product. To be able to identify waste and improve the lead time, Mary suggested using a tool that is already been used in manufacturating called "Value Stream Mapping". This tool allows to visualize all the flow since a requirement is borned until it is completed, identifying the steps that add value and the ones that merely act as links. Visualizing this flow allows to think about optimizations.

These ideas are very compatible with Agile, that states that working software should go over comprehensive documentation. Working software is what produces value, is the essence. Processes and coordination mechanisms are reduced to the minimum possible to be able to produce this value. The more complex the problem, the more coordination mechanisms, formality and ceremony will be needed but under the Agile principles, it should be kept to the minimum necessary.

4. Value is delivered early

Agile delivers software incrementally. This allows to plan for intermediate releases if the project is big. If you add to this that the most valuables features are produced first, the result is an early delivery of the most important value. 

Comparing to waterfall, where all the value is delivered in the end the advantages are enormous:

- The most important problems are solved first.

- There's the possibility of putting a product in the market faster.

- Progress is measured in terms of value (i.e. in terms of a working product).
- Management can make decisions based on real progress. Their visibility is improved and the information they have to make these decisions is better.
- Partial releases means creating influx, which increases the Return on Investment.

To add to this, there are studies that show that for some systems 80% of the users use 20% percent of the functionality. Being able to delivering this 20% of the functionality provides (as you can imagine) great value.

I am deliberately leaving risk out of this point. Risk is the other factor that should be taken into account when prioritizing features. Risky features have high priority and should be attached early. It could be said that if business or technological risks cannot be overcome, the project won't be able to deliver any value (so it can be seen from the value perspective as well)

5. Value is delivered sustainably

Yeah, it is not only early delivery of value. Agile is also about being able to continue adding value to an existing product in a costly manner. The Declaration of Interdepence states that the objective is a continuous flow of value. 

Being able to deliver value for a long period of time (that's what sustainable means) requires many things in the human area, the process area and the technical area: 

On the human side, it requires a jelled team that pushes always in the same direction (even if the direction changes). It requires understanding and collaboration among members, especially between the product members and the development members. The development team needs to understands the product team decisions and the product team needs to listen to the development team. This could be particularly challenging when the direction changes too often and there is the need to do development rework because the development team could feel that the product team doesn't have a vision/objective. This is why it is very important that all members of the team at least participate in the decisions. Participatory decision making is vital to sustainability and it's vital to keep all team members committed to success. 

On the process side, it requires a light process that allows changes to be accommodated. In other words, a process that allows the team to adapt. A heavy process with a lot of formality and ceremony makes adapting difficult. Agile processes on the other side are designed to react.

On the technical side, it requires simple design, clean code and ruthless automation testing. 

    - Clean code: Design evolves, a lot of changes on the code are made continually and if the existing code is not refactored continually to accomodate all changes, it could become a mess very soon. 

    - Simple design: One of the Agile principles says "Simplicity - the art of maximizing the amount of work not done - is essential.". Ron Jeffries says "Always implement things when you actually need them, never when you just foresee that you need them." (YAGNI principle). Simple design means the team only develops code that servers a purpose. They don't try to foresee and implement features that will be needed in the future. This point could be contentious as well because a lot of people will say that to make a good OO design, we need to see the whole picture. Agile relies on evolutionary design. That is, when a new feature needs to be implemented that forces to change the design of existing ones, this should be done. Abstractions should be created at this moment and the code should be refactored. This can be done because there should be a good suite of automated tests to harness all these changes. The code needs to be clean (at the previous point said) at all times.

    - Ruthless Automated Testing: The main reason of the importance of automated tests is being able to regress the existing functionality almost continually. Automated tests provide the harness to evolve the design and to refactor the existing code without fear.   

All of these requirements aim at maintaining the cost of change low. If the cost of changing gets higher, changing is more difficult (e.g. If the code is not maintained clean or automated tests are postponed, technical debts accumulate and very rapidly delivering value becomes more difficult) and keep adding value gets difficult. In highly exploratory projects or projects with high uncertainty, this becomes specially important. In these environments, Agile methodologies are perhaps the only ones capable of delivering value.  

6. Value is the objective

As it can be seen, there is strong focus in Agile on providing value, on giving the customer what the customer needs. In fact, value is so important that Jim Highsmith suggests replacing the traditional iron triangle for one that includes value.

This is his proposition:

In the old triangle, if "scope" grows either the project will take longer (time is modified) or the cost will be higher (cost is modified). This triangle was used to take management decisions,  and to measure the success of the project. Using this triangle, a project is successful if it delivers the scope, on time and within the required budget. The new triangle has value, quality and constraints in its vertices. A successful project in the new triangle is one that delivers value with the expected quality and conforming to the constraints.

Performance measurements, processes and activities are designed to optimize value. Under Agile, a project that sticks to an outdated plan that doesn't provide any value won't be successful, even if it finishes on time and with the required cost. Processes should support the delivery of value in a sustainable way, even in changing conditions. 

Conclusion

- It is better value because the customer participates in the creation of this value. The customer has responsibility in shaping the product to fit their needs. The product is the result of the collaboration between people that know the business better and people that know how to implement the ideas. There is also more people contributing to creating the product. A group that self organizes and has freedom allows to get the value from all its members.

- Value is delivered earlier because processes and people are focused on delivering value. The most important value is delivered earlier, allowing to maximize the ROI and solve the customers problems faster. Keep adding value is possible at a reasonable cost because the cost of change is kept low.

- Finally, value is the objective. Processes exist to support the creation of value and are trimmed to the minimum necessary.