# data[].attributes.body
-More flexible and adaptable projects
-Better response to changes in requirements

# data[].attributes.body
-Continuous customer involvement and feedback
-Higher customer satisfaction

# data[].attributes.body
-Focus on regular provision of functional software
-Reduction of the documentation effort

# data[].attributes.body
-More direct communication and collaboration
-Breaking down rigid hierarchies

# data[].attributes.body
Without documentation how is project intelligence past on to others, say for example a developer leaves with all the knowledge. Surely this is a big risk?

# data[].attributes.body
Being able to adapt is key in the digital world. Advancements are made all the time, changes occur regularly. Being too rigid to divert from the original plan could be shooting yourself in the foot. Those set in their ways will struggle with this.

# data[].attributes.body
Collaborating with the customer ensure the focus remains on the customers desired outcome, not an outcome that suits the company at a predetermined budget. Ensuring the dialogue remains open and a continual service improvement model is implemented, then close collaboration with the customer ensures there aren't any hidden surprises and that the work is completed to a satisfactory level. Those panicked by numbers, guidelines, specifics and SLAs over XLAs will find this way of working tough.

# data[].attributes.body
Comprehensive documentation is important to a point, but if it's causing analysis paralysis then it's no good. Getting a product or service out there is beneficial so that you learn as you go. I can see this being problematic for those with old-school mindsets though. Those that need extensive documentation, with every possible outcome accounted for, before they feel comfortable to move forward, will find this way of working challenging.

# data[].attributes.body
Prioritising Individuals and Interactions is key. That initial communication helps to identify the right processes and tools for the job. Because of this, I don't see it as being a problem, I see it as being common sense. If someone is adopting that level of communication and prioritisation for the first time, then perhaps it may come as somewhat of a surprise - i.e. a team or process is ready to get started in the way they are used to, but are delayed because there needs to be an initial discussion with additional stakeholders to identify whether or not the usual team are suitable for the needs of the upcoming project. I can't see this being too problematic though.

# data[].attributes.body
Without defining the final deliverables in the SoW, it may cause confusion/miscommunication around what is and isn't included in the initial scope agreed by the client. They may be reluctant to agree to a cost if they're unsure of exactly what they're going to get

# data[].attributes.body
May be a grey area if deliverables cannot be defined at stage of contract. It may mean that in the contract the amount or type of deliverables is outlined roughly, with them being subject to change.

# data[].attributes.headline
Adapting agile to non-software based jobs

# data[].attributes.subject
Adapting agile to non-software based jobs

# data[].attributes.headline
Some individuals may be resistant to change and find it hard to motivate themselves without a long list of predefined tasks 

# data[].attributes.subject
Some individuals may be resistant to change and find it hard to motivate themselves without a long list of predefined tasks 

# data[].attributes.headline
Bosses sometimes can't understand how to measure success with agile

# data[].attributes.subject
Bosses sometimes can't understand how to measure success with agile

# data[].attributes.body
I have experienced workplaces where line managers have to nail down exactly what you're meant to be doing every minute of the day in order to see if you're "succeeding". This is so not agile! I think a shift in management thinking is necessary to bring agile into the mainstream. A lot of people think it's just a buzzword or jargon for "flying by the seat of your pants"!

# data[].attributes.body
Interactions between individuals can in some organisations only be defined by the processes and tools they use. It's then tough to flip the focus and make the tools secondary

# data[].attributes.body
Management who continue to measure performance using the same old metrics which don't reflect how Agile changes the way in which the business delivers value.

# data[].attributes.body
I've worked as a BA for almost 5 years, and I've seen what good some changes will do to a project.

A positive changes are always needed, to prevent burnout and give new challenges to the team. But, not all team members are keen to welcome changes. Some of them are even skeptical because they want to keep "how it always have been".

# data[].attributes.headline
Collaborate with customers and making them part of the processes

# data[].attributes.subject
Collaborate with customers and making them part of the processes

# data[].attributes.body
I've been involved in countless projects in which we negoatiate the contract and work based on the contracts, and it costs us a lot when what written in the contract is binding us and the deadline cannot be negotiated especially when the technical issue arise.

It'll be difficult to educate both the management and the customers on how we will work together and what their role will be. Sometimes there are customers who takes over the role of the PM.

# data[].attributes.headline
Collaborate with customers and making them part of the processes

# data[].attributes.subject
Collaborate with customers and making them part of the processes

# data[].attributes.body
I've been involved in countless projects in which we negoatiate the contract and work based on the contracts instead of bringing the customer in and as an extended part of the team.

It'll be difficult to educate both the management and the customers on how we will work together and what their role will be. Sometimes there are customers who takes over the role of the PM.

# data[].attributes.body
Most of the organisation which are new to Agile methodology will need to remember that documentations are needed but not to the point that we have to waiting for all the documentations to be finished and signed off before we start with the planning/design/development.

Even if they manage to have a smooth transition, they still need to make sure that they won't be drifting back to old habits.

# data[].attributes.body
If the team members are used following certain processes and tools, it will take some time for them to adjust with Agile method.

Based on my experience, it can took up to a week just to explain to the team how it will work and how the interactions will play out if we're using Agile methodology.

# data[].attributes.body
It's challenging but everyone knows that during the project we can have changes and we should be ready for it. We have change log and assumption log. Before we start the project we also assume risks( known and unknown) which insure and gives us confidence.

# data[].attributes.body
Customers, stakeholders, sponsor and PM should have a discussion the project, its requirements and needs. Conflict can be according to Charter. Charter it's like <Power bottom> without it  they can't start a project. They should discuss every detail.

# data[].attributes.body
This can be especially difficult for the PM, as he is responsible for the success of the project.

# data[].attributes.body
Introducing Agile will arise such kind of problem if the team used to use another program. They have to adapt the new program , and it will take time. A simple example, when a programmer uses android,  and one day they decide to change computers and start working with ios.

# data[].attributes.body
some environments you legally need the documentation even in trial stages

# data[].attributes.body
Having a tool can clearly communicate to others that specifics have been discussed.. without this you will need to make sure the right conversations are happening at the right time so 'issues' are not missed.

# data[].attributes.body
An Agile project needs to have good communication with the project owner, to be able to gain trust on the team and trust that the product will meet the requirements of project, the client and the end users.

# data[].attributes.body
A lot of people have worked at my agency for over 20 years, whilst they have experienced much change I think for some this is a barrier. Therefore building in a process based on change could be a challenge.

# data[].attributes.body
At my agency, people often need 'proof' of what has been agreed which is largely recorded in tools and through documentation. More trust

# data[].attributes.body
Some projects may have specific requirements in place to comply with regulations or manage risk resulting in comprehensive documentation.

For example, designing a healthcare system for hospitals would require more QA and longer testing periods.

# data[].attributes.body
There may be resistance to new ideas, especially ones that impact the way we do work.

Acceptance of this idea would require trust and expertise from the individual(s) advocating for it. Potentially would have to come from senior level. For larger organisations this would require training and research.

In domains outside of technology the benefits for Agile ways of working are less clear and existing models of working have a stronger evidence base.

# data[].attributes.body
Getting capital expenditure signed off for major project work such as a new site would be challenging without comprehensive documentation and costs. There would need to be buy in and understanding from all stakeholders

# data[].attributes.body
Clients/accounts like to see written proof to refer back to

# data[].attributes.body
Every times has a certain way they work together and may not want to change it

# data[].attributes.headline
Project Team members and Stakeholders expectations of what will be documented and when - for example expecting a requirements document upfront before any development will begin.

# data[].attributes.subject
Project Team members and Stakeholders expectations of what will be documented and when - for example expecting a requirements document upfront before any development will begin.

# data[].attributes.headline
Governance and Assurance checks - peer reviews of work can be difficult due to the pace of the work and the 'agile' iterative documentation produced.

# data[].attributes.subject
Governance and Assurance checks - peer reviews of work can be difficult due to the pace of the work and the 'agile' iterative documentation produced.

# data[].attributes.headline
Some people on the project could have difficulties reversing this process if they've worked with processes and tools firstly as opposed to reversing their routine.

# data[].attributes.subject
Some people on the project could have difficulties reversing this process if they've worked with processes and tools firstly as opposed to reversing their routine.

# data[].attributes.body
When things change, colleagues or those within the project group may feel unease at the new direction, unless this is clearly outlined. Good communications and the setting of realistic expectations will be important.

# data[].attributes.headline
Unease from management at this new style of working

# data[].attributes.subject
Unease from management at this new style of working

# data[].attributes.body
Management, who are unfamiliar with agile, may feel nervous about an approach of this kind and may encourage employees to stick to their original methods of securing a clear contract with deadlines and financial costs outlined

# data[].attributes.headline
Could be challenging for those with a set way of working

# data[].attributes.subject
Could be challenging for those with a set way of working

# data[].attributes.body
Some individuals or teams may struggle to adapt to a new way of working and may feel challenged that their usual way of working has been changed. They may not understand the value of agile as they are in a mindset that their original working style was fit for purpose

# data[].attributes.headline
Procurement or Vendor management teams can be involved very early on at the level of client/provider relationship establishment and create a contractual agreement framework in case they worry about time/budget/scope 

# data[].attributes.subject
Procurement or Vendor management teams can be involved very early on at the level of client/provider relationship establishment and create a contractual agreement framework in case they worry about time/budget/scope 

# data[].attributes.headline
Changes can be the nature of the project so aversion to change is inexistent  and more room for innovation and progression is given to the project 

# data[].attributes.subject
Changes can be the nature of the project so aversion to change is inexistent  and more room for innovation and progression is given to the project 

# data[].attributes.headline
assigning a technical authority on the client side working closely with the project manager on the other side is very effective so both perspective and resources are aligned 

# data[].attributes.subject
assigning a technical authority on the client side working closely with the project manager on the other side is very effective so both perspective and resources are aligned 

# data[].attributes.headline
 A minimum acceptable version of the software should be negotiated, with minimum features comes minimum cost and minimum time, saving resources and progressing on alternative tasks

# data[].attributes.subject
 A minimum acceptable version of the software should be negotiated, with minimum features comes minimum cost and minimum time, saving resources and progressing on alternative tasks

# data[].attributes.headline
A workshop or project meeting to start describing the personas on the project is important to determine who are the individuals and the expectations on the outcome of the program or project 

# data[].attributes.subject
A workshop or project meeting to start describing the personas on the project is important to determine who are the individuals and the expectations on the outcome of the program or project 

# data[].attributes.headline
Revised Impact Assessments will be required as the scope of the project changes.

# data[].attributes.subject
Revised Impact Assessments will be required as the scope of the project changes.

# data[].attributes.headline
Proper Change Management processes and procedures are required, usually administered by a dedicated CM team.

# data[].attributes.subject
Proper Change Management processes and procedures are required, usually administered by a dedicated CM team.

# data[].attributes.headline
Processes and procedures will be minimal at first and expanded as and when the project advances.

# data[].attributes.subject
Processes and procedures will be minimal at first and expanded as and when the project advances.

# data[].attributes.headline
New team members may find it harder to get up to speed quickly and understand the product without proper documentation.

# data[].attributes.subject
New team members may find it harder to get up to speed quickly and understand the product without proper documentation.

# data[].attributes.body
Without a defined schedule of works to be attributed to a contract with a vendor, it can be difficult to ensure that what is delivered provides value for the money spent if, as per other comments, deliverables can't be included due to the nature of change.

# data[].attributes.body
Senior Leadership generally like to see a roadmap with defined project goals and financial costs against it, many aren't comfortable with the 'vagueness' of "at the end of X we'll have something of value".

# data[].attributes.body
Selling on a perceived future feature....defining an external roadmap for customers as the requests could change and be fluid.

# data[].attributes.body
Wihout any focus on process and tools any newcomers to the team during the project may have a steep learning curve to understand how and where to get things from.

# data[].attributes.body
How do you cost up a project accurately if you don't know how long it will take from not knowing what the deliverables might change to? Do you charge a set monthly fee?

# data[].attributes.body
You can spend too long focussing on one software increment i.e. the navigational wireframes of a website. Clients can get fixated by minutiae, forgetting the bigger picture, and before you know it weeks have past before you can sign this increment off.

# data[].attributes.body
Projects need documentation to handover to customers and other developers to support the work in the future. You have to focus on the software, but also document it as you go.

# data[].attributes.body
Customer may want a lot of features which end up taking a lot of time to explore and prioritise - thereby using time to discuss and put aside features that could have been used on developing essential items.

# data[].attributes.body
If there is a lot of change, but you have a fixed budget, you might not achieve enough to deliver the project.

# data[].attributes.body
Procurement

# data[].attributes.body
Management and some team members may feel the need for documentation, especially if they have a traditional project mgmt background (Prince2 etc.).

# data[].attributes.body
Might not be allowed to start the project until a contract is signed, and the contract might have to include a lot of fixed detail that could change during the project.

# data[].attributes.body
Management will worry that they have no control and might waste money if things change.