ScrumTeam1.jpg  

This is Scrum Dynamics. Hi, my name is Neil Benson, and you're listening to Scrum Dynamics. The purpose of this show is to help everyone use the Scrum agile software development framework to successfully implement Microsoft Business Applications. Whether you're implementing Dynamics 365 or the Power Platform, I believe that you deserve a perfect business applications project. Using the Scrum framework, I reckon you can slash project budgets, shrink delivery timelines, mitigate technical risks and have a lot more fun delivering software that everyone loves.

Just before we get into this episode, I'd like to give a quick shout out to two of the Customery Academy crew who recently achieved their Scrum.org Professional Scrum Master certification: Jackie Walker and Veronica Kamph.

Jackie is a Dynamics 365 functional consultant with Capgemini. She's based in Granish in Scotland. Jackie enrolled in my free Agile Foundations course in the middle of October and a few days later joined the Scrum for Microsoft Business Apps course. She achieved her PSM certification on the 9th of November. As well as her PSM, Jackie has also recently achieved a whole sleeve full of Microsoft Business Apps technical certifications. (You know, like in the Scouts when you sew your badges onto your sleeve. Well, Jackie's running out of arm room!) Well done, Jackie. You're an inspiration.

Veronica is the COO of CRM-Konsulterna in Stockholm in Sweden. (Gustaf, I hope I'm saying that right?). CRM-Konsulterna joined the Customery Academy with the team edition of Scrum for Microsoft Business Apps so that everybody in the company could take the course and prepare for their PSM certification. And on the 13th of November, Veronica became the latest member of CRM-Konsulterna to do just that. Well done, Veronica.

The topic for this episode is scrum teams, and the reason I wanted to cover this topic, although Dermot and I covered it way back in episode 6 (the development team) and again in 19 (optimising scrum teams), is that the composition and the characteristics of your scrum team remain fundamental to you having any success with an agile approach when you're implementing business apps.

Scrum team recap

Let's just recap the basics really quickly. In Scrum, all the work of turning your business aspirations into business applications is performed by a small team with a shared purpose that is self-organizing and cross-functional. Self-organizing means no one outside the scrum team decides what work the scrum team will do or how they will do it. And cross-functional means that this team has got all the skills they need to deliver a working application without relying on anyone else outside the team. There are three roles in the scrum team: the product owner, the development team and the scrum master.

The product owner is the single person that has the vision for your business application and is responsible for maximizing the value of that application. The primary way she does this is by managing the product backlog, which is a ranked list of all the possible things your application needs to do.

The development team is the group of three to nine business applications professionals who turn the product owner's aspirations into a working application. Like the scrum team, the development team is self-organizing. They determine how they will achieve the sprint goal and their cross-functional. So they have all the skills they need within the team.

The scrum master is a servant-leader who serves the product owner, the development team and the scrum master by helping them apply the scrum framework and coaching them to greatness.

While the scrum team is self-organizing, it works closely with lots of other stakeholders inside your organization. Your application’s users, their managers, the project's sponsors, your executive leadership. And, you know, fun groups like compliance, enterprise architecture, release management, operations, I.T. security and production support. Maybe even outside groups as well, such as your industry regulator or an industry body, your business partners, shareholders and often your customers.

That's the basics of the scrum team. A small but mighty group that's been proven to achieve amazing results. We've tried other configurations and arrangements, but in all our agile experiments, this scrum team has been shown to maximize flexibility, creativity and productivity.

Frequently asked questions about scrum teams

Slide1.PNG

I recently refreshed the content of the scrum team section in my Scrum for Microsoft Business Apps course. In this refresh, I added a new video which answers frequently asked questions about scrum teams. I thought it would be a good idea to share some of those FAQs with the Scrum Dynamics audience to give you a sneak peek into the kind of topics you'll find in the course.

Do we need to have three developers?

The first question was: do we need to have three developers?

According to the Scrum Guide, the minimum number of people in the development team is three. The rationale for this is that in traditional software development we find that teams with fewer than three people are often blocked because they are missing some necessary skills to develop and release working software.

So if you're taking the PSM certification assessment and you're asked about the minimum number of developers in a scrum team, then the answer is, you guessed it, it's three.

But if you're implementing Microsoft Business Applications, then the answer might not be three. In 2010, I was the only Dynamics professional implementing an asset management system at Guys' and St Thomas's Hospital in London. I made a significant amount of progress before Greg Owens joined me and doubled the size of our team from 1 to 2 people. And that was it. We went live with a new asset management system to help the medical physics team track the maintenance on all of the hospital's equipment in a few months with two people. There are lots of business apps projects where just one or two development team members can deliver working software into production.

Today you can build Power Apps, flows in Power Automate, develop Power BI dashboards or deploy Dynamics 365 Business Central, perhaps even Sales, Marketing, Talent or Customer Service into a small business with one or two people in a few weeks or maybe a couple of months.

If your application is really simple, however, you might need to adapt Scrum outside the normal rules so that you can deliver an app that everyone loves in a week by running one-day sprints. Is that really Scrum at that stage? Perhaps not, but it might work for you.

Can we have more than nine developers?

Second question: what if we have more than nine development team members?

Again, according to the Scrum Guide, the maximum number of people in the development team is nine. The rationale for this is that we find that teams with more than nine people lose too much productivity in coordination and communication. Progress slows down.

So if you're taking the PSM certification assessment and you're asked about the maximum number of developers in a scrum team, then the answer is nine.

I've delivered enterprise applications with development teams of more than nine people. And let me tell you, it gets really tough really quickly to scale one team bigger than about nine people. At the University of New South Wales, we had a team of eight Dynamics consultants, three or four testers from a third-party QA company plus three or four business analysts from UNSW. We struggled with a development team of 15 or so people for far too long before we split them into two teams. One team to develop features to engage future students and the other team to develop features to serve current students. Whoosh. When we finally split the team into two, we took off.

My current project at the Royal Automobile Club of Queensland is similar. We have almost 20 people in the delivery team plus a couple of DevOps engineers to help with release automation. We've experimented with two and three development teams, but we'd never attempt to operate as a single development team, although we do come together for joint sprint planning reviews and retrospectives and that's working pretty well for us.

Can we scale Scrum with multiple teams?

Question number three is related: How do we manage multiple development teams?

If you're deploying an enterprise application that's going to need more than nine development team members to achieve your intended business outcomes within your expected timelines, then you're going to need to scale your scrum teams.

There are several approaches to running enterprise-scale agile projects. I don't cover them all in detail in my Scrum course because it's designed to help prepare you for PSM certification. But let's cover them here for a moment.

  • Nexus is the scaled Scrum framework from Scrum.org. One of its co-creators is Richard Hundhausen, an Azure DevOps specialist and a former Microsoft MVP and Regional Director.

  • LeSS - Large Scale Scrum from Craig Larman and Basse Vodde users feature teams and other practices to scale Scrum.

  • SAFe - Scaled Agile Framework started by Dean Leffingwell, who was also the originator of the Rational Unified Process, is another option. Ken Schwaber, the co-founder of Scrum, is definitely not a fan of SAFe. You can find an article by Ken called 'Not SAFe at any Speed', but several huge software enterprises have jumped on board the SAFe train. You can go and check those on. I'll put links to those scaled agile frameworks in the show notes.

Can we combine scrum team roles?

Next question I get is about combining roles in the scrum team.

Sometimes I get asked, particularly by smaller teams that don't have sufficient resources, is: is it possible to combine roles such as scrum master/developer, developer/product owner or even product owner/scrum master.

Scrum master/developer

Let's take the scrum master/developer combination. In this scenario, when I'm asked that question, there usually isn't sufficient budget for a dedicated scrum master. So one of the experienced development team members steps up into the scrum master role while still trying to develop the product at the same time.

There are a couple of reasons why this isn't a great idea.

First, it's impossible for the scrum master developer to forecast how much capacity they'll have as a developer because they don't know ahead of time what impediments or issues might arise in the upcoming sprint that they'll need to deal with as the scrum master. Predictability of delivery is a benefit of using Scrum, and you're infringing on that by combining these roles.

What often happens is the scrum master/developer's stories don't get finished. So another developer has to try and finish them near the end of the sprint or the stories don't get done during the sprint and they spill over into the next sprint or we have to put them back on the backlog.

The other downside is that the person stepping up into the scrum master/developer role usually isn't an experienced scrum master who has operated in a scrum team as a dedicated scrum master before. Now, you're trying to embrace Scrum with an inexperienced scrum master who doesn't have time to focus on that role.

So the scrum master/developer combination is possible, a few teams have been able to make it work, but most don't. And it's not recommended.

Developer/product owner

The next combination teams try and operate with is the developer/product owner. The developer/product owner combination is theoretically possible, but it's even harder to execute than the scrum master/developer combination we just discussed.

The developer/product owner has a similar challenge of splitting her time between being a developer and being a product owner. How much time do I have to spend as a product owner and how much time is gonna be left for development? It's really tough for her to forecast her capacity.

There's also a conflict of interest in the primary responsibilities between interacting with the project's stakeholders and managing the product backlog, which are your product owner responsibilities, and working in the development team and delivering the product backlog as a development team member. This conflict usually makes the developer/product owner combination too tough to work in practice.

Having said that, I have seen it work in a couple of scrum teams. Usually, they're run internally within a Microsoft customer organization when they have a small scrum team building a simple app in just a couple of sprints.

Product owner/scrum master

The next combination is the product owner/scrum master and I'd recommend you avoid this combination at all costs.

The product owner serves the project's stakeholders while the scrum master serves the product owner and the development team. And his only responsibility to anybody outside the scrum team is to help the organization understand and adopt Scrum. I think it's impossible to serve two masters like that.

Often the scrum master is from a Microsoft partner and the product owner is from the Microsoft customer organization. Scrum has a beautiful built-in tension between these roles. That healthy tension is negated by trying to combine them. Don't do it.

Can scrum teams have part-time team members?

Question number four comes up is can scrum team members be part-time?

Is it possible to have a high performing scrum team with part-time players?

Yes, I absolutely believe it is.

In today's workplaces, we have people sharing jobs, working a few days a week, working shorter days, or having some other kind of flexible work arrangement. I love Scrum's ability to support our team members' working arrangements and still deliver a valuable product and happy team members.

Part-time contributions can work, usually under a couple of conditions. First of all, don't work full time and split your time between different projects. Being part-time on different projects is a nightmare. Your contributions to my business apps project are likely to become unreliable and then the development team is unreliable and unable to forecast its velocity. Out goes the dependability and the trust that we love in our scrum team.

If you're working part-time, share your schedule ahead of time with your team, ideally at sprint planning or before. It's no good declaring you've got next week off after the sprint has started and the sprint backlog is already planned and your capacity is built into that plan. But if you're gonna take off a couple of weeks to spend with your kids, or you need to care for someone, then let your team know your schedule so that you can forecast your capacity as a team together.

Secondly, arrange scrum events around your team members schedules. Ideally, we hold those comm events at the same time and every sprint and on the same day. But we can change it every now and again if we want to.

Part-time development team members are relatively easy to accommodate. Part-time scrum master or part-time product owner can be more challenging, but if it's known in advance and scheduled, then it is possible.

What doesn't work is a product owner who keeps missing scum events because of last-minute conflicts with her operational role or a scrum master who is neglecting your scrum team because of the challenges with another scrum team that they're also leading.

How can the product owner share responsibilities with the development team?

Question number five: How can the development team help the product owner?

The Scrum Guide says the product owner has five backlog management responsibilities: expressing requirements, ranking them, ensuring the development team understands them, optimizing the team's work and making the backlog transparent.

And the Scrum Guide also says the product owner is always ultimately responsible for backlog management, but she can share backlog management responsibilities with the development team.

So how does that work in practice in your Microsoft Business Apps projects?

In my projects, the product owner has had the toughest job of anyone in the scrum team. She must keep a team of hungry, chirping developers fed with elaborated user stories. But she also has to elaborate a vision for the product, a big picture, and keep all the stakeholders updated and as happy as possible. Even full-time product owners dedicated to your Dynamics or Power Platform project are going to need assistance.

Here are some of the ways that the development team can help:

  • By taking on the task of elaborating the product owners user stories, working with the subject matter experts across the organization to define the details and then splitting or combining or refining the cards for the other developers.

  • By adding acceptance criteria to the user stories, preparing test cases, executing the test cases when development is complete so that the product owner can accept the story is done knowing it meets our quality standards.

  • By communicating progress with the users, demonstrating new increments of the application to them and soliciting their feedback. Preparing for and planning the releases into production and for user adoption.

  • Or maybe by tracking project budgets, risks and issue logs, decision registers and preparing reports and presentations for governance groups.

What I've just described sounds a lot like the work of a business analyst, a quality analyst, a release or change manager, and a project analyst or project manager.

But the development team members don't have titles. We might have specialist skills that allow us to help the product owner, but we don't want to fall into the trap of thinking: you must be a business analyst in order to update the product backlog.

If you're a product owner has got a lot of assistance and you've got a large development team, just make sure that you've still got one single person who is accountable for and responsible for the product backlog. You don't want a committee of product backlog owners that negotiate and approve the backlog.

If you've got more than one product owner because you're implementing your application in multiple divisions, then consider splitting your application into two, or have to scrum teams working on the application with one chief product owner, or release the application sequentially in each division with a different product owner for each release.

Can we have blended scrum teams with people from different organisations?

The last question I often get is: Can you blend people who work for different organizations into a single scrum team?

Yes, absolutely you can. I've worked on several successful business apps projects involving two, three, or four different organizations coming together to form scrum teams.

Back at that project at the University of New South Wales, the product owner was a contractor. She was supported by three or four business analysts who were a mixture of contractors and UNSW staff. The development team and the scrum master were from my organization, a Microsoft partner's consulting practice, and there were three or four testers from a third-party QA specialist. Our stakeholders included staff from across the university and some other I.T. consultants from third-party organizations too.

That project delivered amazing results and has a case study on the Microsoft web site: Cloud and CRM graduate with flying colours for UNSW, transforming campus experience and boosting efficiency.

My current project also has a blend of the client staff, lots of contractors, a third-party QA consultancy. There are over 100 people working in the program and it's gone really well so far. We had a successful initial release into production in July and we're anticipating another next May. [KNOCK! KNOCK!] Touch wood. And again, it's already a study on the Microsoft web site: RACQ award proves customer experience leadership.

As we wrap up, I hope you find this scrum teams episode useful. You can find out lots more about scrum teams, including the product owner, the development team and the scrum master in my Scrum for Microsoft Business Apps course. You can see a preview of some of the lessons by visiting customery.academy.

If you've got any questions about how to organize your scrum team for Dynamics 365 or Power Platform projects, you can send me a voicemail by visiting customery.com and clicking on the 'Send Voicemail' button on the right-hand side. That's a really good way to get featured on the podcast. Or you can join our LinkedIn group, Scrum for Microsoft Business Apps.

It's almost the summer holidays here in Australia. I'm going to be taking a few weeks break from the podcast. I'll be back in 2020 with lots more Scrum Dynamics episodes. So remember to subscribe in your favourite podcast player. Keep the questions coming. Keep sprinting. Bye for now.