Marty Schecter, VP-Product Development and Management, John Wiley and Sons
The benefits of shifting to lean and agile methodologies for companies developing products and digital customer experiences have been well documented. In great numbers, companies have shifted from waterfall to agile in order to respond to rapidly changing consumer digital habits and compete in the market against disruption from rapid technological innovation. The main shift that the agile methodology has prompted us to do is to think about software releases coming at a steady pace – say, every two weeks – rather than defining a set of deliverables that are finished within whatever time it takes to complete. In agile, the time frame for delivery becomes the set, agreed upon factor, and the deliverables become the variable. Features comprise a “backlog,” with scrum teams meeting daily under the direction of product owners who groom the backlog and fit features into releases dynamically with business needs. Additionally, the agile software method is a prerequisite for companies wishing to apply lean startup approaches to improve customer success for new products through rapid market testing of minimum viable products. The lean startup approach to innovation reduces the market risk associated with new product launches, while accelerating the time to reaching “product-market fit” by allowing rapid “pivots” to different feature roadmaps with each scrum iteration.
"The time and materials model works well for projects of sufficient duration that agile teams are set in a semi-permanent status, available to develop software under the guidance of product owners building long-term roadmaps"
All of this poses questions for how companies can best partner with outside software vendors, development firms, and digital agencies. How can companies run agile and lean startup shops, and still contract with vendors around pre-defined fees and terms?
In general, there are two business models commonly used with outside vendors. In the first model, the vendor works on a time and materials basis. In this model, the vendor staffs a project team to supplement key positions. In the other model, a company contracts with an outside vendor or agency for a specific product deliverable at a set price. Typically this deliverable specifies either a set of specific tasks or features to complete, the scope of which is used to determine a reasonable fee.
In the first “time and materials” model, it is easy to see how agile methodologies can be employed (although there are still pitfalls to be conscious of). In the second “fee for service” model, applying an agile approach seems more difficult. How can features be free to change and yet you and the vendor agree in advance on a fixed fee for service? We shall see an approach that may come close.
First, however, let’s discuss the pitfalls with the “time and materials” model. It is very easy to set up an agile pod or squad where some positions are fielded by outside vendors potentially in less expensive locations around the globe, and many such vendors now provide these “innovation” services with quality teams. However, team is the operative word in agile, and more than likely, key product owners in your agile squad will remain full time employees (FTE’s) within your company. Moreover team members need to be able to interact and work just like an FTE, and have the same level of competency and chemistry with your team as if your executives had hired them yourself. Modern collaboration tools like Slack, GitHub and Jira make it easier to collaborate 24/7 around the globe. But team chemistry and continuity is still important. You should be able to review resumes and interview potential team members before they are assigned. You also need to make sure that team members aren’t swapped out without your review and approval.
The time and materials model works well for projects of sufficient duration that agile teams are set in a semi-permanent status, available to develop software under the guidance of product owners building long-term roadmaps. But what about more short term projects, or projects that may require a temporary, highly specialized skill set? In these cases, a fee for service model may make more sense, especially when projects have a fixed budget and a specific deliverable in mind.
Can you set up an agile model under such an arrangement? I would say you can, and here are the key points –
Create a statement of work (SOW) that includes multiple releases. Three to four is a good number – it allows for two or three major releases (giving teams flexibility for pivots), followed by a transition release that winds down the project (or hands over to internal “time and materials” teams for ongoing maintenance).
Create a backlog in your statement of work. Evaluate and size the programming effort each of these features and describe at a high level. Agree up front that this backlog comprises the deliverables; but agree that the scrum teams will be able to change the features specified in the backlog as they go, as long as they swap in features that are the same relative effort size as ones swapped out.
Ask the vendor to work in your internal communication and tracking systems, as you would a time and materials vendor. This reinforces the team mentality.
Inevitably, any project run under a fee for service will still be faced with the knowledge that there is a limit to the money, and therefore an ultimate limit to delivering a successful outcome. This will therefore require some level of trust between the company and the vendor. But with the right process established in the SOW, agile principles can still be applied.