Fabian Fagerholm
Department of Computer Science
University of Helsinki
P.O. Box 68
FI-00014 UNIVERSITY OF HELSINKI
These are survey items related to Lean/Agile values.
1 | Software developers should be allowed to freely choose any tools they wish to use | 2 | I want to spend time on identifying and eliminating unnecessary work in software development projects | 3 | A development process has to be followed strictly and with discipline | 4 | I wish pair programming would always be used in the projects I work in | 5 | Working on many things simultaneously makes me more productive | 6 | If I have the choice, I skip documenting and write code instead | 7 | When faced with a large problem, everyone in a software development team should stop what they are doing and work together to solve it | 8 | Sometimes, I like to program a feature that is not yet needed | 9 | If something is broken in the software under development, it should be fixed immediately | 10 | Physically moving around a lot lowers my productivity | 11 | It is very important for team members to know the contents of the contract(s) made with the paying customer | 12 | People are more important for success than following a development process | 13 | You should never work longer hours to get things done at the expense of quality | 14 | The best architectures and designs are created when a single person is responsible | 15 | Before implementing a feature, its value should be tested on end users | 16 | It is impossible to fully plan a software project | 17 | Deadlines should be optimistic | 18 | Software development team members should have the authority to choose what they work on | 19 | When I am involved in building software, I try to make sure that it is fully documented | 20 | The leader(s) of a team should be experienced developers themselves | 21 | In software development projects, I prefer to just solve problems as they come rather than thinking far ahead | 22 | User needs might be important, but software developers should focus on the implementation details | 23 | I often feel that work cycles should be shorter and faster | 24 | Great software is the result of the customer constantly monitoring the project | 25 | Having no development process leads to chaos and failed projects | 26 | It is important to take the time to perform extensive code reviews | 27 | Having the best people in the project is more important than having the best development tools | 28 | When working on a particular task, I feel uncomfortable if I don't have a clear idea of when it can be called "done" | 29 | I prefer having everyone follow a process rather than interacting with people to agree on what to do next | 30 | When implementing a feature, it is critical to know who needs it and why | 31 | Without careful planning, it is impossible to deliver good software | 32 | The best software developers are highly specialised and focus on their speciality | 33 | Tasks should always be doable in one iteration | 34 | I prefer large software development teams rather than small ones | 35 | Even if something is broken in the software under development, the focus has to be on what was planned, not on fixing everything | 36 | Requirements changes are not a big issue, they are handled as part of the work | 37 | Efficient communication is more important than face-to-face communication | 38 | I find it important that the paying customer agrees with the team's development process | 39 | All team members must have a clear understanding of who the software is intended for | 40 | It is ok to make up a feature in order to justify the use of the latest technology | 41 | If someone in a team has agreed to do certain tasks, but cannot complete them, someone else from the team has to take responsibility of delivering the results | 42 | If an ongoing task can be finished very soon, it should always be finished even if there is a more important task pending | 43 | A well-managed process compensates for not having the best people in the project | 44 | Striving for perfection is more an individual undertaking than a collective one | 45 | I think spending time on analysing previous work is pointless | 46 | Several product owners is better than one product owner | 47 | I am annoyed when requirements change | 48 | To get more done in software projects, you must work longer hours | 49 | It is worth breaking deadlines in order to achieve sufficient quality | 50 | Time should be used to try and clarify tasks even though the task may not become clearer | 51 | I often feel that work cycles should be longer and more thorough | 52 | My highest priority is to satisfy the customer by continuously delivering valuable software | 53 | Changing requirements are welcome, even late in development | 54 | Business people and developers must work together every day throughout a software development project | 55 | I only do tasks that are in the iteration backlog, even if someone asks me to do another really important task | 56 | If someone is not motivated to work in a software development project, they should be removed from the project | 57 | Working software is the only right measure of project progress | 58 | The best architectures and designs are created when teams can organise themselves | 59 | Having the best people in the project is more important than spending time on managing the process | 60 | It is acceptable to document a feature but never implement it | 61 | I often feel that projects use development processes and methods that serve no real purpose at all | 62 | Team members should be able to justify why they use certain tools | 63 | When someone makes a mistake, resources should be used to make sure the same mistake can not happen again | 64 | Arguing about technical details is helpful in the long run | 65 | The main thing is just to get the work done, it's not my job to figure out work processes | 66 | Great software is the result of close collaboration with the paying customer | 67 | Requirements can change, but it should not be permitted to change requirements during an iteration | 68 | It is beneficial to prepare stories or task descriptions months or weeks in advance | 69 | Before releasing anything or committing new code, time should be spent "polishing" it | 70 | Documentation and code should always be written in parallel | 71 | The best software developers are generalists and can work on any part of the end product | 72 | Great software is the result of a great plan which is carefully followed | 73 | I try to be flexible and if someone has an important task that is not in the iteration backlog, I do it anyway | 74 | It is acceptable to remove unnecessary or obsolete features even if it means that things that used to work will no longer work | 75 | Asking someone who already knows the answer to a question is always better than figuring out the solution oneself | 76 | No matter how much time it takes, understanding old code is important | 77 | I have no problem switching tasks even though I have already started another task | 78 | It is best to meet in person instead of calling or emailing | 79 | Not knowing who the end user is during a project is a big problem | 80 | Programmers are supposed to write code, and it's not their responsibility if tasks overlap or are unclear | 81 | I prefer interacting with people to agree on what to do next rather than having everyone follow a process | 82 | Work should not start before exact tasks and specifications are ready | 83 | There has to be someone with authority who regularly reviews and approves a team's work before it can continue | 84 | Code should always be tested as soon as it is written | 85 | Software teams should make decisions as early as possible | 86 | Great software is the result of carefully applying a great software development process | 87 | I need to feel sure that the goals set for each development iteration are achievable | 88 | Deadlines and due dates should be set well in advance | 89 | Only those with the greatest knowledge and highest expertise in one particular area should make decisions that have to do with that area | 90 | To succeed in a software project, you must stick to the plan | 91 | Great software is the result of constant replanning when changes occur | 92 | Deadlines should always be met no matter what | 93 | Everyone in a team should know what all the others are working on | 94 | Software development team members should be allowed to organise themselves in any way they see fit |
The following value dimensions have been identified using agglomerative hierarchical clustering.
NWF | Narrow Work Focus |
FLX | Flexibility in Task Execution and Leadership |
PNP | Planning and Preparation |
ATP | Adherence to the Process |
DIS | Discipline |
ROP | Reliance on People |
FTO | Freedom to Organise |
SOP | Sense of Purpose |
PRE | Predictability and Justification |
COL | Collaboration |
BSI | Broad Stakeholder Involvement |