Agile and the Knowledge and Skills : Level 3

novembre 26, 2015

Agile and the Knowledge and Skills : Level 3

The Knowledge and Skills at the Level 2 are :

 – Agile contracting methods

– Agile project accounting principles

– Applying new Agile practices

– Compliance (organization)

– Control limits for Agile projects

– Failure modes and alternatives

– Globalization, culture, and team diversity

– Innovation games

–  Principles of systems thinking (e.g., complex, adaptive, chaos)

– Regulatory compliance

– Variance and trend analysis

– Variations in Agile methods and approaches

– Vendor management

Agile contracting methods

– Contracts

Contracts suited for agile include: general service for the initial phase with fixed-price contracts for successive phases; cost-reimbursable/time and materials; not-to-exceed with fixed-fee; and a combination with incentives. [Agile Software Development: The Cooperative Game – 2nd Edition. Alistair Cockburn.]

Fixed-price contracts

Fixed-price contracts, although typical of traditional projects where scope is defined ahead of time, are not well suited for agile. When scope is fixed it can deter a team from exploring out-of-scope solutions that may add value to the product. Contracts suited for agile include: general service for the initial phase with fixed-price contracts for successive phases; cost-reimbursable/time and materials; not-to-exceed with fixed-fee; and a combination with incentives. [Agile Software Development: The Cooperative Game – 2nd Edition. Alistair Cockburn.]

Fixed-budget and fixed-schedule is a good agile contract

Budget and time

Time, budget, and cost estimation is an important knowledge and skill area of agile. According to Highsmith, the nature of the agile method, whereby it welcomes changing scope, means that it lends itself well to fixed budgets and a fixed schedule because changing scope makes it difficult to estimate a total cost. Generally speaking, the budget and schedule constraints are known but before a project will commence there needs to be an agreed upon set of base product functionality defined in an initiation phase; fixing scope reduces an agile team’s innovative tendency to provide improved value. For companies that are familiar with fixed-price contracts, where requirements are agreed upon before contract closing, adopting agile can be a weary initial venture. Instead, other contract vehicle types are recommended for agile efforts. These include: a general service contract for the initiation phase and separate fixed-price contracts for iterations or user stories; time-and-material contracts; not-to-exceed with fixed-fee contracts; and, incentive contracts (e.g., fixed price with incentive; cost-reimbursable with award fee). [Agile Project Management: Creating Innovative Products – 2nd Edition. Jim Highsmith.]

Agile project accounting principles

Definitions :

– Asset

An asset is defined as a potential future economic benefit that the firm controls based on past transactions.

– Capitalization

Capitalizion is a record of an expenditure as an asset rather than to treat it as an expense of the current period.

3 different stages

– 1. The Preliminary Project Stage includes conceptual formulation, evaluation and final selection of alternatives. Generally, once technical feasibility and the business case analysis are completed, the project is ready for consideration for funding approval by a company representative with budget authority. After approval, the project team participates in a kick-off, or project inception, to deepen their understanding of WHAT the customer needs and to ensure that they will deliver an economic benefit to the organization with a high-level release plan.

All costs are expensed at this stage :
High level customer requirements are determined technically feasible.
Business case has merit.
Financial resources are authorized by a company representative with budget authority.

– 2. In the Application Development Stage, the design of the chosen path, including software configurations and interfaces, marks the capitalization of project labor costs. The team now moves from WHAT to HOW. All work associated with designing, developing, coding, testing and installing of hardware are valuable features for the customer that can be capitalized. The customer may even be an internal department which will indirectly benefit the company’s net cash flows in the future. One exception at this stage is administrative overhead, training and manual data conversion which should be expensed.

Design, coding, testing: requirements prioritized for the next iteration with feedback from the customer.

Customer highly engaged throughout.

Projects have multiple iterations, and each may re-prioritize the requirements.

– 3. The Post-Implementation / Operation Stage begins after the code is in production and after final customer acceptance, testing and stabilization are completed. Typical activities in this stage include training, bug-fixing and maintenance. The costs at this stage are expensed.

Customer has accepted each iteration throughout the project, eliminating the risk of rejection in the final approval stage.

The impact of appropriately capitalizing software development expenditures can be significant, and has a number of important benefits. Conservative treatment of agile projects -expensing all costs- limits the use and extent of agile-developed software projects. Software development resources are expensive and often limited. Appropriate capital allocation of these resources is important to the competitive health of the company, and also ensures consistent reporting and capital allocation within management and across organizations for investors.

Applying new Agile practices

DSTUM or Daily stand-up meeting

A stand-up meeting (or simply « stand-up ») is a meeting with attendees typically standing. The discomfort of standing for long periods is intended to keep the meetings short.

Some software development methodologies envisage daily team-meetings to provide status updates to team members. The « semi-real-time » status allows participants to know about potential challenges as well as to coordinate efforts to resolve difficult and/or time-consuming issues. The stand-up has particular value in Agile software development processes.

Scrum-style daily stand-ups involve asking and answering three questions. Though it may not be practical to limit all discussion to these three questions, the goal is to stick as closely as possible to these questions :
What did I accomplish yesterday?
What will I do today?
What obstacles are impeding my progress?

Whereas Kanban-style daily stand-ups focus more on :
What obstacles are impeding my progress?
(looking at the board from right to left) What has progressed?

The meeting usually takes place at the same time and place every working day. All team members are encouraged to attend, but the meetings are not postponed if some of the team members are not present. One of the crucial features is that the meeting is intended[by whom?] as a communication vehicle for team members and not as a status update to management or to other stakeholders.[citation needed] Although it is sometimes referred to as a type of status meeting, the structure of the meeting is meant to promote follow-up conversation, as well as to identify issues before they become too problematic. The practice also promotes closer working relationships in its frequency, need for follow-up conversations and short structure, which in turn result in a higher rate of knowledge transfer – a much more active intention than the typical status meeting. Team members take turns speaking, sometimes passing along a token to indicate the current person allowed to speak.[citation needed] Each member talks about progress since the last stand-up, the anticipated work until the next stand-up and any impediments, taking the opportunity to ask for help.

Team members may sometimes ask for short clarifications and make brief statements, such as « Let’s talk about this more after the meeting », but the stand-up does not usually consist of full-fledged discussions.

FDD

Feature driven development (FDD) uses a prescriptive model where the software development process is planned, managed, and tracked from the perspective of individual software features. FDD uses short iterations of two weeks or less to develop a set amount of features. The five step FDD process is: 1. Develop overall model; 2. Create the features list; 3. Plan by feature; 4. Design by feature; 5 Build by feature. [Agile Software Development: The Cooperative Game – 2nd Edition. Alistair Cockburn.]

Internal and external factors

When considering whether to apply new agile practices, several internal and external factors should be considered. Internal factors include whether the project is developing new processes or products; whether the organization is collaborative and emphasizes trust, adaptability, collective ownership, and has minimal or informal project management processes; the size, location, and skills of the project team. External factors include the industry stability and customer engagement or involvement. Generally, agile is best suited to developing new processes or products for an organization that is collaborative and emphasizes trust, adaptability, collective ownership, and has minimal project management processes by an agile/project team that is relatively small in size, is collocated, and is cross-functional in skill. Additionally, agile is known to succeed in industries that are quickly adapting to disruptive technologies as opposed to industries that are stable and perhaps inflexible to adaptive approaches. And, lastly, the component of customer involvement and engagement cannot be stressed enough; the more participation, the better. [The Art of Agile Development. James Shore.]

Iteration events

For productive iterations, each team member should attend all meetings as a “PEER” :

– Plan each iteration (Iteration Planning)

– Expect daily updates (Daily Stand-Up)

– Examine product results (Iteration Review)

– Reinvent processes for next iteration (Iteration Retrospective)

Planning game

Extreme programming (XP) uses the planning game to prioritize features based on user stories and release requirements. [The Art of Agile Development. James Shore.]

Planning poker

Planning poker is a popular agile game used to estimate the relative work effort of developing a user story. Each team member has a deck of cards with various numbered values which he or she can draw from to « play (showing one card) » to indicate an estimated point value of developing a user story. [Coaching Agile Teams. Lyssa Adkins.]

Scrum

Scrum emphasizes, in part, the following principles: always have a product you can theoretically ship, speak a common language, and continuously test the product as you build it. [Agile Project Management with Scrum. Ken Schwaber.]

The core roles in scrum are the product owner, scrum master and development team. [Agile Project Management with Scrum. Ken Schwaber.]

The product development team decides what could be achieved by the next sprint. PO gives the priority, team decides the capacity.

Whenever a project needs many people, the guideline is to form multiple scrum teams sprinting individually that do daily scrum followed by a daily or weekly Scrum of Scrums at which one member from each scrum team meet to synchronize their work for any dependencies.

– Product Owner

PO is solely responsible for change management at any stage. The team should provide inputs to the PO like impact analysis on the basis of which the PO needs to make a decision on the priority of the change.

In scrum Product Owner is authorized and responsible to identify what all need to be built, so team member should notify this to PO and PO should take call on this.

XP

Extreme Programming (XP) uses the following practices: pair programming, collective ownership, continuous integration, 40-hour week, on-site customer, coding standards, open workspace, and team rules [Agile Software Development: The Cooperative Game – 2nd Edition. Alistair Cockburn.]

A project manager in an XP team ensures that the team works well with the rest of the organization. A PM is more focused in managing external stakeholders.

– Refactoring

It is always recommended to refactor the code if it is more than complex, but doing this may require a good amount of time so it’s better to get this work first added in product backlog and then accomplish it. If you can do it without impacting the current sprint goal you can create a task in sprint backlog for refactoring the module and start working on it.

Compliance (organization)

Compliance with a company’s code of ethics and professional conduct is standard practice in agile. [PMI Agile Community of Practice Community Charter. Project Management Institute.]

Control limits for Agile projects

Control limits – those which set an objective range to indicate whether a process is controlled or stabilized or defect free (e.g., within three sigmas of the mean) – may be used in an agile project. Generally, a control limit of three-sigma (s) is used on a Shewhart control chart. A sigma refers to one standard deviation. So three sigmas indicates a limit three standard deviations away from the mean in both the positive and negative direction. This applies to normal data, where a normal distribution curve has been obtained. [Lean-Agile Software Development: Achieving Enterprise Agility. Alan Shalloway, Guy Beaver, James R. Trott.]

Failure modes and alternatives

The top 12 causes of agile failure (failure modes) according to Aaron Sanders :

1. A checkbook commitment doesn’t automatically cause organizational change or support.

2. Culture doesn’t support change.

3. Culture does not have retrospectives or performs them poorly.

4. Standards and quality are lost in a race to project closing.

5. Lack of collaboration in planning.

6. None or too many Product Owners.

7. Poor project leadership or scrum master that doesn’t place trust in the team and allow it to be self-organizing and self-disciplined.

8. No on-site agile promoter or coach.

9. Lack of a well built, high-performance team.

10. Accrued technical debt if strict testing standards are not upheld.

11. Culture maintains traditional performance appraisals where individuals are honored and the team aspect is lost.

12. A reversion to the traditional or ‘old-way’ of doing business occurs because change is hard.

[Coaching Agile Teams. Lyssa Adkins.]

Globalization, culture, and team diversity

– Common language

Scrum emphasizes, in part, the following principles: always have a product you can theoretically ship, speak a common language, and continuously test the product as you build it. [Agile Project Management with Scrum. Ken Schwaber.]

A high-performance agile team is one that is ideally collocated for osmotic communication and face-to-face interaction. However, collocation isn’t always feasible in today’s multinational environment. For distributed teams, several practices are available to provide the best form of effective communication in the absence of being collocated: team intranet sites, virtual team rooms, and video conferencing over e-mail when possible. Geographic separation, especially on a world-wide scale, causes the team to consider language and cultural differences, and time zone differences. [Agile Software Development: The Cooperative Game – 2nd Edition. Alistair Cockburn.]

Changing company culture is typically the most difficult when migrating to an agile framework. [The Art of Agile Development. James Shore.]

Innovation games

The phrase innovation game refers to a form of primary market research developed by Luke Hohmann where customers play a set of directed games as a means of generating feedback about a product or service. The research is primary because the data collected is gathered directly from customers or prospects and is intended to answer a specific research question. (Secondary research is data collected previously by others, usually through primary research, that may or may not address a specific research question.) “Customers” who play innovation games are commonly direct recipients or consumers of a specific product or service. In some cases, though, game players may be any person or system who is or would be affected by a product or service.

Innovation games are directed by a facilitator whose responsibilities include :

– explaining the game(s) to be played;

– controlling the pacing and tempo of each game;

– monitoring participation levels; and,

– managing time of the overall game-play event.

The successful operation of an innovation game relies on collaborative play among the participants and a set of observers drawn from disparate functional groups within an organization. For example, a typical game setting for a word processing software might include participants drawn from two or three corporate customers along with observers comprising the product’s quality assurance manager, technical architect, product manager, developer, sales executive, or any one else on the product team. Arguably, the most important observer is the product manager because that person is responsible for acting on the data generated by the game. However, a single observer cannot possible capture all of the nonverbal and nuanced communication that players exhibit, so all observers play a significant and irreplaceable role in the effective utility of the game.

12 innovation games

There are at least 12 unique innovation games (and any number of new games derived by combining elements of these 12 games) :

– 20/20 Vision

Several potential product features appear on a shuffled set of note cards, one feature per card. The facilitator tapes the first card face-out onto the wall and displays each of the remaining cards one at a time to the participants, asking if the feature on the card is more or less important than the feature on the wall. No two features are allowed to be of equal importance.

– Buy a Feature

Participants see a list of proposed product features and a cost (expressed as development effort or street-level pricing) associated with each. Each participant “buys” a desirable feature; participants may also pool resources to buy features too expensive to be purchased with individual funds.

– Give Them a Hot Tub

Several potential product features appear on a shuffled set of note cards, one feature per card. Some of the proposed features are completely outrageous, such as a “crush rocks” setting for a new food blender. Observers note what happens when a customer uncovers one of these outrageous features.

– Me and My Shadow

Observers carefully record a participant using a product or service. Observers sit next to the participant to watch for and listen to actions, expressions, comments, and suggestions. Observers ask questions of the participant, such as “Why are you doing that,” or “what are you thinking at this moment”.

– Product Box

Participants imagine that they’re selling a vendor’s product at a tradeshow, retail outlet, or public market. Participants use plain cardboard boxes, glue, paint, crayons, and other scraps and knickknacks to design a product box that they would buy.

– Prune the Product Tree

A very large tree (representing a system or product) is drawn on a whiteboard. Thick limbs represent major areas of functionality within the system. The edge of the tree—its outermost branches—represent the features available in the current release of the product. Participants write new features on several index cards that are shaped like leaves, and then they place these feature-leaves onto the tree, revealing which branches (product features) are important to customers for future improvements.

– Remember the Future

Participants imagine a time in the future when they will have been using the product almost continuously between now and then. (“Future” may be expressed in months, years, or some other time frame.) Participants then write down exactly what the product will have done to make them happy, successful, rich, safe, secure, etc.

– Show and Tell

Participants bring in examples of artifacts created or modified by the product or service. Participants explain why these artifacts are important, and how and when they are used.

– Speed Boat

A drawing of a boat appears on a white board or sheet of butcher paper. Anchors “attached” to the boat prevent it from moving quickly through the water. The boat represents a product or system, and the anchors are features that the participants don’t like. The lower the anchor, the more debilitating the feature.

– Spider Web

A product name appears at the center of a circle drawn in the middle of a whiteboard. Participants draw other products and services, explaining how, when, and why they are used. Participants then draw lines that link these additional services to each other and to the product’s circle.

– Start Your Day

Participants describe their daily, weekly, monthly, and yearly events related to their use of a product. Descriptions are written on pre-printed, poster-sized calendars or timelines taped to the walls. Participants include events with time frames that match the product’s expected lifecycle or release cycle. Participants may also include one-time events (particularly horrible days where everything goes wrong) and describe how the product helps or hinders as the event unfolds.

– The Apprentice

An engineer or product developer uses the product as an end-user. For example, if the system is used for data entry, the developer enters data for a couple of days. Observers record the engineer’s actions, expressions, comments, and suggestions.

Selecting an appropriate game

While any number or variety of innovation games may be invented, combined, or adapted from other game environments, all such games have strengths and weaknesses that constrain their applicability to specific kinds of problems.

These strengths and weaknesses are expressed as six separate dimensions :

– the degree of open-ended exploration: how much or how little the participants are constrained in their interactions

– the degree of scalability: the number of customers who can play the game at any one time

– the degree of physical preparation: what kinds of supplies or materials are necessary to play the game

– the degree of market preparation: how much background effort is necessary to provide data or content for the game

– the degree of customer preparation: what pre-game activities, if any, to require of the participants before entering the game environment

– the time frame of action: how long after the game completes before the participant expects a product’s improvement to reflect the game’s results

Principles of systems thinking (e.g., complex, adaptive, chaos)

A complex adaptive system, or CAS, is a system composed of interacting, adaptive agents or components. The term is used in agile to remind practitioners that the development of a product is adaptive in that previous interactions, events, decisions influence future behavior. The term chaordic (a made up word blending chaotic and order) is sometimes used when describing CASs. Literature points to three key characteristics of chaordic projects: alignment and cooperation, emergence and self-organization, and learning and adaptation. [Agile Project Management: Creating Innovative Products – 2nd Edition. Jim Highsmith.]

Regulatory compliance

Although in agile project management, it is generally practiced to generate minimal documentation to support the project, some specific documents, like those required by regulatory bodies need to be created to comply with local and federal law. [Agile Project Management: Creating Innovative Products – 2nd Edition. Jim Highsmith.]

Compliance with a company’s code of ethics and professional conduct is standard practice in agile. [PMI Agile Community of Practice Community Charter. Project Management Institute.]

Variance and trend analysis

Unlike traditional project management methods that evaluate risk and variance and trends in formal meetings, agile incorporates risk analysis and variance and trend analysis into iteration review meetings. Risk and variance and trend analysis may be performed in agile using information radiators, like a risk burndown chart, and the use of traditional earned value management (EVM) to measure cost and schedule variance (CV and SV, respectively). [Agile Estimating and Planning. Mike Cohn.]

EVM

EVM or earned value management is a management technique used to evaluate project performance with respect to cost and schedule. EVM relies on other common financial metrics like Budget At Completion (BAC), Actual Cost (AC), Planned Value (PV), Earned Value (EV), Cost Variance (CV), Schedule Variance (SV), Cost Performance Index (CPI), and Schedule Performance Index (SPI). BAC is the total project budget. [Agile Estimating and Planning. Mike Cohn.]

EVM or earned value management is a management technique used to evaluate project performance with respect to cost and schedule. EVM relies on other common financial metrics like Budget At Completion (BAC), Actual Cost (AC), Planned Value (PV), Earned Value (EV), Cost Variance (CV), Schedule Variance (SV), Cost Performance Index (CPI), and Schedule Performance Index (SPI). CV and SV can be converted into performance indicators of CPI and SPI, respectively, and tracked and charted to show progress over time. BAC is the total project budget. AC is the actual cost incurred to date. PV is the planned value of work at a given time in a project; you can calculate it by multiplying the BAC by the ratio of current week/scheduled weeks (e.g., 5 weeks into a 15 week $15,000 project = $5,000 PV). EV is value of work actually completed or earned (e.g., you have completed 50% of the project by week 5 of a 15 week $15,000 project = $7,500 EV). CV is the difference between what a project has earned to date and cost to date (i.e., CV = EV – AC). SV is the difference between what a project has earned to date and what it was planned to earn to date (i.e., SV = EV – PV). CPI is a ratio that expresses cost performance. CPI = EV/AC. If CPI > 1, the project is earning more than spending; and if CPI 1, the project is ahead of schedule and if SPI < 1, the project is behind schedule. [Agile Estimating and Planning. Mike Cohn.]

– SPI

Schedule Performance Index (SPI). SPI is a ratio that expresses schedule performance. SPI = EV / PV. If SPI > 1, the project is ahead of schedule and if SPI < 1, the project is behind schedule. AC is the actual cost the project has incurred to date. [Agile Estimating and Planning. Mike Cohn.]

Variations in Agile methods and approaches

XP primary principles include: collective ownership, continuous integration, energized work, shared workspaces, and an on-site customer. [The Art of Agile Development. James Shore.]

Vendor management

Approch

The Agile Manifesto values customer collaboration over contract negotiation which sets an important tone for procurement relationships on agile projects. The Agile Manifesto sets forth the idea that a buyer and seller work together to create products and governs the entire procurement process.

Determining need and selecting a vendor the agile management way

On agile projects, procurement starts when the development team decides it needs a tool from or the services of another company in order to create the product. The development team and the scrum master work with the product owner to procure any necessary funds.

The development team may need to compare tools and vendors. After you choose what to buy and where to get it, the process is usually straightforward: Make the purchase, take delivery, and procurement is then complete.

Procuring services is usually longer and more complex than with tools.

Some agile-specific considerations for selecting a services vendor include

Whether the vendor can work in an agile project environment and, if so, how much experience the vendor has

Whether the vendor can work on-site with the development team

Whether the relationship between the vendor and the scrum team is likely to be positive and collaborative

Contracts and cost approaches for services the agile management way

– Evaluating cost structures for an agile project

Fixed-price projects: A vendor works on the product and creates releases until the vendor spends all the money in the budget, or until it delivers enough product features, whichever comes first.

Fixed-time projects with a specific deadline: For example, you may need to launch a product for a specific event or to coincide with the release of another product. With fixed-time projects, you determine costs based on the cost of the vendor’s team for the duration of the project, along with any additional resource costs, such as hardware or software.

Time-and-materials projects: Work with the vendor lasts until enough product functionality is complete, without regard to total project cost. You know the total project cost at the end of the project, after your stakeholders determine that the product has enough features to call the project complete.

Not-to-exceed projects: Projects in which time and materials have a fixed-price cap.

– Creating a contract for an agile project

The scrum master is generally responsible for initiating the contract creation, negotiating the contract details, and routing the contract through any necessary internal approvals, including review by a legal or procurement expert.

– At the very least, most contracts have legal language describing the parties and the work, the budget, the cost approach, and payment terms. A contract for an agile project may also include:

– A description of the work the vendor will complete :

The vendor may have its own product vision statement, which can be a good starting point to describe the vendor’s work.

– Agile approaches the vendor may use, including :

Meetings the vendor will attend, such as the daily scrum, sprint planning, sprint review, and sprint retrospective

Delivery of working functionality at the end of each sprint

The definition of done — developed, tested, integrated, and documented — per an agreement between the product owner and the development team

Artifacts the vendor will provide, such as a sprint backlog with a burndown chart

People the vendor will have on the project, such as the development team

Whether the vendor will work on-site

Whether the vendor will work with its own scrum master and product owner or if it will work with your scrum master and product owner

A definition of what may constitute the end of the engagement: the end of a fixed budget or fixed time, or enough working functionality

If the vendor doesn’t use agile approaches, describe how the vendor and the vendor’s work integrate with the buyer’s development team and sprints.

Working with a vendor on an agile management project

How you work with a vendor on an agile project depends in part upon the vendor team’s structure. In an ideal situation, vendor teams are fully integrated with the buyer’s organization. The vendor’s team members are collocated with the buyer’s scrum team.

Some development teams include vendor team members in their daily scrum meetings. This can be a good way to get an idea of what the vendor team is doing every day and to help the development team work more closely with the vendor. You can also invite vendors to your sprint reviews to keep them informed on your progress.

If the vendor can’t work on-site at the buyer’s company, it can still be part of the buyer’s scrum team. If a vendor can’t be collocated, or if the vendor is responsible for a discrete, separate part of the product, the vendor may have a separate scrum team working on the same sprint schedule as the buyer’s scrum team.

If a vendor doesn’t use agile project management processes, the vendor’s team works separately from the buyer’s scrum team, outside of the sprints, and on its own schedule. The vendor’s traditional project manager helps ensure that the vendor can deliver its services when the development team needs them. The buyer’s scrum master may need to step in if the vendor’s processes or timeline becomes a roadblock or disruption for the development team.

Closing a contract on an agile management project

When a vendor completes work on a contract, the buyer’s scrum master usually has some final tasks.

If the project finishes according to the contract terms, the scrum master may acknowledge the end of the contract in writing. If the project is a time-and-materials project, the scrum master should definitely do so to ensure that the vendor doesn’t keep working on lower-priority requirements — and billing for them.

The scrum master may be responsible for notifying the buyer’s company accounting department to ensure that the vendor is paid properly.

If the project finishes before the contract dictates the end, the scrum master needs to notify the vendor in writing and follow any early termination instructions from the contract.

Most large organizations maintain a vendor profiling system to manage the relationships with their vendors. This database contains information about skills, rates, and former projects that have been run with each vendor. More or less, sophisticated ranking systems categorize the vendors from strategic partners to vendors the company wants to get rid of. Used wisely, these systems can establish both a business and a legal relationship with your vendors in which you don’t have to step on the thin ice of contracting a single agile project.

Therefore, rather than focusing on vendor process certifications, size, and rates, the ranking should focus on criteria such as the following :
– Productivity
– System quality
– Flexibility
– Collaboration level

Beyond a single effort, agile development is about building trust. A special vendor management database may help large organizations here — as long as the vendor evaluation is based on « soft » criteria, such as collaboration level and software quality, rather than on « hard » facts, such as rates and willingness to subordinate during negotiations.

Leave a Reply

You must be logged in to post a comment.