Agile Questionnaire How to Interpret Your Results Agile

Agile Questionnaire – How to Interpret Your Results Agile Demystified Amadori Courses: Agile Demystified 1

In this session we will look at the detail of the Questionnaire. Introduction And how you should use your responses to it to decide your next steps with regards to Agile Amadori Courses: Agile Demystified 2

• There are no right answers or target scores in this Questionnaire. Important to Remember • Questions which are important to you will not be important to other organisations – and vice versa • Questionnaire simply there to allow you to apply Agile concepts more easily to your current situation Amadori Courses: Agile Demystified 3

Questionnaire Breakdown Questionnaire contains 108 Questions Split between the 12 Principles as follows Amadori Courses: Agile Demystified 4

01. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. 28 02. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. 13 03. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. 2 04. Business people and developers must work together daily throughout the project. 4 05. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. 14 06. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. 4 07. Working software is the primary measure of progress. 8 08. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. 9 09. Continuous attention to technical excellence and good design enhances agility. 4 10. Simplicity--the art of maximizing the amount of work not done--is essential. 5 11. The best architectures, requirements, and designs emerge from self-organizing teams. 11 12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly Grand Total 6 108 Amadori Course 5

Next Steps • I propose to quickly review the questions posed against each principle • And suggest what typical answers might mean in terms of an organisation’s readiness to adopt Agile practices Amadori Courses: Agile Demystified 6

01. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. • 28 questions divided into 4 sections as follows Continuous delivery 19 Early delivery 2 Regulatory Change 1 Satisfying the customer 6 Amadori Courses: Agile Demystified 7

Continuous Delivery • how often do you deliver new software each year? • how long does it take to release a new version into live • how long does it take on average to agree requirements? • how long does it take on average to develop new code ? • how long does it take on average to test and fix a release? • do you have tools to help manage code versions and different streams of code • do you have separate development test and live environments? • how quickly can you move code from one environment to the next? • how quickly can you cut a new version of code • can you successfully back out a version of code and replace it with its predecessor? • is this an automated or manual process ? How long does it take? • does you have a set of regression tests • are they complete and up to date? • are they manual/automated or a combination of the two? • how long does it take to complete a regression test? • how long on average does it take developers to produce a new build with bug-fixes? • do your dev and test environments include copies of live data? • how often is the data in these environments refreshed? • how long does a data refresh take? Amadori Courses: Agile Demystified 8

Continuous Delivery • The purpose of these questions is to ascertain how quickly you can deliver new releases. • It may be that as things stand that no more than 4 releases is feasible • When Agile expects between 12 and 26 releases annually Amadori Courses: Agile Demystified 9

Reviewing your answers to these questions will highlights the areas which need to change before you can successfully introduce Agile processes Continuous Delivery For each area where change is required ask yourself A. Is the ability to make the necessary change directly within your control B. Or do you need the permission/support of others to make the changes? Amadori Courses: Agile Demystified 10

Continuous Delivery If the changes are largely within your direct control then a move to Agile should be feasible. If they are not you may face more fundamental issues A move to Agile may be possible only if the organisation as a whole realigns its existing processes and structures to better support Agile Amadori Courses: Agile Demystified 11

Early Delivery 2 questions have recent deliveries been on time? have recent deliveries been a success? Amadori Courses: Agile Demystified 12

Early Delivery Agile requires that you make frequent deliveries of working software which adds value to the end user If you don’t have a track record of delivering on time or if customers are generally unhappy with what you do release Then a move to Agile at this point in time may be too ambitious for your organisation…. . Amadori Courses: Agile Demystified 13

Early Delivery A better policy might be to concentrate on addressing some of the process issues this Questionnaire has highlighted first And the review your progress against the Questionnaire once these changes have had a chance to bed in Amadori Courses: Agile Demystified 14

Regulatory Change 1 question does your software need to reflect regulatory and legal changes? Amadori Courses: Agile Demystified 15

Regulatory Change Agile is not particularly well suited to Regulatory Change as such changes are • Usually required on a certain date • All of the requirements must be delivered at that date Amadori Courses: Agile Demystified 16

Regulatory Change It is therefore difficult for many key Agile principles to be applied here as it not possible 1. For the delivery team to decide what elements should be delivered and in what order 2. Move elements of the delivery from one release to the next to maintain a constant workload Amadori Courses: Agile Demystified 17

Regulatory Change If your organisation must implement a lot of regulatory changes Agile may not be the delivery process for you Or you may instead decide to deliver regulatory changes outside the usual delivery cycle via a non agile process Amadori Courses: Agile Demystified 18

Satisfying the Customer 6 questions do you know who your customers are? are they internal/external or a mix of both? do you have direct contact with your customers? how frequent is this contact? do you have direct contact with a representative sample of your customer base? is your contact primarily with the end users of your software or with their management team? If your organisation must implement a lot of regulatory changes Agile may not be the delivery process for you Amadori Courses: Agile Demystified 19

Satisfying the Customer Your answers to these questions may reveal that in practice the delivery team has little if any direct contact with its customers And therefore little if any control into what requirements are added to each delivery Amadori Courses: Agile Demystified 20

Satisfying the Customer Agile requires that the delivery team is in daily physical contact with its customers If this isn’t the case a successful Agile implementation becomes very difficult to achieve Amadori Courses: Agile Demystified 21

13 Questions How do you identify changes in requirements? Who decides which changes need to be delivered and by when? Do you map testcases against requirements how long do you estimate the fix will take to develop 02. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. what degree of confidence do you have in these estimates? How easily can you establish the amount of new testing required to test the fix How easily can you establish the amount of regression testing required around the fix how quickly on average can you make a critical change live how quickly on average can you make a non-critical change live how quickly on average can you make a non critical change live how disruptive is the process of making a critical release live? how quickly can you respond to a new regulatory change how quickly can you respond to an opportunity in your market to expand/make more money Amadori Courses: Agile Demystified 22

02. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. It should be obvious from your answers to these questions whether 1. You are currently an organisation which copes well with change 2. You struggle to deal with changes to agreed delivery plans If you fall into the second category you should work on addressing the issues highlighted by your answers to these questions BEFORE attempting to implement Agile processes Amadori Courses: Agile Demystified 23

03. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. 6 Questions how often do you generally produce releases per year? what prevents you from releasing more frequently? do your releases require fixes in production immediately post go-live? is end user feedback about the release positive? does the release meet the needs it was designed to meet? are any significant gaps in a delivery identified only after iot has gone live? Amadori Courses: Agile Demystified 24

03. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. To implement agile you need to 1. Deliver Frequently 2. Deliver something of Value in EVERY Release Amadori Courses: Agile Demystified 25

04. Business people and developers must work together daily throughout the project. 3 Questions do business representatives and developers work together in the same building are their desks adjacent to one another? are there representatives from the business embedded full time within your delivery teams? Amadori Courses: Agile Demystified 26

04. Business people and developers must work together daily throughout the project. For Agile processes to take hold, it simply isn’t enough for business and developers to have a single formal meeting each week Interaction must be constant and informal to allow teams to adapt quickly when priorities change or issues arise Amadori Courses: Agile Demystified 27

05. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. 14 Questions would you consider your current development team motivated? if so what motivates them? if not what problems need to be addressed? is there an independent objective method of measuring individual's motivation within the team? is low motivation seen as an issue which is primarily for the individual or the organisation to address ? are motivation levels reflected in salary/bonus reviews and/or career progression what is the process for requesting additional hardware/software/support for a project? do you currently allow delivery teams to decide what sort of hardware and software they use on a project? do you provide delivery teams with a budget they can spend on project delivery? would the organisation as a whole be happy to give control over these areas to individual delivery teams Amadori Courses: Agile Demystified 28

05. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. If your current team is not motivated…. . Simply switching to Agile may not fix the problem. It could simply give them something new to complain about Amadori Courses: Agile Demystified 29

05. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. Also, a team may be motivated by the prospect of Agile But if in reality they still have no real input or control over the delivery process They will soon become demotivated Amadori Courses: Agile Demystified 30

05. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. Here more than for any of the other 12 principles overall Company Philosophy is key If a company will not devolve decision making power to delivery teams it will be impossible to properly implement Agile processes Micro Management and Agile Delivery cannot exist in the same project at the same time Amadori Courses: Agile Demystified 31

4 questions 06. The most efficient and effective method of conveying information to and within a development team is face-toface conversation. how often per day do members of the business and development teams speak together? do members of both teams sit in the same area/share the same coffee machine? what is the most common form of communication between business and development (emails/formal meetings/phone calls/informal chats) what are the biggest barriers to improving communication between business and development? Amadori Courses: Agile Demystified 32

06. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. Your answers to these questions wil reveal whether you work for an organisation in which 1. Informal communication is encouraged 2. Communication is more formal and controlled if your organisation falls into the second category you should concentrate on addressing the issues identified here BEFORE you attempt to implement Agile Amadori Courses: Agile Demystified 33

8 questions how do you currently assess the success of a release? 07. Working software is the primary measure of progress. how do you measure whether a piece of software is working correctly? what other measures of success do you use? what is the short term impact arising from a release which is viewed as not working correctly? what is the long term, impact arising from a release which is viewed as not working correctly? what impact does a successful release have upon existing processes? what impact does a successful release have upon those who worked upon the release? how are successful releases reflected in salary and bonus discussions and career progression? Amadori Courses: Agile Demystified 34

07. Working software is the primary measure of progress. • When you review your answers to these questions, one or more of the following may become clear • You do not currently an objective way of measuring the success or value of a release • You have a process but is rarely if ever applied Amadori Courses: Agile Demystified 35

07. Working software is the primary measure of progress. You will need to introduce and support such a process if Agile is to be successful Amadori Courses: Agile Demystified 36

08. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. 9 Questions currently is the workload of your project teams much heavier at some times than others? do your formally measure the workload of your staff from period to period? when are the periods of highest and lowest workload? does the additional effort required at peak times lead to a fall in efficiency and output once the peak is past? what steps do you take to address instances where individuals/teams' workload is significantly higher or lower than normal? when are the periods of highest and lowest workload? does the additional effort required at peak times lead to a fall in efficiency and output once the peak is past? is your capacity to deliver significantly impacted by staff holidays? is business support available throughout the year or are there periods where their priorities lie elsewhere (year end etc. ) Amadori Courses: Agile Demystified 37

08. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. In theory everyone should be in favour of a process which spreads work more evenly across the year In practice however there are organisations which confuse excessive hours with commitment and salary and bonus levels reflect this mindset In such cases Agile is unlikely to succeed without a change in the underlying company ethos Amadori Courses: Agile Demystified 38

09. Continuous attention to technical excellence and good design enhances agility. 4 questions do you currently review releases in terms of technical excellence and good design? if so, how do you measure these characteristics? what impact should good or bad scores in these reviews have upon the delivery process in the short term? what impact should good or bad scores in these reviews have upon the delivery process in the longer term? Amadori Courses: Agile Demystified 39

09. Continuous attention to technical excellence and good design enhances agility. It may well be that on reading these questions you realise that currently your organisation does none of this, or does so rarely and in the most ad-hoc fashion If so, you should focus on building the metrics and process to support such a process and then give them time to bed in BEFORE attempting to introduce Agile methods Amadori Courses: Agile Demystified 40

10. Simplicity--the art of maximizing the amount of work not done--is essential. 5 questions is this an aspect of delivery you measure at all recently? how do you/would you assess your releases in these terms? what impact should good or bad scores in these reviews have upon the delivery process in the short term? what impact should good or bad scores in these reviews have upon the delivery process in the longer term? how would you explain the importance of this concept to the business as a whole Amadori Courses: Agile Demystified 41

10. Simplicity--the art of maximizing the amount of work not done--is essential. As with the previous principle it may well be that on reading these questions you realise that currently your organisation does none of this, except in the most ad-hoc fashion If so, you should focus on building the metrics and process to support such a process and then give them time to bed in BEFORE attempting to introduce Agile methods Amadori Courses: Agile Demystified 42

11. The best architectures, requirements, and designs emerge from self-organizing teams. 11 questions currently who decides the overall scope of each release? currently who decides the detail of the requirements in it? currently who decides the detail of the systems architecture the release is delivered into? currently who decides the detail of the design by which agreed requirements are delivered? if these decisions are NOT currently under the direct control of the delivery team what issues might you expect should you attempt to devolve these decision making powers to the team? are the current members of the delivery team capable of making these decisions? are the current members of the delivery team willing to make these decisions? And accept responsibility for their outcome? do all members of the delivery team feel empowered to contribute to such discussions? If not what are the major obstacles here? do the same people fulfil the same roles in every project? Or are responsibilities assigned dependent on who is best qualified to carry out the role in that particular instance? does the team itself decide on what roles are required within the team or is resourcing manged externally? what sort of input does the delivery team have on salary and bonus levels and the career progression of its members? Amadori Courses: Agile Demystified 43

11. The best architectures, requirements, and designs emerge from self-organizing teams. Your answers to these questions will make clear whether you work for an organisation which would be 1. Happy to devolve decision making power to delivery teams 2. Would not be happy at the thought of doing this If you fall into the second category adoption of agile processes will succeed ONLY if preceded by a change in the company DNA in this area Amadori Courses: Agile Demystified 44

11. The best architectures, requirements, and designs emerge from self-organizing teams. Your answers to these questions will make clear whether you work for an organisation which would be 1. Happy to devolve decision making power to delivery teams 2. Would not be happy at the thought of doing this If you fall into the second category adoption of agile processes will succeed ONLY if preceded by a change in the company DNA in this area Amadori Courses: Agile Demystified 45

12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly 6 Questions does this sort of review occur currently? how seriously are the reviews taken? it doesn't what are the reasons for this? If it does, how honest is the review which follows? do you prepare a series of action points as a result of each review do you periodically review whether agreed action points have been put into effect and if so, whether they are delivering the benefits expected of them Amadori Courses: Agile Demystified 46

12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly As with principles 9 and 10 if your answers to these questions reveal that this sort of review does not currently take place within your organisation…. It once again probably makes sense to introduce this review process and allow it to bed in BEFORE you attempt to implement Agile in full Amadori Courses: Agile Demystified 47

Bringing it All Together In the final session of the course we will 1. Review everything we have learnt to date 2. Decide what this means in terms of Agile for your organisation/project 3. Provide you with solid and objective evidence to justify your decision Amadori Courses: Agile Demystified 48