A snip of the intro to my talk to the Indiana QA Conference on "Magic Pixie Dust: Improving the pace of software delivery through People" is below. I really like the methodology stuff, but it doesn't fit - I may cut everything after "share a few with you." Mostly I wrote it up here to tie it back in with the potholes analogy.
Have you ever been faced with an impossible deadline, where senior management tells you that adding staff, moving the date, decreasing quality, or removing features was "simply unacceptable?" After all, your job is to solve problems, not to whine.
Itââ¬â¢s seems as if Senior Management wants you to spread some magic pixie dust and make everything better.
Well, yes, and to some extent, I believe thatââ¬â¢s possible. Or, that is to say, there are tradeoffs you can make to improve the pace of development ââ¬â and I would like to share a few with you.
1st Generation Methodologies were about preventing common mistakes.
The problem was that code reviews took time to organize, and this increased time-to-market and waste.
So our 2nd Generation Methodologies reacted to that to remove waste.
XP puts the customer in the same room, so you never have to wait a week to get an answer when youââ¬â¢re blocked.
XP moves people to more generalist roles, rather than specialists, which decreases handholding, confusion, friction, and points of failure.
Pair Programming focuses a group on the task, eliminating a great deal of web browsing and goofing off.
So 2nd Generation Methodologies remove waste. Our theory is that 3rd generation methodologies will improve the pace of development.
How do you do that? Some techniques, like exploratory testing, work to make the practitioner more effective. What Iââ¬â¢m going to talk about today are techniques to accelerate innovation within teams, and itââ¬â¢s consequences.
