The dissertation/thesis writing season is approaching so I expect the recent set of questions from a student is the first of many. Actually they occur all year round but March to September is the busy period. So, to pre-empt any students bearing questions about Agile - and so I can just repeat my stock answers - here are some ideas you might want to consider first.
Lets start with the request itself.
I and many other people who are silly enough to write and blog about Agile software development get plenty of e-mail from students doing research on Agile. Fair enough, I like to help but if you don’t ask nicely I’m unlikely to respond.
- I won’t be answering stock surveys that are sent from a mail program.
- I’m much more likely to answer a personal request which indicates you actually know my name and even read some of what I have written.
I’m skeptical of most quantitive research (e.g. surveys) research on Agile simply because the question that I normally see are rubbish. Qualitative research is probably better but
- It is not as satisfying as quantitive, you can’t conclude “58% of teams use Agile” you come up with some wishy-washy case studies
- You actually have to go and talk to people, you can’t just compile a mailing list and feed it into Survey Monkey. That means getting out and finding people to talk to
If you must go down the quantitative route please do your homework, do some qualitative before you begin so you can ask good questions.
Now the number one mistake made by students who approach me is: Assuming there is such a thing as Agile.
That is to say assuming:
- one is either Agile or not Agile,
- secondly: one knows that one is, or is not Agile and
- thirdly: one is prepared to openly and honestly state it.
Agile is not binary. Nor for that matter is Waterfall. While we are about it Agile and Waterfall are not necessarily binary alternatives. Have a look at my Agile Spectrum article: the thing that is called “Agile”, and the thing that is called “Waterfall” are simply points on a spectrum - probably the two extremes - and most teams are somewhere in-between.
Nor is there anyway (at the moment) to objectively determine where a team is on the spectrum. Well actually there are plenty of people who will do an assessment of one sort or another but you have to look at what criteria they are using. My suggestion is get away from Agile as a whole and look at Agile practices.
Likewise get away from the methods - Scrum, XP, Kanban, etc. If you must look at different methods look at them in the context of practices. Agile methods are sets of practices, sometimes with values and principles thrown in.
Practices are the easiest of these things to observe and measure. They are objective, the other bits are subjective.
If you really want to dig deep - and make work for yourselves - you might want to investigate team values - do teams actually value the things Agile claims to value? This is going to take some doing. You probably want to look at what actually happens, shadow a manager for a week and see if their decisions accord with the values.
You might do it quantitatively by composing one of those surveys that asks people to choose between answers, e.g. “Under pressure to ship more often which are you most likely to do: a) make your stories smaller, b) offer financial incentives to the team, c) reduce unit testing, d) increase unit testing”.
Now some suggestions for some research, Agile research questions:
- Validate my spectrum: its a hypothesis, come up with some criteria and do a survey to see if you can determine the spread
- Practices: what are the practices that teams actually use? Specifically, what are the practices they say they use and which ones do they actually use?
- Which practices are the most popular?
- What difference do the practices make?
- How does Agile differ between product development companies and corporate IT? Add “solution providers” (e.g. Accenture, EDS, CapGemini and thousands of smaller companies) for extra marks.
- Correlation of practices to approach: do teams which call themselves Agile actually use practices associated with Agile? And likewise for Waterfall. A couple of years ago a student at Loughborough University, Adam Williams, rose to my challenge. He tried this, his survey was small, 20-odd companies, and he found little correlation at all. In fact he found some teams who described themselves as Waterfall but used several Agile practices. I would love to see this study expanded.
- What do Scrum Masters really do and how are they different from Project Managers?
- What are the recruitment practices of Agile teams and companies?
- Forget Agile, look at Waterfall, find teams who actively claim to do Waterfall and find out what happens, how do the unsuccessful ones differ from the successful? Are there any successful waterfall teams?
- Examine some of the more controversial practices: TDD, pair programming, refactoring. Do a meta-analysis of the studies to date or do your own studies.
- Extend Keith Briathwaite’s work the correlation between TDD and cyclomatic complexity.
- TDD, benefits and the power law - I should blog about this but for now just take my word for it.
Finally the big one.
Real Agility is not about methods, practices or names, it is the state of being Agile. (Something that was meant to be in the title of my first book but was messed up.)
- What is the state of Agile? - in theory and in reality
- What advantage does the state of Agile confer?
So if any student out there wants to raise to the challenge on these questions please get in contact, I’d love to help and to see the final research.
