Venkat has trained and mentored more than 3000 software developers in the U.S., Canada and Europe in the practices of Agile development. Venkat, who frequently speaks at conferences, is also an adjunct professor for the practice of Computer Science at the University of Houston and teaches at Rice University School for Continuing Studies. He is the author of
.NET Gotchas
and co-author of
Practices of an Agile Developer: Working in the Real World (Pragmatic Programmers)
.
Here, at the Grails eXchange, Venkat, inspiring despite his jetlag, spends some time with Javalobby, chatting about Agile development.
Venkat, what exactly is Agile development?
Agile development is figuring out ways of developing relevant working software. We don't have all the answers, though!
"Quick and customer driven," isn't that the core of it?
Yes, but the question is always: "Why?" Don't focus on what ("customer-driven") and how ("quick"). Focus on "why", when working with Agile development, because cycles may vary and the interaction with the customer may vary. Frequent customer participation and rapid cycles can help to achieve success. But, developing relevant working software is the goal.
The word "agile", where does it come from, in this context?
From the ability to adapt, but the word "ability" is wrong, actually. It is, in fact, closer to the words "willingness" and "commitment".
So the perception that Agile is "lightweight", in the sense of course-grained and draft-like, is a misconception. How did that misconception come about, do you think?
I think sometimes people read things and misunderstand them or have a certain incomplete notion of an approach. They see Agility as an escape route. But, on the other hand, if they adopt Agility and they're not succeeding, then it important for them to figure out why. May be their notion of agility is not right. Or maybe the set of practices they follow is not right for them.
You have developed some experience in this area. What would you say it consists of?
It's actually simple. I went back to my developer role and tried to understand where I succeeded (projects) and where I failed. And why? The emphasis on agility might be new, but we have tried it over many years. No methodology that is dogmatic will succeed, it is about figuring out and adapting, depending on the project. It is not about following a set practice.
Can you clarify how Agile development distinguishes itself?
There's a greater emphasis on checking with customers, on finding out from them what is relevant, and doing so quickly. It is about being adaptive, but not
necessarily
quickly. We want to know sooner rather than later that we need to adapt. In other approaches, we might be too late. Other approaches don't give a time to turn around and fix problems. Smaller, frequent cycles, through feedback, to attain and realize customer needs, helps a great deal in how we approach it.
So, concretely, what would an organization need to do to adopt this approach?
Be careful with the word "concrete"! It may, after all, mean a variety of things. It may mean adopting a certain set of tools or a set of technologies or techniques. But Agility is broader than that. The first requirement is that the organization should understand what it
means
to be agile. They
must
be adaptive.
It starts in people's willingness to understand and change how they do things. They must commit time and resources to get the results that they're after. I have come across organizations that say "Let's not write tests because it takes too much time, we want to be agile", instead of asking
why
is it too much time or even if that time taken is an investment that pays back? Sometimes people want quick solutions or quick fixes, which agility doesn't provide. Be ready to put in the effort and hard work.
You give trainings in Agile development, how have the responses been?
I train and I work closely with teams participating in Agile practices. I have found a mixture of responses from the community. I have found some willing to commit the time and effort. They realize they need to work harder. Others don't have the really necessary commitment, and so they struggle. They're doing it for marketing reasons or otherwise, and fail even when they claim to be agile.
Where organizations have succeeded, what have been the most noticeable gains?
Project completion fairly on time, within budget. Project satisfaction was higher than in other cases. I don't want to paint a picture where everything is green. But the rate of success was certainly higher than before. Plus, they've learned enough from their experiences to apply to their future projects.
Since we're at the Grails conference, can you say something about where Grails fits in here?
A number of technologies help us a great deal to be agile. They do so because they help us get the work done by automating things that we don't need to do ourselves. We can focus on the domain instead of the infrastructure. Rails, Grails, and so on, all of those can fit in fairly well in that area, depending on the type of application we're developing. But agility is broader than any specific tool or technology.
Is there a specific message that you're bringing to the Grails conference?
With respect to Grails, the message I would bring is: "When you use these tools and frameworks, take small steps!" Develop code and quickly get feedback but make the change affordable as well. One way to do that is not just to
use
Grails, but to do so in the
right
way. Take the time to write enough tests. You can code much faster with Grails, but you want to make sure that your changes are not breaking parts of the system. Remember to not only run fast but also in the right direction! Don't be infatuated with the speed, but take the time to get the right benefits.
There's a lot of buzz around Grails at the moment. Do you have any comments on that?
The way that I look at Grails is that it helps us leverage the strengths of the Java platform. A lot of the things that Grails is bringing forward is an opportunity for programmers invested in the Java platform to take advantage of Rails-like features and productivity and at the same time benefit from the strengths and capabilities that they have come to depend on over the years on the Java platform.
Can you name some tools you've found useful in web development?
Re: "What is Agile Development?": An Interview with Venkat Subram
Cool...nice points from Venkat.
I have also been quite familiar with the Agile methodologies like XP and Scrum. As Venkat mentioned, these terms in the Agile Methodologies means different things to different people.
When i was working with one the Fortune 500 Automobile company, i had to implement the Agile processes over the existing CMM level. Its was quite challenging to convince the management and team members. This is where Venkat is expert in.
Anyway you can see my comparison of
CMM and Agile
.
Hope this helps for many who wants (has) to migrate.
Re: "What is Agile Development?": An Interview with Venkat Subramaniam
I pray for the day when we have exposes on JavaLobby about how to do
Sloppy Development
and that is a genuine buzzword...
I work for a big company. There is certainly room for more responsiveness. But maybe the question is how did any of us get
non-agile
in the first place, and what is the fix for that...
Tim Boudreau NetBeans.org
Evangelist/Senior Staff Engineer, Sun Microsystems
Re: "What is Agile Development?": An Interview with Venkat Subram
> But maybe the question is
> how did any of us get
non-agile
in the first
> place, and what is the fix for that...
I think the most important reason for getting non-agile is fear. If you can hide behind a complex process a problem is never your fault. If the software is missing a critical feature it is not because you did not talk to the customer, but because "it was not specified".
There are loads of meetings in a non-agile approach to spread responsibility. The wording will always be "it has been agreed that ....". So nobody can be blamed afterwards.
But what if you have two children and a good paying job, but you are not really competent enough to fill this position?
You cannot leave the job because you need the money and you cannot admit that you need help, because this would show you are in the wrong job.
Almost half of the people working in a company have a sub-average qualification but still want to be successfull and get recognition.
In an agile environment the qualifications of people will show much more clearly. Not everybody is interested in fast feeback about project success.
I think the only way to try and improve this is to stop people from beeing afraid. A start is to not blame people for failures but always ask "what can we do the next time to prevent this from happening again". Do not fire people for making mistakes but try to help them improve their abilities.
But fixing this completely is imho impossible. Sometimes you have to replace an incompetent person, so there will always be persons who have a reason to be afraid and a reason to prevent transparency/agility from happening.
A company is a "cooperative game" and not everybodies primary interest is project success. Try to make the best of it.
Re: "What is Agile Development?": An Interview with Venkat Subram
I find this discussion interesting because I also wondered about how this approach is different, since customer-driven development is surely the way all development should happen? But, I guess, very long development cycles, for example, which is typical in software environments, results in finding out too late where the problems are, because the customer's involvement comes in far too late. Also, the point above, from Niklas, about fear and hiding one's lack of skills is relevant too, since people with this attitude are unlikely to support an agile process. The more opaque the process, the more one can hide within it. The shorter the cycle, the more individual contributions are exposed.
Re: "What is Agile Development?": An Interview with Venkat Subram
I think your response is really about engineering culture...
But what if you have two children and a good paying job, but you are not really competent enough to fill this position?
This is probably not entirely fair - I have seen organizations full of competent people fail. Development process has a lot to do with it - and more importantly, communication process. An organization with highly competent people can still fail if the incentives are set up wrong, or if there is a penalty associated with effective communication. Competence definitely comes into play, but competence can most of the time be overcome with education and a culture that emphasizes quality, testing, etc. So I think blaming incompetence may be a short-cut to a conclusion that misses a bunch of stuff.
IMO, the key problem is, very simply,
information loss
. Businesses sometimes organize themselves in ways that encourage information loss. Think of outsourcing - if you contract a company to do something, they will stick to the letter of that contract (if they want to minimize work and maximize profit); the work can be done less well, because any information not specified in the contract is going to be lost. So the actual value of outsourcing can be reduced apparent costs, where the real savings is that information from the customer is never reaching the vendor - but it will be several product releases before the vendor realizes they have committed hari-kari and they really have no idea even what are all of the problems that are suddenly rearing their heads.
That's not saying I'm against outsourcing - not at all - but that information loss can create a mirage of cost savings, by inserting a multi-year delay before the true costs are realized. Communicating is expensive - that's one very good reason to modularize software and keep development teams small. Doing anything
agile
is much harder across organizational boundaries.
In other words, you can have extremely competent people working in an environment that either limits or outright prohibits agility. Which is an oft-repeated tragedy. The good thing is that there are people advocating agile development practices and there is hope that some of those practises can be transmitted to the business world at large. But it is a hard problem.
-Tim
Tim Boudreau NetBeans.org
Evangelist/Senior Staff Engineer, Sun Microsystems
Re: "What is Agile Development?": An Interview with Venkat Subram
[....]
> So I think blaming incompetence may be a short-cut to a
> conclusion that misses a bunch of stuff.
I agree with what you said and I did not want to blame incompetence for all project failures. There is a lot more that can go wrong.
But communication is a problem agile approaches try to solve/improve. So why doesn't everybody agree to do everything in an agile way from now on?
The point I was trying to make is that many people will oppose a more agile approach (even if they know it is better), because they are afraid they might loose something (Job, title, ... whatever).
So if you try to change an organisation you have to take this into account. You can tell these people that an agile approach is great, more productive and more fun. But still you won't succeed because you are not addressing the real issue these people have.
If you believe in the abilities of these people and their fears are just based on a lack of self-confidence/experience the answer is easy: Help them, give them positive feedback and tell them that they will manage.
But where I see a problem is people, of whom you know will most probably loose. I wouldn't want to lie to them and tell them that everything is going to be alright. But if you just ignore their fears, they will affect others with their fear. So what do you do? I have not found a solution for this (which is probably why I focused a bit too much on this group of people in my last posting).
> Doing anything
agile
is much harder across
> organizational boundaries.
Imho this is also based on fear. You trust your co-workers much more, than an outsourced/consulting company whose sole purpose is to make you dispensable. Why should you trust them? This is a real fear and perhaps you are better off if you don't talk to them and the project fails. I think this is a point of view that we (=people doing project work) tend to ignore, because we are never planning to stay in a company "forever", but will move on anyway.
"What is Agile Development?": An Interview with Venkat Subramaniam
URL: Agile Developer, Inc
At 3:04 AM on Oct 18, 2007, Geertjan wrote:
Fresh Jobs for Developers Post a job opportunity
Venkat has trained and mentored more than 3000 software developers in the U.S., Canada and Europe in the practices of Agile development. Venkat, who frequently speaks at conferences, is also an adjunct professor for the practice of Computer Science at the University of Houston and teaches at Rice University School for Continuing Studies. He is the author of .NET Gotchas and co-author of Practices of an Agile Developer: Working in the Real World (Pragmatic Programmers) .
Here, at the Grails eXchange, Venkat, inspiring despite his jetlag, spends some time with Javalobby, chatting about Agile development.
Venkat, what exactly is Agile development?
Agile development is figuring out ways of developing relevant working software. We don't have all the answers, though!
"Quick and customer driven," isn't that the core of it?
Yes, but the question is always: "Why?" Don't focus on what ("customer-driven") and how ("quick"). Focus on "why", when working with Agile development, because cycles may vary and the interaction with the customer may vary. Frequent customer participation and rapid cycles can help to achieve success. But, developing relevant working software is the goal.
The word "agile", where does it come from, in this context?
From the ability to adapt, but the word "ability" is wrong, actually. It is, in fact, closer to the words "willingness" and "commitment".
So the perception that Agile is "lightweight", in the sense of course-grained and draft-like, is a misconception. How did that misconception come about, do you think?
I think sometimes people read things and misunderstand them or have a certain incomplete notion of an approach. They see Agility as an escape route. But, on the other hand, if they adopt Agility and they're not succeeding, then it important for them to figure out why. May be their notion of agility is not right. Or maybe the set of practices they follow is not right for them.
You have developed some experience in this area. What would you say it consists of?
It's actually simple. I went back to my developer role and tried to understand where I succeeded (projects) and where I failed. And why? The emphasis on agility might be new, but we have tried it over many years. No methodology that is dogmatic will succeed, it is about figuring out and adapting, depending on the project. It is not about following a set practice.
So, who coined the term?
It emerged in 2001, a few who wanted to explore lightweight software processes coined it. And the Manifesto for Agile Software Development comes from there too.
Can you clarify how Agile development distinguishes itself?
There's a greater emphasis on checking with customers, on finding out from them what is relevant, and doing so quickly. It is about being adaptive, but not necessarily quickly. We want to know sooner rather than later that we need to adapt. In other approaches, we might be too late. Other approaches don't give a time to turn around and fix problems. Smaller, frequent cycles, through feedback, to attain and realize customer needs, helps a great deal in how we approach it.
So, concretely, what would an organization need to do to adopt this approach?
Be careful with the word "concrete"! It may, after all, mean a variety of things. It may mean adopting a certain set of tools or a set of technologies or techniques. But Agility is broader than that. The first requirement is that the organization should understand what it means to be agile. They must be adaptive.
It starts in people's willingness to understand and change how they do things. They must commit time and resources to get the results that they're after. I have come across organizations that say "Let's not write tests because it takes too much time, we want to be agile", instead of asking why is it too much time or even if that time taken is an investment that pays back? Sometimes people want quick solutions or quick fixes, which agility doesn't provide. Be ready to put in the effort and hard work.
You give trainings in Agile development, how have the responses been?
I train and I work closely with teams participating in Agile practices. I have found a mixture of responses from the community. I have found some willing to commit the time and effort. They realize they need to work harder. Others don't have the really necessary commitment, and so they struggle. They're doing it for marketing reasons or otherwise, and fail even when they claim to be agile.
Where organizations have succeeded, what have been the most noticeable gains?
Project completion fairly on time, within budget. Project satisfaction was higher than in other cases. I don't want to paint a picture where everything is green. But the rate of success was certainly higher than before. Plus, they've learned enough from their experiences to apply to their future projects.
Since we're at the Grails conference, can you say something about where Grails fits in here?
A number of technologies help us a great deal to be agile. They do so because they help us get the work done by automating things that we don't need to do ourselves. We can focus on the domain instead of the infrastructure. Rails, Grails, and so on, all of those can fit in fairly well in that area, depending on the type of application we're developing. But agility is broader than any specific tool or technology.
Is there a specific message that you're bringing to the Grails conference?
With respect to Grails, the message I would bring is: "When you use these tools and frameworks, take small steps!" Develop code and quickly get feedback but make the change affordable as well. One way to do that is not just to use Grails, but to do so in the right way. Take the time to write enough tests. You can code much faster with Grails, but you want to make sure that your changes are not breaking parts of the system. Remember to not only run fast but also in the right direction! Don't be infatuated with the speed, but take the time to get the right benefits.
There's a lot of buzz around Grails at the moment. Do you have any comments on that?
The way that I look at Grails is that it helps us leverage the strengths of the Java platform. A lot of the things that Grails is bringing forward is an opportunity for programmers invested in the Java platform to take advantage of Rails-like features and productivity and at the same time benefit from the strengths and capabilities that they have come to depend on over the years on the Java platform.
Can you name some tools you've found useful in web development?
FireBug , JavaScript Shell , Greasemonkey , Selenium , Crosscheck , JSLint , JsUnit , and YSlow .
Finally, any thoughts you'd like to leave readers of this interview with?
Be open, take time to learn and apply, and find ways to improve!
6 replies so far (
Post your own)
Re: "What is Agile Development?": An Interview with Venkat Subram
Cool...nice points from Venkat.I have also been quite familiar with the Agile methodologies like XP and Scrum. As Venkat mentioned, these terms in the Agile Methodologies means different things to different people.
When i was working with one the Fortune 500 Automobile company, i had to implement the Agile processes over the existing CMM level. Its was quite challenging to convince the management and team members. This is where Venkat is expert in.
Anyway you can see my comparison of CMM and Agile .
Hope this helps for many who wants (has) to migrate.
Re: "What is Agile Development?": An Interview with Venkat Subramaniam
I pray for the day when we have exposes on JavaLobby about how to do Sloppy Development and that is a genuine buzzword...I work for a big company. There is certainly room for more responsiveness. But maybe the question is how did any of us get non-agile in the first place, and what is the fix for that...
NetBeans.org
Evangelist/Senior Staff Engineer, Sun Microsystems
Re: "What is Agile Development?": An Interview with Venkat Subram
> But maybe the question is> how did any of us get non-agile in the first
> place, and what is the fix for that...
I think the most important reason for getting non-agile is fear. If you can hide behind a complex process a problem is never your fault. If the software is missing a critical feature it is not because you did not talk to the customer, but because "it was not specified".
There are loads of meetings in a non-agile approach to spread responsibility. The wording will always be "it has been agreed that ....". So nobody can be blamed afterwards.
But what if you have two children and a good paying job, but you are not really competent enough to fill this position?
You cannot leave the job because you need the money and you cannot admit that you need help, because this would show you are in the wrong job.
Almost half of the people working in a company have a sub-average qualification but still want to be successfull and get recognition.
In an agile environment the qualifications of people will show much more clearly. Not everybody is interested in fast feeback about project success.
I think the only way to try and improve this is to stop people from beeing afraid. A start is to not blame people for failures but always ask "what can we do the next time to prevent this from happening again". Do not fire people for making mistakes but try to help them improve their abilities.
But fixing this completely is imho impossible. Sometimes you have to replace an incompetent person, so there will always be persons who have a reason to be afraid and a reason to prevent transparency/agility from happening.
A company is a "cooperative game" and not everybodies primary interest is project success. Try to make the best of it.
Re: "What is Agile Development?": An Interview with Venkat Subram
I find this discussion interesting because I also wondered about how this approach is different, since customer-driven development is surely the way all development should happen? But, I guess, very long development cycles, for example, which is typical in software environments, results in finding out too late where the problems are, because the customer's involvement comes in far too late. Also, the point above, from Niklas, about fear and hiding one's lack of skills is relevant too, since people with this attitude are unlikely to support an agile process. The more opaque the process, the more one can hide within it. The shorter the cycle, the more individual contributions are exposed.Re: "What is Agile Development?": An Interview with Venkat Subram
I think your response is really about engineering culture...But what if you have two children and a good paying job, but you are not really competent enough to fill this position?
This is probably not entirely fair - I have seen organizations full of competent people fail. Development process has a lot to do with it - and more importantly, communication process. An organization with highly competent people can still fail if the incentives are set up wrong, or if there is a penalty associated with effective communication. Competence definitely comes into play, but competence can most of the time be overcome with education and a culture that emphasizes quality, testing, etc. So I think blaming incompetence may be a short-cut to a conclusion that misses a bunch of stuff.
IMO, the key problem is, very simply, information loss . Businesses sometimes organize themselves in ways that encourage information loss. Think of outsourcing - if you contract a company to do something, they will stick to the letter of that contract (if they want to minimize work and maximize profit); the work can be done less well, because any information not specified in the contract is going to be lost. So the actual value of outsourcing can be reduced apparent costs, where the real savings is that information from the customer is never reaching the vendor - but it will be several product releases before the vendor realizes they have committed hari-kari and they really have no idea even what are all of the problems that are suddenly rearing their heads.
That's not saying I'm against outsourcing - not at all - but that information loss can create a mirage of cost savings, by inserting a multi-year delay before the true costs are realized. Communicating is expensive - that's one very good reason to modularize software and keep development teams small. Doing anything agile is much harder across organizational boundaries.
In other words, you can have extremely competent people working in an environment that either limits or outright prohibits agility. Which is an oft-repeated tragedy. The good thing is that there are people advocating agile development practices and there is hope that some of those practises can be transmitted to the business world at large. But it is a hard problem.
-Tim
NetBeans.org
Evangelist/Senior Staff Engineer, Sun Microsystems
Re: "What is Agile Development?": An Interview with Venkat Subram
[....]> So I think blaming incompetence may be a short-cut to a
> conclusion that misses a bunch of stuff.
I agree with what you said and I did not want to blame incompetence for all project failures. There is a lot more that can go wrong.
But communication is a problem agile approaches try to solve/improve. So why doesn't everybody agree to do everything in an agile way from now on?
The point I was trying to make is that many people will oppose a more agile approach (even if they know it is better), because they are afraid they might loose something (Job, title, ... whatever). So if you try to change an organisation you have to take this into account. You can tell these people that an agile approach is great, more productive and more fun. But still you won't succeed because you are not addressing the real issue these people have.
If you believe in the abilities of these people and their fears are just based on a lack of self-confidence/experience the answer is easy: Help them, give them positive feedback and tell them that they will manage.
But where I see a problem is people, of whom you know will most probably loose. I wouldn't want to lie to them and tell them that everything is going to be alright. But if you just ignore their fears, they will affect others with their fear. So what do you do? I have not found a solution for this (which is probably why I focused a bit too much on this group of people in my last posting).
> Doing anything agile is much harder across
> organizational boundaries.
Imho this is also based on fear. You trust your co-workers much more, than an outsourced/consulting company whose sole purpose is to make you dispensable. Why should you trust them? This is a real fear and perhaps you are better off if you don't talk to them and the project fails. I think this is a point of view that we (=people doing project work) tend to ignore, because we are never planning to stay in a company "forever", but will move on anyway.