I had the pleasure of ducking in and out of STPcon today. So, the conference is still going on, I just had to leave early. I've been doing the testing conference thing for 24 years, speaking for 23 of those years. So, I've been to the rodeos quite a bit.
So many ideas are swirling about, which is a good thing. The challenge is sorting them out to make sense in your own situation.
I was observing the panel discussion about agile testing and some things struck me:
1) What happened to XP... and then, Crystal and then...? What I mean is they apparently went out of style. In 2001 I was at a conference where XP was the solution to all problems. Now, it seems there is a new kid on the software block, Kanban. So, the discussion is around Scrum vs. Kanban.
This all makes me think there is "nothing new under the sun." People seem to want to follow the new thing, which I totally get, but why? Typically, it's because the present methods have problems. Why?
The reasons go to deeper issues, I think, than the flavor of the methods being used. I keep going back to my mantra that "the magic is not in the method." It is something deeper and more esoteric than a methodology.
I am convinced I was on an agile team in 1979.
2) People, tools and process...if you gravitate to just one or two of these, you will be out of balance.
OK, so you love the people and the team. That's great and the right people, all being able to get along is key to good projects. But...even the best teams need the right tools and the right methods to get the job done.
3) The customer is king, regardless what your process is. Your customer may be the end-user or the CEO. If they want something, you better get it to them (thanks, Scott Barber, for making this emphatic point today!). If you stick with your process in opposition to what your customer wants or needs, you will be replaced.
I once was teaching a class when on the afternoon of day 1, half of the class had to leave. Some of you cynics are thinking "I can totally see that" but no, it wasn't due to the teacher. It seems they had to restore functionality of a change back to the original version. They got the requirement totally right. They implemented the change 100% correctly. However, a powerful stakeholder got so much push-back on the change, he said "pull it." So, even though everyone had done their job correctly, there was still a problem that had to be dealt with. (By the way, this was all based on a new state law that was passed and was being implemented. The stakeholder was a state senator.)
4) Software development is a creative process and has to be managed as such. It's also a knowledge-based process and knowledge-based workers are not the same as other types of people. Otherwise, we could create software with software all the time, not just some of the time. I know, we have visual tools and the like, but remember CASE tools? There are some principles of manufacturing that can be applied well in software, but we must remember that software is intellectual in nature.
5) Release processes drive almost everything else. If you get this wrong, you can get really bound up. Some of us can recall the famous "I Love Lucy" episode where she and Ethel work in a chocolate factory wrapping the candy as it travels down the conveyor belt. The candy keeps coming faster and faster. They can't keep up and start eating it, stuffing it...funny stuff. I see this in software projects all the time. Too much work, too fast pace, people just try to get the stuff out of the door. Then when things don't work, the testers get blamed.
No matter which method you use, if you can't control scope and pace, you won't succeed. You will always be behind and your customer will always be complaining.
Well, those are some thoughts in the airport. I would like to hear your thoughts.