Dear Software Developer

[tvaperi]

Dear Software developer,

in the context of my PhD I am conducting a study with the working title [redacted].

It aims to make the agility of a software project measurable. The instrument has already been developed but I need about 500 participants to test its validity and it's really challenging.

I would be very grateful if you would support me by participating in my study.

Here is the link: https://ww2.unipark.de/uc/PhD/1d1a/

The questionnaire is a bit long, but it is important to go till the end. Please contribute those 15-20min towards science.

Thank you very much! Kind regards.

[fjfaase]

I wanted to fill in the questionair, but the second question does not have the option: No cycles. What is your definition of agile if you have to work in cycles to be agile in the first place?

I very much enjoy they way we are working at my current working place. We do not have cycles, we do not do daily stand-ups, we have one team meeting per week, which last about one hour (often less). We have several people working off-site and some people are working from home part of their time. We communicate through an instant messenger. We do not have a product ownere, but we do have almost daily contact with our in-house users of the software we develop, through some formal meetings and informal interactions. We have an list of issues and every one just picks the issues that they want to work on. Generally, we like to work on issues that help our colleagues who are using the software we develop. It alsmost feels as the most agile way of working I have ever done during my career, but I guess it does not measure very agile.

[tvaperi]

Thank you very much for your participation. We try to cover all aspects of agile software development like "short release" etc. as describe in the literature. This is the reasons why the questionnaire is so long. Whether short release belongs to agility or not we hope to find out during the analysis.

Thank you again for your participation!

[HelloNurse]

> Whether short release belongs to agility or not we hope to find out during the analysis

Where do you draw the line between "agile" and not "agile"? Do you have objective criteria?

Considering practices agile if they are associated with other agile practices is circular, considering practices agile if they are claimed as agile in some literature is incoherent.

[HelloNurse]

There are buzzword buffer overflow errors in question 7 (Which of the following agile method are you using?) and 8 (Which of the following practices are you using?).

Item by item explanations might improve the quality of answers from developers who are actually doing X but aren't aware that it has a name, or who are doing something slightly different from canonical descriptions of practices.

Edit: thinking of it, you might also make a more explicit distinction between what you do, what someone else does, and what your manager says the team does (with the latter suitable for the bingo card format of questions 7 and 8).

[tvaperi]

Thank you very much for your participation and your feedback.

Question 7 and 8 "only" help us to know which practices and/or methods are in use in software development. The remaining questionnaire is independent of any buzzwords or if you are using a practice exactly right out of the textbook.

Thank you again for your participation. If you haven't finished yet you can continue where left by opening the link again.

[HelloNurse]

I'm afraid you don't understand the problem with questions 7 and 8: informed answers would require in-depth knowledge, with a lot of critical awareness, of a large number of techniques that are described in hard to find primary sources and commonly misunderstood. So it might make sense to ask what practices one has heard about (and from what sources), or what people say they are doing, but asking what a developer is actually doing is to a large extent ill-defined (e.g. how many untested emergency fixes are enough to void a rigorous testing process? How many late night emergencies can fit in a 40-hours work week?) and it requires weeks of study.

As noted in other comments, there's also the issue of your assumptions; for example release cycles with a definite scale, while in reality there are nested or overlapping long and short cycles (from edit-compile-run to formally discussed tickets and other units of work to public releases and updates to grand rewritings and replacements): different practices apply to each cycle.

[baash05]

Lost me at Which of the following agile method are you using?

TDD is not a method of agile. It has nothing to do with project management or team structure. On a rails/elixir team you TDD as a reflex.

Release cycle is many times a day. On a team of 20 devs, we're releasing to prod about 12 times a day.

The idea of Projects keeps coming up. Often projects are 1 or 2 day features. Customers don't feedback in a day or two long feature.

Then we A/B test the feature, and if it improves the metrics, we move on.

...

Ahh... I see what you did here.

These projects are desk or mobile apps. Clear release cycles and manuals. Web dev's deliver many times a day. There is no major and minor version management in most places. In fact many places have different teams delivering different features on one app at the same time.

"You take the necessary time to document the changes you made to make them traceable, even in crunch time." -> GIT takes care of this, and has been for well over 10 years now. No dev company would go without git or like.

[tvaperi]

Thank you very much for your participation. We try to cover all aspects of agile software development like "TDD", "short release" etc. as describe in the literature. This is the reasons why the questionnaire is so long. Whether those belongs to agility or not we hope to find out during the analysis.

We assume that CMM tool only provide the technical basis for a good documentation but how well it is used depends on the developer.

Thank you again for your participation!

[HelloNurse]

> We assume that CMM tool only provide the technical basis for a good documentation but how well it is used depends on the developer

This comment exemplifies an important potential source of bias in your future analysis: judging how well practices are applied, which is neither objective, feasible, or relevant. Someone's use of a practice shouldn't be considered more (or less) agile on the basis of their success, and you also lack clear measures of success to begin with.