Notes to students doing research about Agile

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

  1. 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
  2. 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.

#NoProjects becomes #BeyondProjects and online

On Monday night I delivered a talk at Skills Matter in London entitled “Beyond Projects: or the end of projects and what to do about it.” This was the latest evolution of the #NoProjects meme being advanced by Steve Smith, Joshua Arnold and myself.

Steve, Joshua and I have been thinking that #NoProjects is a bit negative and something like #BeyondProjects would be more positive but we didn’t reach a final decision. Having read some of the Tweets after Monday I’ve decided.

#NoProjects is now #BeyondProjects – that also sidesteps the problem of teenagers on Twitter using the first of those hashtags to denote the end of their coursework.

The talk was well received and I’ve got mails and conversations to follow up.

The #BeyondProjects slides are now online at Slideshare and Skills Matter have published a video of the talk.

If you want to know more about this see my blog last year “Beyond Projects, Beyond #NoProjects” see too Steve’s past blogs and Joshua’s blogs, particularly “The Problem with Projects.” What is really interesting is Steve, Joshua and I all started rethinking projects from different points of view.

My thinking originated with the cognitive dissonance that exists because successful software doesn’t end but projects do. I think projects don’t make a good model.

Steve comes from a continuous delivery point of view.

And Joshua emphasises risk and value more.

Gradually these three points are being woven into one story.

 

Xanpan update

As regular readers will know I have been working on a new book, or rather a new ebook called Xanpan. Indeed, since I am using the LeanPub system some people are now reading the book.

The content in this volume stabilised a few months ago but as always my English is a little eratic. The book needed a professional copy edit – indeed even better writers than I have their books professionally copy edited. This was done a few weeks ago but I’ve only now been able to complete all the other changes.

So today I am proud to announce a new version of Xanpan.

I would like to offer readers of this blog a buy the book at a discount, half the recommended price. If you follow this link to Xanpan on the LeanPub site or enter the code “BlogMarch2014” when buying the book the price will be reduced. These discounts should be good until the end of next month.

(I’m sorry, LeanPub works in US dollars so although most readers of this blog are in places which are not the USA, particularly the UK, I have no choice.)

Apart from the copy edit the most significant change is I’ve changed the subtitle from “Personal reflections on agile software development” to “Team centric software development.”

While this book still contains my reflections – and sense making – on the development process, and particularly agile, the feedback I had from several people suggested that Xanpan differs from other methods by its emphasis on the team.

I expect the team centric aspect to be more noticeable in a second volume I plan to write “Xanpan: Management heuristics”. And I have a thought for a third volume “Xanpan: Requirements” but not for a while yet.

The next task is to make this version of Xanpan available as a hard copy. That should happen in the next few weeks.

In the meantime, if you have any comments or feedback please let me know.