Shane Warden

Originally posted by shantanu puranik:
Is Agile methodology (SCRUM) suitable for development that includes bug fixing/ customer complaints only ?

Hi Shantanu,

What kinds of technical practices do you include with Scrum? Do you have a comprehensive test suite, for example?

Originally posted by Damon Black:
And I've never heard anyone grumble about it once they adopted the habit.

Heh, I can think of one person I've tried to pair with who absolutely *refuses* to use bash or Vim shortcuts or ctags or any of that lovely stuff. At least this person uses screen, but... yeah, it can be painful to pair with someone who always does everything the difficult way.

I agree with Ilja. It's completely okay for your customer to change his or her mind, provided that:

* you maintain a consistent release schedule (Jim and I recommend an iteration length of one week)

* you implement stories in terms of customer priority

To my mind, it sounds like your current difficulty is delivering a new release every iteration. With a week-long iteration and some discipline, you can probably get away by asking your customer to add new feature requests as stories and set the priority of stories for the next iteration.

I realize that a Scrum tends to be a month in length, but I wonder what would happen if you handed your customer a fresh CD every Wednesday morning with the freshest build on it.

Originally posted by R. M. Menon:
Can we eliminate or have a revised version of pair programming when practising XP?

Hi R. M.,

Although I don't recommend it, you can eliminate (or postpone) pair programming while performing the other XP practices. If you do this, you need to find another way to gain the benefits of pair programming. Specifically, you probably need:

* additional and regular code review
* greater discussion of the code and its state to spread knowledge around the team, perhaps in weekly study groups
* more discipline to stay on task while developing
* a greater concern for energized work

I expect that a team performing pair programming will have a smaller defect rate than a team that programs solo, for example, and I expect there to be greater technical debt in the solo team. Nothing else shares knowledge quite as much as promiscuous pairing, in my experience, and it's a bit of a risk to get rid of it.

It's a manageable risk, though, if you know what you're missing.

Originally posted by Eric Hindle:
We are fairly new to Agile and our business users think all their Christmases have come at once.
They can (and do) ask for everything and anything and never seem to be refused however absurd the direction in which they drive the project.
They still want to set infeasibly short, rigid deadlines driven by events outside the business without any regard for the practical demands of development and testing.

How can we best educate the business that giving them almost day to day control over the development goes hand in hand with an acceptance that they pay for it in other ways?

Hi Eric,

Are you using XP's Planning Game or something similar to manage and the amount and priority of work you will do in each iteration?

Originally posted by Vinayagam Kulandaivel:
When there are only very few requirements say 5 to 10 (am not sure about the size or the complexity) means it cant be fit for agile model. Please correct me if i am wrong.

Hi Vinayagam,

Any requirement, no matter how large, gets implemented by writing one line of code at a time. No matter how large, I think there's probably a way to split any requirement larger than an afternoon of work into smaller requirements for planning purposes. At least, I've never seen a requirement where we couldn't do that.

Splitting large requirements into smaller, parallelizable requirements is something of an art, and I can understand a customer's reluctance to do so, but I do believe it's possible.

Originally posted by John Roodt:
I understand the value of creating a rhythm of delivery, but is it OK to allow Iterations/Sprints to finish when they do ... rather than fix the time and date? (But keep the daily pressure on via scrums)
Thanks.

Hi John,

I understand the temptation to do this, but think of getting an iteration estimate wrong as an opportunity to learn something. The amount of work your team can do in any time period is roughly constant, assuming that the number and severity and duration of interruptions is roughly constant. The actual numbers will very somewhat, but over time you'll end up with a really good rule of thumb as to how much work you can actually do in a fixed iteration.

If you wildly overestimate how much work you can do, you have the opportunity to ask why, then learn from that and make better estimates next time. Contrarily, if you wildly underestimate how much work you can do, you can do the same.

I worry that if you let your team have the option of slipping the iteration date by a day or two, you wouldn't take the opportunity to figure out why your estimate didn't match reality. Now it may be nothing in particular to worry about, but it could mean that something's wrong and you need to address it.

Either way, I would hesitate to give up the benefit of the rhythm of a regular iteration-based release cycle, as well as the opportunity to reflect on your status and your technical practices.

Originally posted by Ilja Preuss:
Where does your impression that Agile projects miss a strategic approach come from? That's not at all my experience...

It depends on the skill of the customer at prioritizing tasks. If there's no strategic vision, the effective strategy of the project can change dramatically from iteration to iteration.

We have an entire section devoted to Vision and its importance in projects. Strategic thinking is definitely important, else you may not deliver long-term value to your customer.

Originally posted by Padma Asrani:
My question is if there is any comparative stuides covered in the book? I think it will help us to understand the benefits of Agile Development Process.

My Another question is
Is the agile development process explained in the book is only for Software Development or can it be applied to the development of any thing for example electronic hardwares?

Hi Padma,

We cite a few studies about various software development practices, but to my knowledge there are no particular studies pitting development methods against each other. (I'm not sure how you'd create a double-blind study of that sort anyway; you'd need teams of comparable skill working on the same project in such a way that you could identify and measure any differences.)

The best we can do is explain the experiences we've had and studied and suggest what we've seen work and what we think will work for you if you perform it with discipline and mindfulness and start to adapt it for your own circumstances.

We do spend a fair amount of time comparing agile practices to comparable practices. We recognize that it's not possible to adopt XP completely from the start of every project, and that you may have to adapt what you do to fit your team and organization.

As for applying agile principles to non-software projects, I'm sure a lot of the book applies... but we concentrated solely on software, so you'll have to do more work to fit the process to a new domain.

Originally posted by Hariharasudhan Selvaraj:
In pair programming, is it really required that the two developers have to be in same physical location? or is it ok if they are in differnt place and communicate often through mail, chat and telephone?

Hi Hariharasudhan,

I know one team that pairs successfully by using Skype and GNU screen, but it's my experience that there's no substitute for sitting side by side and working on the same code on the same machine together. My preference is for the whole team to sit together, and I recommend that if at all possible. The more distance between people, the more barriers there are to communication, and agile development attempts to make communicating so cheap and easy that it's the first thing you do, not the last.

Anything that puts up a barrier to communication introduces a risk. Now you may be able to work around that risk with other practices, but I still recommend sitting together whenever possible. (A very experienced team will probably be able to make remote pairing workable, but it won't be as effective as physical pairing.)

Hm, good questions. When you say your developers are "less experienced", do you mean they're all relative programming novices, or relative novices to XP or agile development?

Originally posted by Jayesh Shere:
My question pertaining to usage of Agile technologies with teams of relatively less experienced developers.
Do you think pairing can work effectively when there is a gap in the skill levels of the various developers in a team?
Does the reduction in the amount of documentation hamper the learning (or handover) of new team members?
I'll be thankful if you could share your thoughts on these questions.

Hi Jayesh,

Pairing is the most effective way I know to transfer knowledge, both of the system under development and in software development in general. For the junior developer, it's a chance to work with a mentor. For the experienced developer, it's a chance to explain the system by walking through it, which often provides the opportunity to check some assumptions by having to explain things.

I can't tell how how many problems I've seen solved just by talking through them with other people, let alone reviewing code together. Pair debugging is highly effective; pair programming more so.

Your point about reduced documentation and handoff is a good one. For that reason, we recommend a rolling handoff, where you bring the new maintainers into the team gradually and let them pair with the existing maintainers. As well, we suggest a specific practice of documentation for the sake of handoff and ongoing maintenance.

Originally posted by Chai Chamsai:
what're advantage and disadvantage if i only use XP or xp+other?

Hi Chai,

We chose XP for two reasons. First, we have the most experience with it of all of the available agile practices. Jim and I have practiced it on multiple projects with a variety of teams in several very different circumstances. It's much more effective to draw from personal experience when evaluating an entire field of practices than to do it without.

Second, and most importantly, we both believe that XP is the most complete of all of the agile practices, which is important from a didactic sense. Scrum has a lot of good practices, for example, but it expects that you already have solid development practices in place that support short iterations without getting you into technical debt.

We didn't want to assume that everyone who read the book had those practices in place yet, so we chose XP as the most effective place to start. If you're already using Scrum or another agile process, that's fine too. We just wanted to give everyone the best possible opportunity to evaluate agile development as a whole without accidentally overlooking anything important.

Originally posted by Sushma Sharma:
I want to learn and understand Agile. I don't have any experience with it. I have been working in j2ee for last 6 years. How would your book help people like me?

Hi Sushma,

Congratulations, you're our target audience! We had in mind programmers with an interest in agile development but not necessarily any practical experience practicing it.

We assume that you understand the basics of professional software development in a modern language (J2EE certainly qualifies) and don't explain IDEs or object oriented programming, but we cover the agile practices in detail, assuming only that our readers have an interest in them.

I can see three benefits for you:

* Improve your understanding of the agile practices through studying and practicing them with your work

* Learn strategies for adopting them with your team

* Reflect on what works best for you and your team and refine your process to improve how you deliver high-quality software

Originally posted by Rohan Dhruva:
I read the amazon overview of the book. However I have one question - does the book cover any programming language / project as a practical example ? Is the book more of a reference theory oriented book, or teaches you how to actually implement AP/XP by giving examples ?

Hi Rohan,

We deliberately tried to avoid tying the book to any specific programming language or technology. With that said, we did use Java in a few places to illustrate Spike Solutions, TDD, and Refactoring, but the goal of the examples was to illustrate the theory, not to explain how to perform any of those practices with any specific language or tool.

It's a theory book, but we try to give practical application of those theory, and we drew from a lot of practical experiences with real projects we've worked on (or have discussed with people who were there) to explain some of the choices we made and give examples of successes and failures. We do expect our readers to know how to program, or manage, or be a customer already, as there are plenty of other resources dedicated to teaching those.