1      Executive summary

It is suggested that the agile implementation team be, first of all, agile in itself and that the agile implementation team follow a decision making model of:

1. Identifying discontinuing factors in the way of implementing agile,
2. Do an organisational level assessment of the possibility and how to implement agile in the organisation,
3. Do a project level assessment of the possibility and how to implement agile in the project, and
4. Reconciliation of how agile could be and possibly was implemented.

 Remember as with agile you need to start somewhere and produce business value at the end of every cycle.

2      Introduction

Agile is the new buzz word in the project management environment and in the organisation the writer works, this word is even used in the business sense at board level to say “our sales force must be agile”. Though not a lot of organisations actually know what agile project management is.

This paper will endeavour to formulate a decision making model to assess how ready the organisation is to adopt an agile project management approach.

3      What is Agile or Agility

Agility has been defined as “the power of moving quickly and easily; nimbleness” and “the ability to think and draw conclusions quickly; intellectual acuity” (Dictionary.com, n.d.). Note that definition does not state to get from point A to B but to move or change direction quickly. Many times an agile project is defined or thought to be one that get finished rapidly. The opposite of being agile is to be slow to change, clumsiness and being stiff (Larson & Larson, 2011).

The agile principle in general is there to reduce bureaucracy and manage expectations by facilitating collaboration between the development team and the business, transparency between all parties and quality of the outcome (Larson & Larson, 2011).

4      The four articles in the agile manifesto

There are four articles or phrases in the Agile manifesto and they are:

• We value individuals and interactions over processes and tools
• We value working software over comprehensive documentation
• We value customer collaboration over contract negotiations
• We value responding to change over following a plan

Note that these statements are each divided in a left side and a right side by the word “over” and many organisations make the mistake of thinking that the right side is of no importance, however this is not what agile state. Agile state that the importance of the right side is less than the left side. So agile state that people, working software, customer collaboration and responding to change is more important than processes and tools, comprehensive documentation, contract negotiations and following a plan (Larson & Larson, 2011).

5      The agile principles

5.1    Customer focus

• Produce customer satisfaction through early and continuous releases.

This does not mean release quickly or complete quickly but rather release smaller chunks of valuable code often. This will show the customer a return on investment much earlier than in traditional project management frameworks (Larson & Larson, 2011)

• Reduce release cycle times to a few weeks to a couple (two) of months.

This again give value to the customer much sooner and assist the development team in giving easily manageable chunks of work to them (Larson & Larson, 2011).

• Welcome change even late in development.

Agile harness change to the advantage and competitiveness of the customer. This mean the team should welcome change and manage it constructively (Larson & Larson, 2011).

• The organisation and the technical team must work together on a daily basis.

This indicate that no one is more important than the other and continual collaborative input is required form all parties (Larson & Larson, 2011).

• The best communication is face-to-face communication

It does not mean that other communication is not good or required but just that the best way to communicate is face to face, the organisation should think about co-locating the team either physical (the best way) or have the proper facilities in place like video conferencing (Miller, 2013/2) (Larson & Larson, 2011).

5.2    Quality

• Create a project environment around a motivated team.

Trust the team to get the job done. Trust motivate most individuals to work in a team and will more eagerly take ownership. When one take ownership one does the best one can do (Larson & Larson, 2011).

• The best output like design and architecture emerges from self-organising teams.

Teams that take ownership see what needs to be done and get the best solution out (Larson & Larson, 2011) (Miller, 2014).

• Progress is primarily measured against working software

Working software is better than a lengthy document describing how it should work and how the customer should interface with it (Larson & Larson, 2011).

• Quick and dirty is not the name of the game

Continuous focus on good design and technical excellence assist the ability to be agile (Larson & Larson, 2011).

• Focus on business value.

Prioritise everything according to business value. If a change does not provide business value then it is not getting done (Larson & Larson, 2011).

• Indefinite sustainability of development

Because the team maintain a shorter cycle it becomes easy to predict the amount of work that can be done in one cycle. This in turn assist the team not to go into heroic mode to try and finish the specification near the end and therefore prevent burnout (Larson & Larson, 2011).

• Moving towards perfection

The agile team reflect on lessons learned every now and then and fine tune their behaviour to become more efficient (Larson & Larson, 2011).

6      Questions found in the literature

This section will look at questions proposed in the literature to test the readiness of an organisation to see if the organisation is ready to fully adopt Agile.

Larson and Larson (2011) on the PMI website suggest the following seven questions:

1. Is the organisation willing to appoint a product owner?
2. Is the organisation willing to dedicate a full time team per product / project?
3. Is the organisation willing to have a dedicated business analyst to create requirements?
4. Is the organisation willing to have set timeframes that do not change?
5. Is the organisation willing to place the right competent people in the right roles (Miller, 2013/2)?
6. Is the organisation willing to breakdown silos and share information / fostering collaboration? This include collaboration between the customer and the agile team (Miller, 2012).
7. Is the organisation willing to apply the necessary discipline?

 One may consider four stages in the process to adopt agile. These may be referred to as identifying discontinuing factors, project level assessment, organisational assessment, and reconciliation (Sidky & Arthur, 2007, p. 6).

The following should be asked:

1. Will adopting agile have a real benefit?
2. Are there sufficient funds to implement agile?
3. Does top management really buy in to and support the agile way of doing things (Miller, 2013/1)?

If one look at the agile levels combined with the agile principles as captured by Sidky and Arthur (2007, p. 3) one could get to the following questions:

1. Is the organisation ready to adopt a highly collaborative state or is knowledge and information slow to flow through the organisation (Nanjundappa, 2012)?
2. Is the organisation willing to accept an evolutionary process of release early and release often or is the organisation dead-set on obtaining all functions on the first release? The organisation should understand that release early and often does not mean to release unstable solutions, the opposite is actually true. Each release should be technically 100% sound and stable. Release early and often rather refer to releasing smaller segments that is valuable to the customer.
3. Is the organisation ready to be more adaptive in their approach to solutions or are the organisation very rigid in its processes?
4. Is the organisation willing to be human centric and create a vibrant environment for agile to flourish?

 In most of the articles the writer red, it was clear that the organisation must understand what agile is about and that misconceptions must be removed before the organisation embarks on implementing agile whether it be for requirements gathering, development, project or business management or implementing agile in an eLearning environment (PWC, 2014) (Winner, 2015) (Sidky & Arthur, 2007) (Larson & Larson, 2011). It is therefore almost the main element in deciding if an organisation is ready to adopt agile. It would be a good idea to get all of the key players in the organisation on a training course on what agile is, not necessarily how to implement it but what agile is and what must be in-place before agile can be implemented (Miller, 2013/2) (Nanjundappa, 2012).

Kelly (2012) introduce more factors that play a role, things like:

1. Do the organisation or team that will be using agile have the right environment for example enough space for equipment like physical cork or white boards.
2. Does the organisation have any statistics on amount of bugs, speed of development, amount of work that can be done is a set amount of time, etc.
3. Do not try to implement agile alone unless you have a very strong agile leader, rather make use of a consultant that specialise in implementing agile.
4. Just like agile, you must start implementing agile and refining your implementation of agile.
5. Do not try to shove agile down the employees and organisation’s throat, rather enthuse and pull them into the mind-set of agile because if the team do not believe in agile it would be hard for the team to be successful (Miller, 2013/2).
6. Make sure everyone is clear on why agile is being implemented.
7. The organisation will have to implement the process of agile but also the technical side of agile, both are needed.
8. The organisation must make sure that the requirements are clear and clean this said the agile process allow for requirement incompleteness (Miller, 2013/2). The difference is that the so called cycle or sprint requirements that should be fulfilled should be clear but the end goal requirements may be vague.
9. The organisation will have to make structural changes, this is for instance a team should have all the people they need, UI developer as well as DB developer, BA as well as the product owner or client representative. Therefore functional teams are of very little use in an agile environment.

7      Proposed decision making model

According to the literature the thought behind agile is to have the ability to adapt and change rapidly. It is therefore suggested that the implementation of agile should be approached in an agile way. This is that the direction and journey of implementing agile must be adaptable to fit the environment and that change may occur while implementing agile (Roux, 2015).

7.1    Phase or cycle one

Let’s call the person that would like to implement agile in the organisation the product owner.

The product owner should be the first one that go for a proper training course to understand what agile is all about. Once the product owner has a proper grasp on all the terms, articles, processes, etc. he may proceed. At this stage it is advisable not to get an external person as the internal person knows the organisation the best.

Next the product owner should note down all barriers to implement agile in the organisation, these may be as stated above, the organisation may have a strong silo based environment, not enough funds, etc. True to agile this does not need to be a full list but should be fairly extensive. The writer suggest the following main questions to assist the product owner to fill in the obstacle table:

1. Will top management support the change to a way of doing things that will support quality and prove business value earlier rather than later?
2. What are the education levels of employees around agile?
3. Does the organisation have available funds to support the implementation of agile?
4. Does information and knowledge flow easily through the organisation?
5. Are there any regulatory objects that might constrain the implementation of agile?
6. Will the implementation of agile have a real positive impact on the organisation?
7. What might be the human resources barriers? For example do the organisation have a strict functional team model or more a matrix management model, ?

Once the list is compiled the product owner should investigate if any of these obstacles cannot be solved or if it can be solved, how. Refer to table 1 below for an example. If most of the barriers can be overcome then proceed with the implementation but if there are critical obstacles that cannot be overcome then it is advisable to rather not continue with the implementation. It is important for the product owner to keep a realistic and objective view during the first stage and should have a second or even a third employee to bounce these ideas off to make sure the project can succeed.

7.2    Phase or cycle two

Cycle two is about training, though remember that agile is about producing quality work and therefore it is suggested that phase two should not be started too soon, though it might be a good idea to start the training process earlier rather than later. The more employees get trained the better, and phase one may have to go for another cycle as new trained employees get on-board. Also start with the key individuals of the organisation. The product owner will need all the support he can get.

As the agile implementation team grow they should entice and draw the rest of the business into this “new” concept. This could be done by “selling” the benefits of agile to the business in normal day conversations during lunch, tea times, etc. Do not get discourage if you find resistance. Remember resistance to change is normal yet futile as long as the team has strong support from top management. Also remember that implementing agile should be agile in itself, embrace resistance and find a solution – be agile, change the journey, you only need to do short cycles that prove business value.

7.3    Phase or cycle three

This cycle is where the major implementation of agile start and it is at this stage that the writer suggest to bring in an external consultant.

The agile implementation team should be at a point where most of the barriers to implementation have been noted and very possible already overcame some of them. Most of the key individuals of the organisation would have been trained on agile and at this point everyone should be on-board why the organisation would like to implement agile.

At this cycle the team and external consultant should reflect on what has been done on the agile implementation project.

Reflect and potentially do another cycle on identifying discontinuing factors, project level assessment, and organisational assessment.

Again do not get discourage if the agile implementation need to adapt or shift course, remember agile embrace change. Reflect on how far the team came up to now. Celebrate the successes and take courage for the full implementation of agile.

7.4    Phase or cycle four

This is the reconciliation cycle. Look back at the lessons learned. Make sure to keep on encouraging the multiple agile teams to celebrate successes, learn from both successes and failures and continually adapt to perform better and faster.

And lastly but maybe even more importantly the agile implementation team should also do the fourth cycle and ask: “How can we adapt our agile implementation to be better and faster?” and then…

Start the next cycle.

8      Bibliography

Dictionary.com, n.d. Agility. [Online]
Available at: http://dictionary.reference.com/browse/agility?s=t
[Accessed 31 08 2015].

Kelly, A., 2012. My 10 things for making your Agile adoption successful. [Online]
Available at: http://www.infoq.com/articles/ten-things-agile-adoption
[Accessed 03 09 2015].

Larson , E. & Larson, R., 2011. Seven questions to ask to determine if your organization is agile ready. [Online]
Available at: http://www.pmi.org/learning/determine-organization-agile-scrum-ready-6129
[Accessed 31 08 2015].

Miller, S., 2012. Is Your Organization Ready for Agile?. [Online]
Available at: http://insights.sei.cmu.edu/sei_blog/2012/10/readiness-fit-analysis.html
[Accessed 04 09 2015].

Miller, S., 2013/1. Mitigating Agile Adoption Risks: Organization Climate. [Online]
Available at: http://insights.sei.cmu.edu/sei_blog/2013/03/mitigating-agile-adoption-risks-organization-climate.html
[Accessed 04 09 2015].

Miller, S., 2013/2. Is Your Organization Ready for Agile?. [Online]
Available at: https://insights.sei.cmu.edu/sei_blog/2013/12/is-your-organization-ready-for-agile-1.html
[Accessed 04 09 2015].

Miller, S., 2014. Is Your Organization Ready for Agile?. [Online]
Available at: https://insights.sei.cmu.edu/sei_blog/2014/06/is-your-organization-ready-for-agile.html
[Accessed 04 09 2015].

Nanjundappa, N., 2012. 12 Questions to Ask Your Organization About Agile Adoption. [Online]
Available at: http://www.solutionsiq.com/12-questions-to-ask-your-organization-about-agile-adoption/
[Accessed 04 09 2015].

PWC, 2014. Adopting an Agile methodology: Requirements gathering and deliv. [Online]
Available at: https://www.pwc.com/en_US/us/insurance/publications/assets/pwc-adopting-agile-methodology.pdf
[Accessed 03 09 2015].

Roux, D., 2015. Agile a way of thinking. Pretoria: s.n.

Sidky, A. & Arthur, J., 2007. A Disciplined Approach to Adopting Agile Practices: The Agile Adoption Framework. [Online]
Available at: http://arxiv.org/ftp/arxiv/papers/0704/0704.1294.pdf
[Accessed 03 09 2015].

Winner, A., 2015. Adopting Agile Approach For eLearning Development In Your Organization. [Online]
Available at: http://elearningindustry.com/adopting-agile-approach-for-elearning-development-organization
[Accessed 03 09 2015].