Practical IT Research that Drives Measurable Results Understand the Impact of Going Agile.

Practical IT Research that Drives Measurable Results

Understand the Impact of Going Agile

Agile Development: Don’t Be Led Astray!

Info-Tech Research Group 2

The Agile Software Development Methodology has become very vogue. If you’re not doing it, you are probably being told you should be!

Development leaders are jumping on the Agile bandwagon in droves based on the promise of success; shorter timelines, higher productivity, and greater client satisfaction – but are they really getting everything that has been promised?

Use this research to gain an understanding of what Agile means for your enterprise. Discover why so many are seeing some success with their projects, while so many others are

quietly regretting their decision to Go Agile!

You should read this if you are a:

Business or IT & Development leader responsible for running development-related projects

Leader who made the leap to Agile Development, but has encountered issues with the process

Leader who simply wants to be more agile in their approach and/or responsive to the business and client requirements asked of development

Anyone who wants to hear the “other” side of the story

This research will enable you to:

Know what changes are needed in your organization to make true Agile work

Understand how adopting Agile will impact your business culture

Develop processes to enable successful implementation

Executive Summary


Agile has become synonymous with success … but is it?

This isn’t StarWars, using force won’t make it work

Going Agile is supposed to make things better, it is supposed to streamline your development efforts, it is supposed to make your clients happier, it is supposed to make your developers happier.

Agile is not for every business. Agile is not for every project. Agile is not for every development team. Businesses need to stop trying to force this square peg into round holes …. It simply may not fit, and that’s OK.

IT leaders are feeling pressure to switch their software development methodology over to an Agile format.

Agile development methods can provide benefits to your development process, but you need to try and implement correctly to avoid major problems.

Agile development methods can potentially decrease your responsiveness, negatively impact developer morale, and lead to implementation of counter-productive practices.

When implementing Agile methods, IT leaders must focus on incorporating agility in the development structure and not simply try to fit their organization into the Agile paradigm.

This solution set provides the strategic advice you need to avoid pitfalls associated with Agile development and adapt the agility practices, that are the real source of benefits, into development teams, and drastically improve your responsiveness while maintaining a positive working environment.

The HypeThe Hype

Roadmap

The Solution The Reality Appendix

So you are sold on the benefits of Agile… what are they again?

• The Agile process: its principles and methods.

• What the hype is all about.

• The potential benefits of an Agile development approach.

1

Agile 101: Understand the basics behind Agile development

1. The users are involved throughout the process.

2. The team is empowered and allowed to make decisions.

3. While requirements evolve, timelines and timescales are fixed.

4. All requirements are captured only at a high level, are lightweight, and are generally visually represented.

5. Development proceeds in small incremental steps, each has a release at the end.

High-level overview of true Agile practices:

5Info-Tech Research Group

6. General focus is always on the frequent delivery of products.

7. At the end of each sprint (iteration), every feature included is complete.

8. The 80/20 rule is always applied; the focus is on the important 20% that will drive the majority of the results.

9. Testing is implemented throughout the lifecycle. Testing is done early and often.

10. All interactions of the team and stakeholders are collaborative and cooperative.

Agile promises a faster return on investment through shorter cycles; quicker to market; and faster resolution of

issuesShorter Cycles

By breaking the project down into sprints, the project cycles are shorter and eliminate the stressful looming release date. The quicker cycles keep the developers fresh by providing more lightweight workloads.

Quicker to MarketEach sprint should produce a deliverable to the client. As a result the development team should put out product more quickly and the end product should be finalized at an earlier date.

Faster Resolution of IssuesHaving the client involved throughout the process, issues should come up more quickly and as a result be resolved earlier in the process. Getting feedback every 2-3 weeks instead of every 6-8 months would allow for quicker issue resolution.

Investment Benefits Attributable to Agile Development Methodology

N = 4,232 Source: Ambler, 2006.

Make sure each cycle produces some feature for the client; don’t fall into the trap of going too lightweight.

Info-Tech Insight:

ReducedCosts

66%

Faster Timeto Market

83%

ReducedDefects

85%

Productivity

90%

Percentage Increase Reported with Agile

Agile is not only good for the developers, but its good for the business too… Frequent delivery means frequent

paydaysRequiremen

tsAnalysis

Specifications

DesignCoding

TestingDeploy

Waterfall Methodology

Agile Methodology

In Agile, the end of every cycle has a deliverable. That means money starts coming in early and more often.

Waterfall has the payday at the end, when the final product is delivered. If something goes wrong and the end product isn’t delivered, guess what? No money!

Even from a sales point of view, Agile makes good business sense. Faster and more frequent delivery brings money in sooner and on a more steady basis.

Info-Tech Insight:

Agile promises increased client confidence by improving productivity; quality, and client satisfaction

Higher ProductivityPart of the Agile methodology is to deliver something after each short cycle, and as a result, usable code should be produced at a higher rate.

Higher QualityOne of the key principles for Agile is to test early and test often, this is intended to allow for a higher quality product being delivered to the clients.

Higher Client SatisfactionBy having the client involved throughout the process, issues come up more quickly and are resolved earlier in the process. This increases the likelihood that the end-product will be consistent with the customers’ needs. The people oriented philosophy of Agile places high value on the clients. N = 1500 Source: VersionOne, 2007

Get your clients involved throughout the development process. It will increase the likelihood of achieving these project benefits.

Info-Tech Insight:

Customer Satisfaction

38%

Cost Reduction

44%

Quality

44%

Production

44%

Factors That Increase Likelihood of Higher Client Confidence

Percentage Increase Reported with Agile

Sprint

Sprint

Executing agile will increase customer satisfaction

What the customer would, in the end,

like to have


like to have

What the initial plan estimated the

customer would like


customer would like


like to have


like to have


customer would like


customer would like

In a non-agile world where the “plan” is the most important thing

Following an agile approach with adaptive planning and frequent delivery

Delivery

Delivery

Measure of customer

dissatisfaction

Time

Time

Non-Agile development methods have a far off goal and deadline. Unfortunately, by the time that deadline comes, often the customers’ needs have changed and the end product falls short. The customer is unhappy with what is delivered and the developers feel that their efforts were wasted.

At the end of each of the sprints, changes due to altering customer needs can be addressed. This should result in the final product hitting the mark despite the shift in what the customer would like to have. The congruence between product delivered and customer need should result in higher customer satisfaction using Agile.

Sprint

Sprint

Non-Agile

Agile

Make sure you incorporate testing into the planning of each sprint, if you leave testing until later you are setting yourself up to fall short of the final target.

Info-Tech Insight:

Agile promises happier developers by giving them more autonomy; diversity; and lightweight loads

More AutonomyAgile development is supposed to give the power to select what needs done and deciding how long it will take into the hands of the development team.

More DiversityDue to the shorter cycles and theoretically the shorter projects, the developers should get to work on different tasks more often, rather than plowing away at the same larger task for longer periods of time.

More LightweightAgile is supposed to segment work into lightweight sections that developers find easier to manage and less stressful. Agile promises a relief from the heavy workload associated with other traditional methods.

Agile Methodology Shows the Greatest Impact on Developer Motivation

+55%

40%

Traditional

38%

Agile Combination

62%

40%

No FormalStructure

N= 670 Source: Freeform Dynamics, 2008

When using the Agile process, you will make quicker decisions based on actual needs, rather than traditional project methodology.

Info-Tech Insight:

Development Methodology Used

Agile promises better communication with more face-to-face; feedback, and collaboration

More Face-to-Face The principles of Agile state that daily meetings should be done face-to-face with the other team members. This should allow for great feedback and a greater sense of collaboration.

More FeedbackDue to the daily meetings, feedback should be provided more frequently and efficiently compared to traditional methods. Inclusion of the client throughout the process should give the developers fewer deadline surprises.

More CollaborationAgile demands that team members constantly collaborate through practices such as pair programming. The practices of Agile are supposed to lead to a “people-centric” development department.

Agile Methodology Scores Highest on Level of Team Communication

Traditional

48%

Combination

57%

No Formal Structure

60%

Agile

67%

N = 670. Source: Freeform Dynamics, 2008

Agile itself won’t make your team instantly better communicators. It will facilitate a better approach, but you still need to make sure they know how.

Info-Tech Insight:

Development Methodology Used

Don’t adapt agile because you think everyone else is…Agile isn’t as prevailing as the “hype” makes it out to be

40% 12%17%

20%23%

28%

A 2008 survey found that 60% of respondents considered themselves Agile. By contrast, a recent Info-Tech survey found that only 23% of respondents consider themselves Agile while 28% consider themselves variable. The trend seems to be the abandonment of Agile as an overarching philosophy in favor of Agile as a project-based methodology.

% Using Agile Methods % Using Agile Methods

Development Methodology Development Methodology

“Variable” depending upon project is actually

the more popular choice

The likely cause of these differences revolves around companies either implementing only some Agile practices or implementing them only on a project by project basis.

Info-Tech Insight:

60%

40%

N = 106 Source: ITRGN = 3000 Source: Version One 2008

The RealityThe Reality

Roadmap

The Solution The Hype Appendix

Your teams are following the Agile methodology… or are they?

• What is really happening out there with Agile?

• What are the mistakes that organizations are making with Agile?

• Case studies of companies who misstep when going Agile.

2

Organizations make 3 key mistakes when going Agile, thereby eliminating the potential benefits that Agile

offers

1. Management fails to transition to their new role

“A lot of managers like to be hands-on, whether in the details, or the direction of tasks… this doesn’t bode well for Agile teams. Managers need to focus on support.”

~Software Developer

2. Clients don’t get involved in the new process

“Clients often know (or think they know) what they want, and don’t want to hear from you

until you can give them what they asked for.”

~IT Manager

3. The developers can’t work in autonomous, self-directed

teams“Many developers have never had to make

critical decisions and so they don’t know how to without management assisting and

this completes the circle of bad agile practices.”

~IT Manager

Agile is not a “Silver Bullet” – Mistakes happen

(1) 40% of Agile developers still don’t see themselves as having a good relationship with management. (2) 56% of defects are said to result from missing requirements that could have been delivered by client communications. (3) Only 43% of developers reported feeling empowered to manage workload and task assignment in Agile .

3. Empowered1. Poor Relationship 2. Defects

40%

56%

43%

N= 670 Source: Freeform Dynamics, 2008

Mistake #1: Management is unable to transition to their new role

• Managers whose previous roles involved a high degree of control over direct reports often find the transition to an Agile environment stressful. They may have difficulty allowing teams to self-direct.

• As soon as an issue arises, the management team defaults to their old style and gets involved where they shouldn’t.

• It is often hard to tell micromanagers that they are being less than helpful. The chart on the right shows how ineffective they can be.

• If management starts to micromanage, developers will revolt, resulting in decreased productivity, lower morale and poor client satisfaction.

Many Managers find it difficult to take a “hands-off” approach

% of Developers that agree with the statement:“We deliver software on time and on budget.”

26%

53%

Hands-Off Management

Hands-On Management

“Hands-Off Managers” Are More Often On Time and On Budget

Convincing management to be more supportive, rather than directive, is critical to the success of Agile teams.

Info-Tech Insight:

N = 670: Source: Freeform Dynamics, 2008

A company’s failure to transition management intotheir new role


Industry: TechnologySegment: Medium EnterpriseSource: Information Technology Executive

Situation

• Company A, due to pressure from the CIO decided to switch over to an Agile methodology.

• The CIO brought in an Agile consultant for a two day workshop to “train” the development department.

Mistake

• The company took the ideas of daily meetings and short cycles, but failed to also bring in the changes to management’s role that are key components of Agile methods.

• Management maintained their explicit control over what gets done and also has a presence at the daily meetings

• Company A has implemented a culture of micromanagement.

• The managers increase their workload by constantly overseeing all the work being done and determining who is working on what.

• The developers feel like management is always looking over their shoulder and also feel they don’t trust the developers to do their job.

Results

A good manager will recognize the differences in how people work, and enable them to work that way.

“ “

-Software Developer

Mistake #2: Organizations fail to include their clients in switching over to Agile

• Many organizations, when implementing Agile methodology, fail to inform and include their clients in the new process.

• Often clients hear that their development team is switching over to Agile and they think “great, I hear good things!” “We will get deliverables more quickly and with less bugs.”

• However, in many cases it is not made clear to them that a switch to Agile development causes changes to their own responsibilities during the project life-cycle.

• Without being involved in the entire process, the clients will not be able to give feedback to the developers. The clients will not be able to receive updates on the changes that will occur, and likely won’t receive the final product that they were expecting.

% of Costs Spent on Fixing Defects

18%

82%

Requirement Related

Others

In Agile, the Majority of Defect Costs Come From a Lack of Client Requirement Input

An important factor regarding client’s trust is that if your client (or client representative) is not attending sprint review meetings with you, this is NOT Agile development at all.

Info-Tech Insight:

N = 670: Source: Freeform Dynamics, 2008

A company’s failure to involve their clients inthe new Agile process


Industry: : EducationSegment: Medium EnterpriseSource: Information Technology Manager

Situation

• Company B felt a lot of pressure from their development team to switch over to an Agile methodology.

• The company did a good job of getting their management and development teams up to speed with the changes that were coming.

Mistake

• However, they failed to fully explain to their clients that their feedback was needed throughout the development process.

• The clients not only were not fully aware of their new role but were unwilling/unable to take on that new role in the project life-cycle.

• As a result, the consistent client feedback, which is vital to Agile methodology working successfully, was not available.

• The bugs or changes that always appear during and after the sprints are not handled fully and the end product is not what the client really wants.

• There is a failure to keep the development team and the clients on the same page.

Results

Clients that embrace involvement in projects see the benefits first hand by being involved at every step of their project.

“ “

-Software Developer

Mistake #3: Organizations fail to recognize they have the wrong developers for an Agile environment

• An Agile methodology demands a lot of teamwork and collaboration. Developers often would rather work by themselves, but because it is such a big part of Agile often developers say they are good at teamwork.

• In Agile, developers are given more decision-making responsibilities. Therefore, the direction of the development team should fall on the developers’ shoulders. They must be able to carry that weight in order for Agile practices to work successfully.

• Organizations often fail to recognize that developers on an Agile team need both technical and personal skills. The personal skills could be considered even more important since in the end, they will be the real difference makers in an Agile environment.

Political IssuesSoftware QualityCollaboration Challenges

88%

64%50%

Agile Developers Still See Collaboration as the Main Challenge

N = 670; Source: Freeform Dynamics, 2008

Don’t be surprised if developers bristle at first mention of Agile. Most developers really enjoy programming but find explaining what they are doing as a distraction from coding.

Info-Tech Insight:

A company’s failure to realize they have thewrong developers for an Agile environment


Industry: : FinancialSegment: Large EnterpriseSource: Information Technology Manager

Situation

• Company C succumbed to external and internal pressure to go Agile.

• The company brought in an Agile consultant to “train” the development team on the important principles of Agile.

Mistake

• Company C failed to recognize that their culture was in no way a collaborative one.

• Failure to recognize this has created a development team made up of individuals that can’t handle being autonomous and self-directed.

• As a result, infighting within the development team arose.

• The collaborative culture that must be in place for Agile to work is missing and daily meetings have become daily airing of grievances.

• This has resulted in low developer morale and low levels of productivity due to the inability to successfully check each others work.

Results

Agile development helps, if properly implemented, because it brings the teams closer together, but some developers really struggle with that type of structure.

“ “

-Software Developer

The Solution

The Solution

Roadmap

The Hype The Reality Appendix

Agile isn’t for everyone, don’t make the wrong choice

• Arm yourself with the right information to know if Agile is right for you.

• Know the Do’s and Don’ts that will guide you to successful implementation.

• Find out what areas need to be focused on during transition.

3

Use Info-Tech’s Agile Readiness Assessment Tool to help identify whether you & your team are ready for Agile


This is a diagnostic tool to help gain visibility into the current state of your organization. See if you have the right conditions to make the

switch to Agile.

The Agile Readiness Assessment is a diagnostic tool that helps IT/Development managers gain visibility into the state of their development, and how ready they are to make the shift to Agile. The questionnaire targets critical categories that track the necessary requirements for basic success. Follow the diagnosis analysis that corresponds with your score.

Download theAgile Readiness Assessment Tool

http://www.infotech.com/research/it-agile-readiness-assessment-tool

Flipping everything upside down for agile means more than just adjusting your project methodology, it includes

management too

Tasks directed

from above

Tasks directed

from above

Tasks determined by the

team

Tasks determined by the

team

Waterfall

Agile

MANAGEMENT

MANAGEMENTPROJECT RESOURCES

PROJECT RESOURCES

The staff have been hired because they have the necessary skills to do their jobs, the managers can serve best when they provide the tools the team requires, and remove obstacles that slow them down.

“ “

-Former Professional Services Manager

When you flip your world upside down, and provide your teams with increased ownership, you will receive in return higher productivity and superior quality.

Increasing ownership over

product delivered

Managers need to balance their role in supporting the team with constraints imposed from the organization. Policies and governance are still critical and cannot be ignored.

Info-Tech Insight:

Focus on team collaboration, flexibility, and the delivery of value to your clients when running agile

Plan DrivenPlan

Driven

Value DrivenValue Driven

Waterfall

Agile

fixed REQUIREMENTS

RESOURCES TIME

FEATURESRESOURCES TIMEestimated

The fixed plan creates

cost/schedule estimates

Releases & resourcing drive feature estimates

In order to manage “the plan”, waterfall demands tight control over schedule and scope. In contrast, Agile turns it all upside down and focuses on collaboration and delivered value.

Info-Tech Insight:

Delay meetings if someone cannot attend. Hold the meeting anyway.

Take on clients that are unable to attend meetings due to distance or time differences.

Allow management to be a team member or attend daily meetings.

Try to juggle both the manager and developer roles. It makes it difficult to for team members to know their place.

Emphasize good, frequent, and quality communication amongst all team members.

Encourage everyone on the team to look at each other as equals - there is no hierarchy in Agile teams.

Locate the agile team at the same physical location - within close proximity if possible. This helps to foster constant communication.

Co-locate your team for optimal results:Or your team will get lost in transition

xx

xxAgile projects with co-located teams are more successful on average than distributed teams. The number of High Success increases by 63% for co-located teams. The number of Low Success projects increases by 183% if the team is distributed.

xx

xx

32

52

30 28

9

21

48

Co-Located

Distributed

+183%

+63%

Low Success

17

6

Average Success

2830

High Success

32

52

N = 781; Source: Ambler, 2007

Avoid letting this happen…

Focus your attention on doing this…

Level of Project Success

Make the client aware of the need for their participation throughout the project. Changes occur quickly and often in an Agile environment.

Ensure the team always has someone speaking on behalf of the client. They will take on all responsibility and accountability. If the team needs information and the representative can’t supply it, then they must get it.

Turn to the client for information and feedback to assist your developers in arriving at the best-fit solution.

Provide progress updates when project milestones are reached.


Allow the clients to have a “You guys know what you are doing, just do it.” type of attitude if you are going Agile with their projects.

Allow the client to think that completed, tested and functional sprints are intended to be small substitutable chunks for a completed project. IT knows it still needs an end product and the clients needs to provide input to do that.

Expect the clients to come up with solutions – that’s what they’ve come to you for.

Don’t burden the clients with the minute details of the project.

Ensure a client presence throughout the project lifecycle

xx

xx

xx

xx


“Look, I have four different consultants doing different things for me right now, designing different parts of the system or different systems. I don’t have time to be in the weeds of every one

of those, that’s why I hired all the consultants. I want to be involved, I want to be consulted if a decision needs to be made, but I don’t want to be bothered with the day to day… you know what

you need to do, you are the experts right?” ~Small Retail E-commerce Business

Make the plans have just enough information to get to the next level of the project, not a complete work breakdown structure before development has begun.

Have the manager emulate this behavior by creating project plans the same way. This lets everyone know this type of planning needs to be established by all team members.

Provide just enough coding to demonstrate the current feature to the client and verify to them that the team is on schedule.

Keep the level of expectations high enough to facilitate a moderate level of urgency. Despite the lack of documentation, it has to be reinforced that each feature delivery is vitally important.


Try and identify all features and then specify their requirements.

Worry if you can’t identify every possible question in the specification.

Settle for “just good enough”, make sure you can show the value of the feature to the customer and verify that you are still on track.

Don’t get stuck in your previous habits of the traditional planning. If you do, you won’t be able to handle the changes that come up.

Clearly define & implement “Just Enough” practices:But “Just Good Enough” is NOT acceptable

xx

xx

xx

xx


“This is one of the hardest habits to break with a traditional team and the Agile manager needs to champion this mentality on a daily basis.”

~Software Developer

Move from solitary development attitudes to team attitudes by implementing team building exercises with the developers.

Transition from a non-customer-centric attitude to a customer-centric attitude by letting the development teams know that customer involvement is a key to success.

Move from a contract-compliant attitude within the organization to a change-tolerant attitude by being positive about changes that arise and accepting them as just part of the process.

Hire developers who have shown the ability to learn new skills, adapt to changing situations and apply acquired skills in new ways. This will serve you well in Agile as much as strong technical skills will.


Assume that your developers know how to collaborate. Many developers may not be naturally good at this.

Worry if communication during meetings is strained at first. Developers and open communications often take some time.

Expect everyone to jump on board initially. The hardest thing for people to do is change, don’t expect these changes to occur overnight.

Panic as individuals start to establish themselves as leaders within the development group. Leadership is ok, dictatorship is not.

Create a collaborative culture within your development team:

Without it Agile becomes Fragile!

xx

xx

xx

xx


“Migrating to Agile is more than changing your process. It also requires a change in culture. For most companies changing culture is the most

difficult part.” ~IT Manager, former Software Developer

Make the first Agile project a small one so people can learn the process under less pressure than a large project can produce.

Ensure the team isn’t overwhelmed with expectations. The team might feel that this is the new method and they have to ensure it will work.

Turn the first project into a pilot project, eliminating the additional pressures that come with implementing a new developing methodology.

Provide the Agile team with the knowledge that you are going to take this process slow and you hope to see some positive aspects, not a solution to all existing issues.


Allow the Agile mentality to immediately take over the organization.

Put Agile methods in practice across the board on all projects. Start small or chaos will ensue.

Expect the results and benefits to show themselves right away, Agile takes time and training, don’t expect the first few projects to run without transitional hiccups.

Don’t burden the development team with the expectation that this is the new method that will solve all of the organization’s issues.

Avoid going too big too fast in your transition to Agile

xx

xx

xx

xx


“We have a small team of developers, it just made sense for us to pick a small project to see if Agile would work for us. It was clear that for some projects Agile would be beneficial, but for others it just wouldn’t make

sense.” ~IT Manager - Medium Educational Institute

Deal with team members who don’t pull their weight. Agile practices will shed light on individuals who try to slack, you have to fix that issue or teams will breakdown.

Monitor how management deals with the constant changes that come with Agile. Get feedback from them and the development team about how managers are handling the change. You may find some just can’t work in an Agile environment.

Find out which developers specialize in what areas and allow them to work outside of those areas. Build a team of multi-skilled developers to ensure that fewer “bottlenecks” occur.

Provide the team with the opportunity to learn new skills while on a project. This novelty will increase morale and help widen your developers’ skill set.

Avoid letting this happen …

Fail to evaluate the strengths and weaknesses of your team members. Knowing who is skilled in what areas will help you avoid developers getting stuck with the same tasks over and over.

Fail to identify the solitude seeking developers on staff because they will poison your teams. Identify who these individuals are through team exercises and train that out of them or move them to a non-Agile project.

Allow teams to become reliant on specialists. Know who your specialists are and monitor the workload of their team members.

Just evaluate the developers collaborative skills. Managers in Agile have to be good at collaboration as well. Include them in team skill training.

Evaluate staff to see how they mesh with Agile methods

xx

xx

xx

xx

Focus your attention on doing this …

“Even though we get to select what we work on everyday, I always end up with the same type of task because I am the one who is good at it. Sometimes I would really like to try my hand at something new.”

~Software Developer from an “Agile” team

Summary

• Agile is great in theory and it promises many key benefits, but in practice Agile is not for everyone.

• Agile is a people-oriented methodology and as such can raise a lot of people-oriented issues.

• Be prepared for an overhaul of management’s activities and attitudes; the whole management system will need to be turned on its head.

• In Agile, the developers will also find themselves in decision-making roles they may have never been in before, prepare them for it and don’t be surprised by some initial developer backlash.

• Agile will raise a lot of new process impediments, you must be willing to remove these as they arise and be patient in your expectations.

• Your clients will see significant benefits when you use Agile, but like other people involved, their roles will change. You must have client involvement throughout the Agile project lifecycle, even if it is by having a client representative present.

• Arguably the best advice we can give you is: go slow! Agile takes time and may not be suitable for every project. Start small and then grow as your teams get the hang of it.

• Agile development can be successful in a collaborative culture that embraces change, if you don’t have that or can’t transition to that, don’t force Agile onto your development team.Info-Tech Research Group 31

Appendix: Implementing Agile Development Survey Results


Practical IT Research that Drives Measurable Results Understand the Impact of Going Agile.

Documents

Transcript of Practical IT Research that Drives Measurable Results Understand the Impact of Going Agile.