Agility survey Review with FusionMLS Team 4 (September 21)

Screen 1: Questing clearness Q1 Have you previously taken this survey? Q2 As you respond to this survey will you be thinking mostly about your:

Screen 2 : Questing clearness Q1 Does your project need to meet any regulatory requirements (ISO 9001, Sarbanes-Oxley, etc.):

Screen 3: Questing clearness Define what project means more clear

Q1 How long had this 'group' (as identified above) been doing agile development prior to starting this project? Q2 Which best characterizes this project?

Between commercial software and web development

Screen 4: Questing clearness What does it mean? How many on team or entire project Why should 10 people give answers on generic questions

Q1 About how many people were or are on the project being assessed (or your last project)? Q2 About how many teams were on the project being assessed (or your last project)?

Screen 5: Questing clearness Need hint

Q1 What industry best describes the project being assessed? Q2 What best describes your role on the project? (pick one)

Screen 6: Questing clearness Need clarification outsource not off shore This is a generic question. Team suggests having this information prefilled.

Q1 Does this project involve outsourced Agile development? Q2 What is your company's name?

Screen 7: Questing clearness generic

Q1

What was the project's name?

Q2 Where were employees on the project located?

Screen 8: (Demographics) Questing clearness Should be anonymous. May advise on generic content Should be anonymous. May advise on generic content

Q1 Q2

What is your name?? What is your title?

Screen 9: (Demographics) Questing clearness Should be anonymous. May advise on generic content

Q1 Would you like to be contacted with further information about this research? Q2

Screen 9: (Teamwork) Questing clearness Need clarification on team versus other responsibilities

Q1

People are not on more than 2 teams

Q2 Specialists are willing to work outside their specialties to achieve team goals. Q3 Everyone required to go from requirements to potentially shippable product is on the team Q4 Testers and programmers are on the same team. Q5 Teams have 5-9 people on them. Q6 Team members are kept together as long as possible

Answered No since CM is not part of process. Probably need some guidance

May be need clarification on what as long as possible mean

Screen 10: (Teamwork) Questing clearness Whose standards are non-value-adding. There are many way to read it. Is it for company, client, internal customers, infrastructure or else. Is it features vs bug fixing? Double negative does not help

Q1 We don't need to work on non-value-adding tasks

Q2 Management sets goals but doesn't tell us how to achieve them. Q3 Teams can determine who is on or off the team. Q4 Team members choose which tasks to work on.

Screen 11: (Teamwork) Questing clearness Q1 During an iteration, it feels like we're all headed toward the same goal. Q2 Management rarely changes our priorities during an iteration.

Screen 12: (Teamwork) Questing clearness Q1 Q2 Teams have a stand-up meeting everyday. We communicate mostly face-to-face. May be better Phrase as We communicate faceto-face as much as possible

Q3 Agreements between the team and the product owner are made and perhaps documented but not enforced by signoff. Q4 Standup meetings take less than fifteen minutes. Q5 Formal written documents are used to supplement rather than replace faster, more informal communication. Q6 Standup meetings are effective at synchronizing work Q7 All team members meet in person at the start of the project.

Definition of project required and definition of team members (This team or project team)

Screen 13: (Teamwork) Questing clearness Q1 Team members work hours that overlap substantially. Q2 Team members are located in the same city. Q3 Team members are located on the same floor. Q4 Team members work in a shared physical environment. Q5 Team members are located on the same campus. Q6 Team members are located within the same time zone. Q7 Team members are located in the same building.

Might need clarification

Screen 14: (requirements) Questing clearness Q1 We acknowledge that not all details can be conveyed in written specifications Q2 The details of a feature are fleshed out in just-in-time discussions Q3 Written requirements are augmented with discussion. Q4 Our product owner is available to discuss features during the iteration. Q5 Q6 Q7

Screen 15: (requirements) Questing clearness Q1 During an iteration the specific details of some features are negotiable. Q2 Teams are able to start projects with incomplete requirements. Q3 Requirements are represented at different levels of detail based on how soon we expect to implement them. Q4 Q5 Q6 Q7 What does it mean? May need a clarification

Screen 16: (requirements) Questing clearness Q1 Development teams can request and negotiate requirements changes with product owners. Q2 Product owners acknowledge that sometimes features turn out to be bigger than anyone thought. Q3 Product owners can change requirements without a lot of fuss. Q4 Change is a natural part of our business; we accept it and embrace it at resonable times Q5 Q6 Q7

Need probably a definition of scale and timebox. Current sprint versus future sprints

Screen 17: (requirements) Questing clearness Q1 Technical design occurs iteratively throughout a project. Q2 Technical design is a team activity rather than something performed by individuals working alone. Q3 Projects to not begin with a big, distinct technical design phase. Q4 Q5 Q6 Q7

Screen 18: (Planning) Questing clearness Q1 At the start of each iteration we create a plan showing the tasks that we'll work on during that iteration. Q2 Before the first iteration, we create an initial plan that shows an incremental release of features and update this plan during the project. Q3 Q4 Q5 Q6 Q7

Screen 19: (Planning) Questing clearness Q1 Product owners prioritize work for teams.. Strange question.

Q2 One or more of scope, schedule, or resources is allowed to change during a project. Q3 Product owners are willing to discuss tradeoffs between scope and schedule. Q4 Q5 Q6 Q7

Screen 20: (Planning) Questing clearness Is it my team or other teams

Q1

Teams know their velocity.

Q2 We create an update iteration burndown charts, which shows how estimated work is remaining each day. Q3 At the end of each iteration, we create a release burndown chart, which shows how much work remains in the release. Q4 Features are either complete or not; no partial credit it given. Q5 Q6 Q7

Dont need lawyers to be involved.

Screen 21: (Planning) Questing clearness Q1 Estimates are created collaboratively by the people who will do the work. Q2 Developers are included in the planning process in a way that they can meaningfully and appropriately affect scope and deadlines. Q3 Q4 Q5 Q6 Q7

Screen 22: (Planning) Questing clearness Q1 Upfront planning is helpful without being excessive Q2 Teams communicate the need to change release date or scope as soon as they are discovered. Q3 Team members leave planning meetings knowing what needs to be done and have confidence they can meet their commitments. Q4 Effort spent on planning is spread approximately evenly throughout the project. Q5 Q6 Q7

Screen 23: (Technical Practices) Questing clearness Q1 All production code is written using testdriven development. Q2 Programmers always write a failing test before writting production code. Q3 Q4 Q5 Q6 Q7

Screen 24: (Technical Practices) Questing clearness This is ambiguous question. Q1 When someone goes on unexpected leave we don't worry about who will cover his or her work. Vacations usually planned ahead of time

Q1 When someone goes on vacation we don't worry about who will cover his or her work.

Q2 Production code is written using pairprogramming. Q3 People switch pairing partners at least once a day. Q4 We have a physical and computer infrastructure that supports pair programming. Q5 Q6 Q7

Screen 25: (Technical Practices) Questing clearness Q1 Code contains little or no duplication. May be ambiguous and subjective

Q2 Refactoring is performed whenever needed. Q3 There are enough automated tests that we can refactor without worrying about breaking existing functionality. Q4 Any code can be refactored; no code is too dangerous to touch. Q5 Q6 Q7

Screen 26: (Technical Practices) Questing clearness Q1 The entire system is built automatically at least once per day. Q2 Source code is stored in a configuration management system. Q3 Developers check in code at least once per day. Q4 Unit and acceptance tests are run as part of each automated build. Q5 Q6 Q7

DBA cant check once per day.

Screen 27: (Technical Practices) Questing clearness Q1 Coding standards are effective at helping support collective code ownership. Q2 We have a coding standard for each language we use. Q3 Coding standards are known and used by the whole team. Q4 Q5 Q6 Q7

Screen 28: (Technical Practices) Questing clearness Q1 Anyone is allowed to change any code.

Q2 There are enough automated tests that everyone feels safe changing any code without worrying about breaking existing functionality Q3 Q4 Q5 Q6 Q7

Screen 29: (Quality) Questing clearness Q1 Programmers always write automated unit tests. Q2 All unit tests are run and pass before code is checked in. Q3 The entire suite of unit tests is run in an automated way. Q4 Running all unit tests is fast, so we run them frequently. Q5 Q6 Q7

Screen 30: (Quality) Questing clearness Q1 Acceptance testing is automated and run at least once a day. Q2 Product owners provide the acceptance criteria for each feature. Q3 A feature is not complete until its acceptance tests pass. Q4 Q5 Q6 Q7

Screen 31: (Quality) Questing clearness Probably dont have information. Answer could be subjective

Q1 At the end of each iteration the is little or no manual testing required. Q2 All bugs are fixed during the iteration in which they are found. Q3 Testers are productive right from the start of each iteration. Q4 There is no big handoff between programmers and testers either during or at the end of an iteration. Q5 All types of testing(performance, integration, scalability, and so on, for example) is performed each iteration. Q6 Q7

Screen 32: (Culture) Questing clearness This is subjective

Q1 Teams feel an appropriate amount of pressure to meet deadlines. Q2 We maintain a high rate of productivity without being overworked. Q3 We don't cancel training, holiday, and vacation time when behind schedule. Q4 Product owners are willing to consider delivering less than a 100% of a solution. Q5 Management allows team members to make the decisions that should be theirs to make. Q6 Developers and product owners participate equally in determining what features will be included in a given release (i.e., release planning). Q7 Product owners understand that sometimes solving 20% of the problem delivers 80% of the value.

Screen 33: (Culture) Questing clearness Q1 We rarely add people when changing scope or schedule might be better solutions. Q2 When faced with a stressful situation, our initial reaction is to prioritize and explore tradeoffs. Q3 We avoid people having to work long stretches of evenings and weekends to meet deadlines. Q4 Q5 Q6 Q7

Screen 34: (Culture) Questing clearness Q1 Product owners and other stakeholders are consistently involved throughout the entire project. Q2 Product owners are co-located with teams. Q3 Product owners respond to team requests in a timely manner. Q4 Teams have reasonable access to their product owners. Q5 Q6 Q7

Screen 35: (Culture) Questing clearness Q1 Titles are not significant in how team members interact with one another. Q2 Bonuses, annual reviews, and compensation promote team behavior. Q3 Q4 Q5 Q6 Q7

Screen 36: (Culture) Questing clearness Q1 We aren't forced to use software tools that don't help us. Q2 Our telecom systems (phones, VOIP, video conferencing, conference calling) help us be agile. Q3 Our software tools help us be agile. Q4 Our physical environment (office space, conference rooms, access to white boards, etc.) help us be agile. Q5 Q6 Q7

Screen 37: (Culture) Questing clearness Q1 Our default answer is 'yes' rather than 'no, it can't be done.' Q2 Our ScrumMaster or project manager is good at their job. Q3 Team members have the appropriate skills and knowledge to do agile development. Q4 Product owners are good at their job. Q5 Team members know who their ScrumMaster or project manager is. Q6 Team members know who their product owner is Q7

Screen 38: (Knowledge Creating) Questing clearness Q1 Iteration retrospectives are attended by all team members. Q2 Iteration reviews are attended by product owners, stakeholders, and team members who actively participate. Q3 We do iteration reviews at the end of each iteration during which we solicit feedback on the state of the software. Q4 Iteration retrospectives lead to refinements in our process. Q5 We hold retrospective meetings at the end of each iteration during which we evaluate how we're doing and discuss how to get better. Q6 We get actionable feedback from our iteration review meetings. Q7

Screen 39: (Knowledge Creating) Questing clearness Q1 We agree on how much testing and how much deployment must be done within the iteration. Q2 All work is done in iterations of no more than 30 days. Q3 Within our iterations work such as design, coding and testing overlay rather than being performed sequentially; this is, no mini-waterfalls. Q4 Iteration retrospectives lead to refinements in our process. Q5 At the end of iterations, we have working software that could be given to friendly first users. Q6 Q7

Screen 40: (Knowledge Creating) Questing clearness Common principles could mean different things for different people.

Q1 We share a set of common principles. Q2 Teams exhibit courage in discussing problems. Q3 We are willing to acknowledge and adopt other options. Q4 We value learning new approaches, technologies, skills and practices. Q5 We ask questions of each other as often as we advocate positions. Q6 Q7