Tuesday, July 5, 2011

The Agile Manifesto – 10 Years Later

At the 2011 Agile Development Practices West, Martin Fowler reflected on where we are in the agile movement 10 years after the creation of the Agile manifesto. Martin looked at what was going on back in 2000. We were in a world of badly managed software. A group of people felt that to clean up this mess we needed big methodology, planned driven methodology, or an engineering approach to software development with lots of documents and lots of processes (waterfall).

Others had success with a different approach. They believed in rapid iteration, lots of collaboration, and an evolutionary approach to requirements, design, and architecture. They felt that they were not getting heard and were getting trampled by big methodology approach.

This group got together in Snowbird 10 years ago. The idea for the meeting originated a year earlier when the group got together at a workshop at Kent Beck’s home. Kent described XP as a set of practices governed by a set of principles and values. However, there were some that liked the values or principles, but did not like the practices.

This led to the Snowbird meeting where they concentrated on the values and discussed the different approaches like XP, SCRUM and Feature Driven Development. Uncle Bob felt the group needed a manifesto as a statement of what they believed in. In the end, the people that wrote the manifesto were just the people that were free to meet up that week.

Now 10 years later, a lot of the people that where there at the creation feel a sense of unhappiness with Agile and the manifesto.

Martin believes there are 2 main reasons for this.

The 1st is due to the inevitable consequence of success. The idea of Agile spreads out but the true meaning gets diffused. He refers to this as semantic diffusion. Anything that is successful spreads faster than the semantics can follow it. Martin stresses that we have to keep reminding people about the core concepts.

The 2nd reason is that the Agile revolution is still in its infancy. We are in the early days of a very long running change. Martin remembers the OO revolution. It started in the late 60s, it was put together in the 70s, had a good definition of what OO is in the 80s with small talk and took another 20 years or so before OO became main stream in languages like java, C++ and C#. Still today, 40 years on, people think they are doing OO, but they really just have procedures and naked data structures and not true OO.

Martin thinks Agile will take even longer than OO because it affects more people. It’s not just developers, but it is testers, BAs, managers, etc…

Martin then argues that people should still care about agile. He remembers how the manifesto was written.

The group came up with 8 valuable useful good things in software development. The idea was to arrange them in pairs so that one useful thing was more valuable than the other. The guiding light was the drive to the engineering methodologies. Flipping the values around was the value system of the engineering methodologists.

A lot of companies care about processes and tools over individuals because they want to be able to move people around.

The design and documentation is important to them because they believe that once it is produced they can give it to a bunch of developers that can code it up.

You have to have contracts in place and decided. The conversations are based on what is in the contract.

Following a plan was important because the definition of success was based on whether they stuck to the plan.

Martin argues that if you don’t care about Agile then you can be equally happy in a flipped or agile environment. The order within each pair of values does not matter.

Martin wraps up by looking to the future. He sees 2 emerging areas for Agile. The 1st is Agile User interface design where the UI evolves through customer, designer and developer collaboration instead of handing the UI to a team and then asking the developers to code what was designed (even if the developers see much simpler and faster solutions).

Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation (Addison-Wesley Signature Series (Fowler))The second is the concept of continuous delivery and improving the process of how we move code from development to test to production.

This presentation is available on youtube at http://www.youtube.com/watch?v=p5Qj75nJPEs (minute 50)