Blended teams: customer and partner co-development

[00:00:00] How can a Microsoft partner's scrum team work with a customer's developers? 

One Microsoft partner I worked with, let's call her Selina, refused to have anyone from the customer organization in her scrum team. She was concerned that her Gotham Heroes business was responsible for quality and velocity, which would suffer if the customer stacked the team with developers new to Dynamics 365. How would you handle a situation like this?

 Hi there. I'm Neil Benson and you're listening to the Amazing Applications podcast. A very special welcome to you if this is your first time listening to the podcast and welcome back. If you've been here before. 

I like to alternate between interview style episodes and solo episodes like this one. I'm going to be releasing some more solo shows for the next few weeks, addressing questions about how to adopt and apply an agile approach to building business apps. 

At the same time, I've been interviewing lots of great guests and we'll be releasing those episodes sometime next year. Make sure you stick around, follow the show and set it to download episodes automatically into your favorite podcast player.

If you'd like to see what's coming next or suggest a topic or guest for the show visit AmazingApps.Show/Ideas. I'm experimenting with having the show's content plan available to you and so far it's working well, let me know what you think. Okay. Let's get on with this week's episode.

 Earlier this year, I was [00:02:00] coaching the owner of a Microsoft partner business, Selina from Gotham Heroes and her customer, let's call him Arthur from Gotham Orphanages. They had recently embarked on an enterprise transformation project involving their CRM and finance applications. 

Arthur at Gotham Orphanages was keen to take an agile approach and he had enrolled his team in my Scrum for Microsoft Business Apps course. Gotham Heroes had hired a scrum master and were attempting to adopt an agile approach. They used a practice called PI planning, or product increment planning, which is a quarterly product goal setting and backlog ordering practice borrowed from the Scaled Agile Framework.

Together, Gotham Heroes and Gotham Orphanages were beginning to plan their second product increment. And Arthur wanted to add a couple of the Orphanages' developers to the Heroes' scrum team. I don't know who the customer had in mind and whether those folks were business analysts or new Power Platform citizen developers, or pro developers or developers with, uh, experience in the organization's existing technology stack, perhaps they could have been QA analysts. I don't know their skills or level of experience. 

But Selina's reaction was a flat-out no. She felt like her Gotham Heroes were responsible for meeting the timelines and the scope agreed in the statement of work. Adding Gotham Orphanages' developers to her team jeopardized her ability to meet these commitments.

If Arthur wanted to expand the team, Selina was happy to do so if she got to hire them and to manage their work, not Arthur. She knew that Gotham Orphanages had no previous experience building Dynamics 365 or Power Platform applications and there was a risk that anyone from the Orphanage would slow down her team of highly experienced developers. 

They were already a little behind in the schedule after the first product increment. And if they fell [00:04:00] any further behind, she was worried about the consequences, like getting dropped and losing the customer. 

Selina's reaction was a natural one. In similar circumstances if I own the business and had its reputation and existence to protect, I might've made similar decisions. 

In situations like this one, it's helpful to dig a little deeper, to find the root cause of the issue. In this scenario, I think there were two issues. 

The first was Selina's preference for controlling as much as she could. She is an expert technical architect with an amazing career as a developer who set up her own business a couple of years ago. She's won this massive opportunity with Gotham Orphanages and felt solely responsible for delivering the project.

Although she had built a great team around her, she still enjoyed being a hands-on technical architect, directing the scope and the resources like a project manager, and looking after the customer as their engagement manager. Well, she's talented and could probably succeed in any of those roles, but she couldn't possibly do them all at the same time without burning out. And without confusing the people she had hired to delegate those roles to. 

Mindset was the first underlying issue. And to her credit, Selina was working on it. She had some great coaching sessions with me and her trusted business coach, whom she had known for years. 

I wonder if you can figure out or imagine what the second root cause issue was. I hinted at it earlier. It was the contract. 

If you're applying an agile approach to building an enterprise business application, but your contract, that is usually your terms and conditions and your statement of work. If they were written eons ago for a traditional waterfall style engagement, then you're probably going to run into issues like this. 

Here are a couple of key differences between statements of work for agile and waterfall engagements. 

Waterfall [00:06:00] statements of work are tied to a requirement specification. This defines the scope. The specification says, this is what we will build no more, no less. Sure, you can make changes to the specification, but they're going to cost you. The specification gets decomposed into a work breakdown structure with all the effort required to complete all the tasks to build the app to the specification.

Waterfall statements of work specify the resources. The Microsoft partners specifies the types of billable resources, their level of effort, and their rates to derive the total fees for building the application. Resources, and I appreciate that's a trigger word for some people, are considered fungible. If the statement of work specifies a senior developer, at 200 an hour, then I can swap out a senior developer for any other one in my pool of senior developers. But they must be my developers, not your developers. Otherwise, there is a quality risk and the loss of revenue. 

Waterfall statements of work commit to a deadline. Based on that work breakdown structure, the estimated effort on the number of resources applied to the project we, as Microsoft partners, can forecast how long it'll take to build. And then we commit to a delivery date in the statement of work. 

Waterfall statements of work sometimes take this a step further by fixing the scope and the costs and the timeline. This is often at the customer's request because the customer perceives a benefit of loading the partner with all the risk of building complex business applications.

Now, there are penalties for nonconformance with this specification going, over the budget, or delivering late. Often, these are expensive financial penalties. The partner returns the favour and loads the SOW with a big fat contingency to cover their risk. 

Let's contrast that with an agile statement of work. 

There's no requirements [00:08:00] specification attached to an agile SOW. I recommend including a set of high level requirements, usually expressed as epic user stories and illustrated in a user story map. My teams estimate these epics using a relative estimation method and an arbitrary unit of measure, like story points. 

There's no work breakdown structure in an agile SOW. I recommend using a release burndown chart, showing the estimated number of sprints it'll take to burn down the estimated backlog to zero based on our delivery team's predicted velocity. That's how we get our forecast timeline for building and releasing the application. And if anything changes during the delivery, then the user story map will change, and the release burndown chart will also change. The timeline can shrink or expand depending upon the changes made by the customer's product owner. 

Agile statements of work describe a joint delivery team. This includes the product owner. The product owner is the senior decision maker from the customer's organization who will be responsible for maximizing the value of our business application. They do this by setting the product goals and being accountable for the application's product backlog. I like to specify who the product owner will be and their expected capacity in our agile statement of work. This sets expectations upfront and attempts to prevent surprises. When it later turns out that the nominated product owner thought that three or four hours a week would be sufficient or delegates the role to a business analyst who doesn't have decision-making authority. Name the product owner.

I also like to specify the rest of the scrum team in the statement of work too. I'll name the scrum master and the developers. Two to eight developers. If you want, you can also include developers from your customer's organization in your scrum team. Describe them in the statement of work. 

If I've been [00:10:00] working with these folks in presales or discovery work, and the customer has made it clear they want them in the team, then I'll include them in my statement of work. I'll make my expectations about my customer's developers clear too. I'll state my assumptions, such as the minimum capacity they'll have in our team, how many hours per week or per sprint will they be working in our business applications team? And I'll also specify some minimum training and certification expectations too. They'll need to achieve Professional Scrum Master 1 certification and their relevant associate level technical certification in the Microsoft business application, such as PL-100 Power Platform App Maker, or whatever is appropriate for the app we're deploying. 

One big question is this: Do you. Adjust the scrum team's predicted velocity when customer developers are added to it? For example, if I predicted that my scrum team with six of my developers would have a velocity of 40 story points per sprint, what's the predicted velocity when we add two customer developers to the team. 

Personally, I don't alter their predicted velocity, either up or down.

There's a chance it'll go up because the customer's developers make a significant contribution to the scrum team. Their effort helps the team build more high quality increments every sprint. 

I've seen this in projects where the customer's developers include an experienced business analyst with a deep understanding of the organization's structure, processes, and systems. Or where the customer's developer has the skills and experience required for integration with one of the customer's existing systems. 

But there's also a chance it'll go down because the customer's developers don't have a lot of experience building Microsoft business apps. My developers, as a Microsoft partner team, spend a significant amount of time each sprint on training and knowledge transfer, which [00:12:00] slows us down for several sprints. At least until the customer's developers come up to speed. 

The effect of adding customer developers to a Microsoft partner's scrum team that has experienced Dynamics 365 or Power Platform consultants in it is unpredictable. 

I don't change my predicted velocity up or down. I include that assertion in the statement of work and I discuss it with my customer so they're clear on it. They're usually hoping that a bigger scrum team will be able to go faster, but that isn't always the case. And we need to level set those expectations in the statement of work. 

Imagine that, after a few sprints, the customer's developers are rockstars on picking up Dynamics 365 or Power Platform apps quicker than expected. Your team's velocity will be higher than that initial predicted velocity. You'll be able to complete the forecast backlog within a shorter timescale or get more of the backlog done within the customer's budget or within their timescale, whatever is most important in their objectives. 

Or, imagine that after a few sprints, the customer's developers are inundated with support work for a legacy system or distracted by another project. Whatever the cause they are not providing the capacity agreed in the statement of work. In this scenario, your predicted velocity won't be affected because you were never counting on the effort of your customer's developers in that predicted velocity. 

Only rarely have I ever seen a Microsoft partner's team's velocity drag down from more than a few sprints when some customer developers joined, and it takes a while for them to make a positive contribution.

Selina, if I were in your shoes, I'd find a way to reframe your engagements with Gotham Orphanages and all your future customers too. If you're going to adopt a modern, collaborative and agile approach, then use a statement of work, suited to this style of engagement. 

 I love it when [00:14:00] developers from my customer's organization join my team. It shows the customer's commitment to the business application. It helps me deliver faster and further, most of the time. And it ensures that there is an experienced team to continue to support and enhance the application after the initial project to, to deploy it has been successfully delivered. 

Whether you work for a Microsoft partner or customer organization, I hope you learn something today that has inspired you to take action and consider the style of your relationship and your statement of work, so you can work together in a combined fashion between Microsoft customer and partner.