Who do we need in our Business Apps team?

Neil Benson [00:00:00]: In my experience, I've found that great product owners are passionate about the problem the organization wants to solve with Dynamics 365 or Power Platform. They've got the vision and the drive to lead the team to build the app that the organization needs. You'll need decision-making authority and capability to determine what's going into the app and what's not going into it. 

[00:00:24]: G'day. This is Neil Benson. You're listening to Amazing Applications, the podcast for Dynamics 365 and Power Platform professionals who want to build amazing, agile business applications their stakeholders will love.

[00:00:36]: If this is your first time to the show, a very special welcome. If you're a repeat listener, then welcome back. I really appreciate you downloading another episode. This is episode 143. We're going to be talking about resourcing our teams. In the last episode, we were splitting teams, and today, we're resourcing them. What roles do we commonly find on teams building enterprise business applications? I'll share my experience with you and give you some real-life examples of the composition of my teams when we've been building complex business applications. You'll find show notes, a transcript, and links to any resources mentioned at amazingapps.show/143. While you're there, you can Buy Me a Coffee if you find that my content helps you in any way. There are links that you can leave a review on Apple Podcasts, a rating on Spotify, or if you don't use any of those apps, you can leave a review directly on the site. If there's a question you'd like me to answer in a future episode, you can also leave me a voicemail.

[00:01:32]: So let's talk about resourcing our teams. When I'm talking about a team here, I'm referring to an agile team, specifically a team who has adopted and is applying the Scrum framework as their approach to building complex apps. Scrum isn't the only agile approach that teams can use, but it's the most popular and the one that I recommend for Microsoft customers and partners building mission-critical business applications. One of the things I love about Scrum is the clear accountabilities it provides for the team's members. They are the product owner, the developers, and the Scrum master accountabilities. Let's work through them one by one.

[00:02:06]: The product owner. As the product owner, you are accountable for maximizing the value that your Dynamics 365 or Power Platform applications have within your organization. You're ultimately responsible for the application's success. You're also responsible for creating the product goal and for drafting sprint goals. Product goal is your overarching vision for the business application, and I find it useful for the product owner to frame the product goal as a release goal. That is, the product goal is updated with each release to production, so that your organization and the Scrum team clearly understands what's next. Sprint goals are short-term goals. There's a Sprint goal set for each sprint, and I find it helpful if you bring a draft sprint goal into the sprint planning meeting and collaborate with the team to refine the goal, which will then help the developers choose the right backlog items to work on in this sprint. You might even have a release plan with draft sprint goals mapped out for all of the sprints in the upcoming release and beyond. This kind of release plan helps the team focus and lets other teams and your stakeholders understand the bigger picture. As the product owner, you're responsible for ordering the items in the product backlog. The product backlog is an ordered list of all of the work that needs to be done by the team to build the application and meet the needs of your app's stakeholders. In some teams, the product owner might create product backlog items. For example, by writing the actual epics, features, and user stories and refining them by splitting them and adding acceptance criteria so that the developers know when the item will be done. In other teams, this work is handled by one or more of the developers, usually by someone with a background as a business analyst who is familiar with the business application and also with Azure DevOps or JIRA or whatever backlog management tool your team's using. Anyone can suggest or add items to the backlog, but you always have the final say. You remain accountable for the sequence of the items in the backlog and can deprioritize or even delete items if you want. 

[00:04:03]: So what qualities will you need to be a great product owner? In my experience, I've found that great product owners are passionate about the problem the organization wants to solve with Dynamics 365 or Power Platform. They've got the vision and the drive to lead the team to build the app that the organization needs. You'll need decision-making authority and capability to determine what's going into the app and what's not going into it. You'll also have expert domain knowledge about the organization. You know the stakeholders across the organization who also have an interest in the app. You understand the business processes. You're familiar with the existing systems, and you probably know the data as well; at least you should know which data is sound and where the quality issues lie. And you should also be supported by subject matter experts who are even more familiar with the existing processes, systems, and data. You're not on your own, at least you shouldn't be.

[00:04:54]: The most important thing then for product owners is that you know the people. You might find that they're bombarding you with competing requirements, and it's going to be your job to order the backlog for business value and then still retain their trust even when they don't always get what they want when they want it. Or on the other hand, you might find that your stakeholders are disengaged. You've got to inspire them to join you at sprint reviews and participate in backlog refinement workshops. When this happens, it's often because they don't have the capacity within their teams. They can't spare someone to be a subject matter expert on your project because they don't have the budget to backfill the subject matter expert's role for several hours a week while they're involved in your project work. That's the kind of risk product owners need to escalate to the organization's executive team to resolve. If your stakeholders can't or won't participate, then there's a fair degree of likelihood that your app won't have the right features or the processes will be wrong or the data quality won't be good enough, and your app won't achieve the business outcomes that the business case is relying on.

[00:05:55]: So now we know what the product owner does, what qualities are needed to be a great product owner. Let's discuss for a moment who should be the product owner. Well, well, let's start with who probably shouldn't be the product owner. If you're a Microsoft partner building an app for a customer, the product owner shouldn't be someone from your organization. It needs to be someone from the customer's organization. Technical knowledge of Dynamics 365 or Power Platform is not required and neither is experience as a business analyst writing user stories or managing Azure DevOps. None of the great product owners I've worked with in 15 years have had those technical skills.

[00:06:30]: At least not at the start of the project anyway. So even if you have someone with business apps experience or backlog management skills in your organization, please don't propose someone from your side as a product owner. It's your customer's application. They need to nominate someone to own it. You need to help your customer find the right person. What about a business analyst? Can a customer's business analyst make a good product owner? There are a couple of supporting arguments here for sure. Business analysts often have expert knowledge of the organization's stakeholders, business processes, existing systems, and data. That domain knowledge is a good thing, right? But in my experience, business analysts are not granted the decision-making authority to determine the scope of the application.

[00:07:13]: They often need to confer with someone else or perhaps a committee of senior stakeholders before they can make those kinds of decisions. And that's going to slow everything right down. I've even had situations where the product owner accountability was given to someone not really trusted to do the job at all. Her boss would rant and rage at every sprint review because he didn't agree with anything the team had built. And surprise, surprise! The project didn't go well. We did manage to finish the app, but it wasn't a pleasant experience for anyone involved. Definitely not for the product owner. Personally, I've not been part of a project where a business analyst was appointed the product owner accountability.

[00:07:52]: I've definitely had business analysts as part of the team, but not as the product owner. However, I do know many business analysts who have progressed in their career, and today they are professional product managers. But I've not worked with someone like that in any of my projects, not yet anyway. Let me know if you're a business analyst and have become a product owner. I'd love for you to share your story with us here on Amazing Apps. The customer might have an internal project manager available. Do project managers make good product owners? Well, product owners are not project managers, although they can perform some project management activities like risk management or contract and resource management, or they can be supported by a project manager who can look after those kinds of processes. Good project managers will be trusted by the stakeholders and they'll have the political savvy and the empathy to work effectively with those stakeholders.

[00:08:39]: That's a positive attribute. If they have completed their previous project, project managers often have the capacity to act as a product owner, so that's another positive attribute as well. The biggest drawbacks with having a project manager take on the product owner accountability are, well, you know, business application’s really for life. It's not just a project who's going to own the app once it's live? The project management is probably going to be assigned to another project, and there's a risk that the app is left hanging without a true product owner who is vested in its ongoing success. 

[00:09:12]: The second challenge is a project manager's tendency to want to manage the developers. Scrum's developers are self-managing and trusted to organize themselves to get the work done. If your Darth Vader command-and-control tendencies tend to come out when you act as a product owner, you're going to end up choking the developers to death. If you're a project manager and you can break your Dark Lord of the Sith habits by letting the developers be self-managing and you have a plan for handing over the application to a line-of-business leader, then you could make a great product owner. Microsoft partner product owners are almost certainly a bad idea. Business analysts as product owners or project managers as product owners might work in some circumstances. 

[00:09:56]: Who does that leave as the perfect product owner in our customer's organizations? Well, I'll give you three examples from my experience. Firstly, it's a senior manager within the department that's going to benefit most from the Dynamics 365 or Power Platform application. In large organizations, that's unlikely to be the CEO or a C-level executive, but I have seen that happen successfully in smaller organizations. In large enterprises, it's likely to be the head of a business unit, a vice president, a director, or senior manager. Their job titles vary depending upon the industry and on whatever region you're working in. But they have a couple of things in common. They have or they are given decision-making authority. They have the capacity to participate full-time in the project or close to full-time. And they have the vision and can inspire the team to hit the product's goals. Most of the great product owners I've worked with have been senior managers from a department that will benefit from the mission-critical app that we're building. But a couple of others have been great, too. I worked with one independent consultant who was hired by the senior stakeholder to act as the product owner on his behalf. She was great. She had the experience working in a successful CRM team before. She had the vision and the leadership attributes, and running the CRM program was her only responsibility, so she had the capacity to do it, unlike our project sponsor. Critically, she had worked within the organization for several years on other engagements, so she knew the stakeholders and they trusted her. More recently, I worked with a product owner whose job title was CRM Manager. He worked in the technology team, and he was already the product owner for the previous CRM application. He was used to balancing the needs of different stakeholder groups who had requirements that competed for his resources. He knew the business processes, the existing systems, and the data. And the reason he was successful was that he was trusted by the organization and he kept the team focused on the product goals and the sprint goals during the project. 

[00:11:50]: Alright, I hope that's product owners covered. Let's move on to the developers in our team. How should we resource the developers in the Scrum team? Why don't we start with a quick reminder about what a developer is in the context of a Scrum team? Well, everyone who has a part to play in turning a product backlog item into an increment is a developer. They could be a business analyst, an architect, an app maker, a professional developer, a tester, or a DevOps engineer, or even a change manager. And we'll come back to some of those in a moment. 

[00:12:22]: Business analysts take items created by the product owner and refine them, expand them, split them, combine them, and help the other developers understand them and eventually estimate them. Are business analysts really developers, or are they assistants to the product owner? I used to think that they were proxies for the product owner, and therefore they weren't developers. That means, for example, business analysts wouldn't be expected to attend the daily scrum because it's an event that only the developers need to attend. But over the past few years, my thinking has shifted. I’ve found it more helpful to consider the business analysts to be developers. Their focus is on assisting the other developers in understanding what our stakeholders want and need from the application. 

[00:13:05]: When it comes to the role of Dynamics 365 or Power Platform architects in a scrum team, I've seen two different styles of architect. I call them intrinsic architects and extrinsic architects. Intrinsic architects have a hands-on role in the system. They are actively involved in designing and building increments and helping other developers design and build their increments. They're part of all of our scrum events, including the daily scrum and the sprint retrospective. Without their contribution, the team's capacity and velocity would be diminished. Then, there are extrinsic architects. They aren't so actively involved in designing or building increments. Instead, their role is to review designs and ensure they meet the organization's standards, often by shepherding those designs through a technical design authority or similar approval kind of committee. Or their role might be to circulate around teams to coordinate and communicate patterns and practices and to smooth out technical dependencies. I don't consider extrinsic architects to be one of the team's developers. Instead, we work with them as a stakeholder external to the team. They're invited to our backlog refinement workshops and the sprint review. But we don't expect them to participate in scrum events like sprint planning, daily scrums, or sprint retrospectives. 

[00:14:21]: It's a similar story with system administrators, usually Microsoft 365 global admins or Power Platform admins interested in our application. We'll often need their help with things like environments and licenses and user accounts, storage and consumption, all that kind of stuff. But unless they have a significant amount of their capacity dedicated to creating increments during our sprint, then I don't consider system admins to be developers in our team. Just like architects, they are important technical stakeholders, and I'd invite them to the same events as the other technical stakeholders. 

[00:14:53]: Low code app makers, functional consultants, professional developers are the core of our scrum team. We're relying on their expertise and effort to turn backlog items into increments. Recently, one of my team's developers has led the effort to automate our work. They build pipelines, review unit tests, muck about with the YAML. They pack and unpack solutions and manage releases. But I prefer it when lots of developers can do that kind of work and the team doesn't rely on one person. I don't want our team to get stuck when our DevOps expert isn't available. I love it when we have a blended or fusion team combining team members from my Microsoft customer’s organization with my partner organization, and they're working side-by-side. This often results in a great combination of domain expertise of the customer's technology — their systems and data — with the broad experience of Dynamics 365, Power Platform, and Azure that my developers bring to the team.

[00:15:46]: Let's talk about testing or quality assurance in business apps teams. I find it incredible that in 2023, I still hear about separate testing teams, even separate testing estimates. I still hear about a group of testers working a sprint or two behind the developers testing the work from earlier sprints. I might be able to get my head around that if it was a transitional state maybe in an organization gradually adopting an agile approach. But it's an anti-pattern that I hope doesn't last long if that's one that you're seeing in your organizations. You can't get an increment into production without testing it. We know that testing is a fundamental practice in the development process. Unit testing, peer reviews, system testing, integration testing, and lots of other types of verification and validation should be included in your team's definition of done.

[00:16:37]: And the QA professionals that carry out this work should be considered developers in your scrum team. Increments need to be tested, and they need to meet all the definition of done within the sprint before they're declared done, not they've done this sprint and then tested and done-done next Sprint. If you're building simple apps and there are only a couple of developers in your team, you might not have a dedicated QA professional — a person who has ITQSB qualifications, or something similar — but your increments still need to be tested before being considered done. And we're always rubbish at testing our own work, so get another developer to verify whether or not your increment is done. 

[00:17:17]: Let's circle back and talk about change managers a little bit. Are change managers considered developers in your scrum team? For the first ten years I built business applications, there were no change managers anywhere near our applications, let alone part of our teams. Then, I started to see change managers become involved as stakeholders in our applications. That seemed to result in better outcomes. They provided valuable feedback about a disruption that a business process change might make or even a simple terminology change could make. They also began to communicate our progress outside the sprint review and ensure that all of our stakeholders and users had greater transparency into our progress building the new applications. They would arrange town hall-style demonstrations, smaller focus groups, and they would begin to prepare communication and training plans.

[00:18:05]: On a couple of recent projects, one in particular I can think of, the change manager was part of our scrum team. There were product backlog items that the product owner expected the change manager to get done. They weren't Dynamics 365 features, but they were increments that the organization would find valuable and the work was tracked in our sprints just like any other. It was an interesting, and I have to say, largely successful experiment. I'm keen to repeat it in future projects, but I don't have enough evidence yet to say which is a better practice: change management should be considered developers in our scrum team or change managers should be considered stakeholders slightly outside it. Either way, when it comes to resourcing the change management role, I think your change manager can come from the Microsoft partner organization often known as a customer success manager, or the Microsoft customer organization, where they're sometimes known as a nusiness change manager. Or if you don't have capacity in either organization, you could always hire an independent change management professional if that's what you need to do. What I have found is that as a delivery manager, I'm not part of the scrum team typically. I'm in the background pulling levers. I'm trying to figure out who's going faster. Do we have enough requirements for the developers? If we don't have enough requirements, we've got to add another analyst. Are we able to keep up with the testing? We can't keep up with the testing. There's a backlog of items built up at the back of the board. We're going to have to add another tester. And so I'm constantly balancing the resources in our scrum teams, particularly around the developer roles. 

[00:19:36]: Okay. We've covered the product owner and the developers. The last role in our scrum team is, of course, the scrum master. What's the most effective way to resource the scrum master role? Like some of the other roles, my perspective on the best way to resource the scrum master role has shifted over the years. If you're reasonably new to building business apps with Scrum, I hope you can shortcut decades of trial and error and benefit from some of my experiments. I've been responsible for building business apps from the Microsoft partner perspective. I haven't sat in the customer's seat yet at any rate, and I used to feel the pressure and responsibility of providing a team, included providing the scrum master. After all, the scrum master is the coach and guide for the scrum team. I couldn't risk having an unknown, untrusted person coaching my team. There was too much risk that they'd turn out to be a terrible scrum master and the team wouldn't deliver on expectations, and we'd get sued into oblivion. 

[00:20:37]: These days, I'm a little bit more relaxed about it. I'm happy to work with my customer’s scrum master or even an independent consultant as the scrum master. Here's why: the scrum master isn't accountable for coaching the developers. The scrum master is accountable for coaching the developers and the product owner and the organization in the successful adoption and application of scrum. Sometimes, a Microsoft partner’s scrum master is amazing at coaching the developers. They work for the same organization and have the same loyalties and goals, after all. But the partner's scrum master doesn't have the same level of trust with the customer's product owner or the rest of her organization. That trust might develop gradually. The partner's scrum master and the customer's product owner can, in the fullness of time, as they say, form a tight connection that creates amazing results.

[00:21:30]: But the scrum master in these situations rarely has the mandate to coach the rest of the customer's organization in the adoption of scrum. In fact, any effort to do so might be seen as meddling or outside the agreed statement of work for the business applications project. It's a very fine line to tread. If instead, the customer provides the scrum master, then I'll sit on the sidelines as an interested observer and make sure that the coaching is effective, and our developers and the product owner are being supported appropriately. I reserve the right to have a word with the scrum master or even to escalate it to the sponsor if I see things going off the rails. Recently, we worked with an independent Scrum master from an agile consultancy appointed by her customer to help us deliver a Power Apps application, and that was awesome. She had far higher levels of trust and influence within the customer's organization than we had, and I hope that our team's five years’ experience working together as a Scrum team made her job pretty easy. I've heard of Microsoft Partners hiring independent scrum masters where they don't have someone available, and that's been successful too. So whether the scrum master works for your customer organization or the partner's organization doesn't seem to influence the outcomes one way or the other.

[00:22:43]: I'd be interested in your feedback. What's worked for you? Have you seen any resourcing patterns that you think that other teams should avoid or adopt? I'd love to know what's been working for you. If you have any questions or feedback or would like to join me on the show to discuss resourcing or anything else about building amazing business applications, you could email me at neil@customery.com — that's Neil and the word customer with a Y on the end, customery.com — or you can reach me via LinkedIn. Until then, keep experimenting.