Agile vendor management
Agile vendor management
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.