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