Agility: The misconception about being Agile is to follow Extreme Programming practices
Posted by Jai on August 25, 2009
Few days back one of my colleagues asked me the same thing that what exactly being Agile means and how do you measure the Agility of a team or an organization. He is new to the agile and being agile for him is more of following the extreme programming practices. And another question was if the team/organization says that they are agile then how do we measure the agility, how agile they are until and unless we know the practices they are following. In this post we will discuss the similar questions.
The same question has been asked and explained so many times and in so many ways. The first thing I did was to point him and explain the Agile Manifesto. And also tried to explain the principles behind it.
But during most of the discussion he was focusing on that all these principles are fine and are the same for most of the teams/organizations. All team/organization just can say that they are following Agile, on paper, but how do you really figure out that are they really doing it. Then he added that if you are not doing pair-programming or continuous integration, how can you say that you are agile. There I got the idea that what he was confused at.
I supported my points with few arguments like, being agile for the team/organization means you:
- are more client focused, work in collaboration with the client.
- prefer people to people interactions over processes, minimize waste etc.
- regular feedback and continuous working software and open to changes.
- right management support to build self organizing teams, having right people etc.
- follow best practices to attain the agility and continuous improvements.
and many more similar points (idea is not to cover all here :)).
And to add more to this that what the extreme programming practices are. And also about particularly the Scrum practices.
Sometimes it is hard for people to differentiate and digest the differences between the Agile practices and many of the XP practices. They somehow get mislead by the idea that the XP practices etc are part of Agile. And Agile enforces these practices with it.
This misunderstanding lead to the idea that if you are not following one of the XP practice like pair-programming, it means you are not totally Agile. We all know the benefits of pair-programming and many other XP practices but the baseline is that you should not underline the things which may work for one team, may not supposedly work for other team. If one team is following Scrum plus XP fully and is quite successful doesn’t mean that the same things will for other team also. The XP practices like pair-programming, continuous integration etc. help you to achieve the Agility.
People have done a lot of surveys around to measure how agile your team/organization is, covering many of the above points from all the Agile and XP practices. Sometimes it is hard to say what we are measuring and what we are trying to achieve, personally no idea.
And the discussion went on and on but still it was hard for me to convince him to clear out this misconception from his mind. Lets hope over a period of time it gets more clear to him in the form of real Agile experience.
Jai's Weblog - Tech, Security & Fun... 
Kevin E. Schlabach said
I’ve dealt with this myself. I try to explain that the manifesto was the result of many people with different ideas on how to solve the same problem. The manifesto is the solution to the problem strategically. The “denominations” of agile are tactical approaches to solving the problem. Scrum is product and schedule focused, XP is engineering focused. And oh yeah, many of them have converged over the years.
Contrasting XP/Scrum with Kanban, Crystal, Lean, etc also tends to help. When people can see the common outcomes from the different appraoches, it starts defining Agile by the results and not the chosen methods.
Tim Ottinger said
yes, of course. There are those who stop at “Shu” rather than progressing on to “Ha” and “Ri”. If “Shu” were it, then agile could be installed from a CD. Instead we have to deal with agile principles and learning teams and retrospectives. I am a fan of boiling down concepts to very small spaces, but I never pretend that the sketch or the soundbite is all there is to learn.
Jesse Gibbs said
There was a great talk yesterday at Agile 2009 about whether or not Agile should still be called ‘Agile’ at all. One point which kept coming up was the dogmatic approach that a lot of people take to particular methods, whether they are for planning and management (Scrum, Kanban,…) or for day-to-day engineering practice (XP).
To me measuring how agile you are is like measuring how you are. It’s impossible. In the case of Agile, you should adopt any practices that make your team more effective at delivering high-quality software as quickly as possible. If some suggested practices just don’t work for your team (pair programming is one that doesn’t work for everyone), just punt it, keep the rest, and ignore anyone who says you’re not Agile. If your team is continually improving its ability to deliver, then you are clearly doing the right things.
Bronnen Agile at ting said
[…] Practices to deal with assumptions, risks and priorities Agility: The misconception about being Agile is to follow Extreme Programming practices « Jai’s W… Bron http://www.jasperoudenaarden.nl/agile-ux/blog/artikelen/ « Bronnen […]