Hope is perhaps the most powerful human emotion as well as the most uniquely human one. It allows us to overcome great challenges. But it can also be a weakness.
I was talking to a colleague recently who is charged with leading a digital transformation in her organization. Like many digital transformations, this means organizational change and often comes with a transition to an Agile methodology. To share responsibility and an overall stake in the game, she decided to appoint business leaders as product owners, who would have to quickly learn the Agile way to creating a roadmap: epics and user stories organized into sprints for rapid execution.
Having seen too many engineering teams hamstrung by slow product decisions and low-quality user stories, I offered an outside view: at such a crucial moment of transition, why place so much risk in people who may be out of their comfort zone? Business leaders often have too many meetings to answer the daily questions that Agile often demands of product owners, and may not be able to hit the ground running when tasked with the creation of an Agile roadmap and backlog of user stories. She responded that they were hoping that by involving the business directly in the transition, they would be guaranteeing the success of the transformation with their participation and buy-in.
There it is: hope. When I go all in on a pair of jacks, I also hope I do not see any aces. Even if you do not play poker, you get the point. When leading initiatives that impact an entire organization, no one likes to gamble.
The bottom line is this: business leaders are amazing at what they do. They make key decisions in their area of expertise. Unless the business is making software applications, there is the risk that they are out of their element when it comes to the ins and outs of Agile.
The exact same argument can be made when traditional project managers are expected to become scrum masters overnight. All the training and certification in the world does not compare to actual experience delivering working software the Agile way.
Managed Teams versus Staff Augmentation
The most common model for outsourcing software development and IT resources is staff augmentation. In this model, you get exactly what you pay for – a resource, usually at an hourly cost. Whether that resource has tasks efficiently assigned or a robust backlog to pull tasks from is 100% dependent upon your company’s ability to manage delivery, from product vision down to shipping code. As a solution provider, we are often in the situation in which we want to provide more value but do not have the responsibility and authority to do so. And with staff augmentation, the reality is that the vendor will likely be paid at the end of the month whether the resource is 100% productive or not. In this sense, the customer has complete control but also bears all of the risk.
Taking the example of my colleague above, let’s look at the worst-case scenario.
The initiative begins, and the business owners struggle creating quality user stories. Since they are responsible both for their day-to-day business and grooming the backlog, they cannot keep up. The engineering team, largely consisting of contractors working under staff augmentation, become frustrated because they do not have work to do, and they have unanswered questions about the few tasks they have. Ultimately, they feel responsible for delivery, but cannot deliver. This would be a “lose-lose” situation, bad for the customer, bad for the vendor.
A managed teams approach seeks to share both the risk and the responsibility, including the benefits of flexibility, adaptability and continuous validation that come with rapid Agile development. The managed team would include the roles necessary to keep the code flowing. This may mean a product owner, who would work closely with the business leaders to both capture requirements and translate them into a workable backlog, and a scrum master to ensure productivity and minimize risk on a day-to-day basis. Depending upon the scope of transformation, this may also include roles like DevOps and test automation engineers to ensure continuous delivery.
This approach is usually framed by a time and materials agreement with a fixed monthly cost, as opposed to individual hourly rates for resources.
Besides a higher probability of overall success, there are other key benefits for customers who choose this approach:
- Let the business make decisions at the business level, where they are the experts. Let the people who know how to deliver software do what they do best.
- By focusing more on teams than individuals, it is easier to arrive at volume discounts and regular fees. This also allows the vendor some flexibility with the team composition to make sure they are providing the most value and provides stability and forecasting to the customer.
- Companies can focus on the digital transformation without having to become Agile experts overnight. They can learn from each initiative and incorporate this knowledge within the context of their business while assuming less risk.
These are only some of the benefits that this model provides – others include frequent validation of deliverables as part of the agreement, as well as KPIs and quality metrics that the customer may define. Again, the spirit of the agreement is accountability to guarantee successful delivery.
This does not negate the overall value that staff augmentation may provide, and there are cases in which this is the simpler and most effective option. However, it is an option that does not always allow the vendor to provide the maximum value it can (and wants to) provide, nor does it necessarily guarantee skin in the game when the success of a large customer initiative is at stake.
A Disruptive Secret
Embedded in the managed teams approach is a simple idea: each role in the SDLC has very specific expertise, including traditionally non-technical roles like scrum masters and product owners, who understand the inputs and outputs of software – the parameters, but at a higher level of abstraction. These team members quickly adapt to and understand many organizations and their industry-specific challenges.
Disruption in markets occurs often due to innovation that comes from applying a paradigm from one domain to another. This kind innovation relies on outside experts who can see a business with fresh eyes and apply new ideas from their diverse set of experiences. Sharing control of delivery with a managed team, along with the responsibility of delivering successful products, adds greater value that can stimulate this innovation. This will lead to a more strategic and ultimately successful partnership between the customer and the vendor.