Success with Scrum for Dynamics 365

Hi, I'm your host, Neil Benson. Welcome back to the Amazing Applications podcast. This episode was recorded from User Group Summit EMEA in April 2018. The conference was hosted that year in Dublin. I remember it well. Flying from Australia to Ireland. I met up with my dad, we had a lovely dinner. And George Dubinsky and Leon Tribe, and I shared a house in Dublin for a few days for the conference. We had an amazing time. 

At the user group conference that year. I presented a talk called Success with Scrum for Dynamics 365. And this is a recording from that presentation. You'll find show notes and a transcript for this episode at AmazingApps.Show/5. Thanks for listening.

 Welcome everyone to this session on success with Scrum for dynamics 365.

My name is Neil Benson. I'm the director of customer engagement at KPMG in Australia. I actually grew up in Northern Ireland and I went to university. I spent 12 years in London and then three years in Los Angeles before moving to Brisbane about three years ago. So sorry about my accent. It's pretty stuffed up.

Any introverts in the room can follow my content using those channels on the left of the slide. And then the extroverts can contact me using the methods. All right. The learning objectives for this session are what is Scrum? What are the benefits of Scrum for dynamics 365? And sure. Some of my lessons learned in the field from my dynamics 365 projects over the last 10 years or so.

I've been working with CRM software for about 20 years with an IMAX CRM software since 2006. And with Scrum since 2009, I'm Scrum certified by the scrum Alliance and Scrum dot org. So, first of all, what is scrum? Scrum is a framework within which we solve complex problems while delivering valuable products.

It's important to know that scrum is a framework. It's not a complete methodology. C compliments Scrum with technical practices for dynamics 365 product, right. I know Scrum, isn't really limited to software projects. Scrum is used in all kinds of industries to deliver results and improve how we work. So this is Scrum on a single slide.

A person called a product owner has a vision for the software based on Microsoft dynamics, 365 dynamics 365 is going to be implemented by cross-functional self-organizing development team. And the scrum team is coached by the scrum master. Everyone else with an interest in the project is a state. We capture requirements in a prioritized list called a product backlog.

And we call the requirements, product backlog items and Scrum dynamics. 365 is implemented and time-box iterations of work called a sprint that have between one week and one month long. The first workshop is the sprint planning workshop and the scrum team decides which items to work on during the upcoming sprint.

And that's the sprint backlog during the sprint, the team syncs every day for 15 minutes called the daily stuff. And at the end of the sprint, they review their progress by demonstrating an increment of working software, to the product owner and to the stakeholders in the sprint review workshop.

Afterwards at the sprint retrospective, they inspect and adapt their practices to improve their efficiency and effectiveness sprint over sprint. And at the end of each sprint, we should have a new product increment. Those are dynamics 365 enhancements to the product owners could release into production.

The organization can keep the sprints going as long as they value being delivered. Each increment is greater than the cost of the scrum team. Underpinning, all of this is in parasitism. That's the scientific theory that we need to keep measuring, inspecting and adapting what we're doing. In fact, transparency, inspection and adaptation are the pillars of scrum like commitment, courage, focus, and openness are its principles.

Let's have a look at some of the benefits of Scrum for dynamics 365. Let's have a look at the Scrum benefits for dynamics customers from a product owner's point of view. First. I think there's five or six of those. They are better dynamics, 365 software faster release cadence, better return on investment, higher customer satisfaction, more visibility and confidence.

And number six less risk. I think we get better dynamics 365 software because Scrum results and better quality software that more closely meets your user's most valuable requirements. Secondly, we get a faster release kids. You can deliver your first dynamics, 365 release, much quicker. Than a traditional project methodology, because the benefits realization happens much earlier.

Number three, a better return on investment, where you get a higher return on investment, because your benefits are being realized earlier. And because Scrum projects cost 30 to 40% less than projects. Following traditional methodologies, you get higher customer satisfaction because Scrum embraces earlier feedback from your stakeholders and delivers features collaboratively with them.

So there's greater involvement and hopefully that leads to greater status. You get more visibility and confidence because project sponsors and stakeholders have got more visibility of the progress in a Scrum project. They can come along to any of our meetings and hear the risks and issues that we're discussing, and that provides them with greater confidence.

I think you get less risk because of those frequent opportunities for inspection and adaptation that ensure we're building the right solution. And from the point of view of your dynamics teams, there's another three or four benefits. Scrum teams have got more control because they're self-organizing. So teams have more control over the work that they do and how they do it.

They get empowered collaboration because Scrum encourages team members to work closely together and directly with users, rather than working through a requirements specification document, we measure what matters and Scrum, the methods that scrum teams use to estimate complexity, track their progress and make decisions are different and often more accurate than traditional methods on sequential.

And they're just more fun. I find that people who work on scrum teams are happier because their jobs are satisfying and rewarding. That notion of self management puts decisions that would normally be made by a manager or someone else in the organization, into the scrum team. Members' hands. And we have more fun in the project.

Let's have a look at some of the lessons I've learned for some of my Scrum projects over the last couple of years. First of all, for product owners, I probably owner needs to be a leader. That's somebody with a vision. Uh, for high dynamics has going to satisfy the business challenge. They need to have sufficient decision-making authority.

And then do you have good people skills? They need to be a domain expert. That's in their industry, within the organization. They need to understand the stakeholders and some of their politics, and they don't understand what the users need from the system as well. And they need to be somebody who's accountable.

That means they're committed to the project they're responsible. And one of the hardest factors of all is. The good product owners are available three to four days a week on the project. So some of my lessons for pet owners use proxy product owners. If you have to. So proxy product owners, anybody who the product owner has delegated some of their responsibility to that could be a business analyst.

Who's going to help write those product backlog items. It could be a test analyst. Who's going to ensure that the finished work meets the acceptance criteria that the product owner has set. It could be a change manager. Who's going to help communicate change throughout the organization. Or it could be a project analyst who's going to help with things like risks, budgets, resources, and managing issues.

My second lesson is to never have a committee of product owners. If you have two product owners, you really should have two product backlogs and two scrum teams trying to share the product owner role between two people really doesn't result in very successful projects, the development team. So we said earlier on the development teams cross-functional and self org.

So cross functional means that they've got all the skills that they need to do their work. They're not relying on outside team members and they've got those skills inside the project team if they need them. And they're self-organizing so they don't need a project manager or somebody else to assign work or to manage their work.

They get on and do it themselves. And Scrum a development team. Everybody's called a developer inside that development team. That doesn't mean you're new, you're a.net developer or coder, or you're a programmer or anybody who's developing features in the product. And we call them the developer in Scrum.

So take that George Dubinsky, successful development teams. I think I've got a couple of factors. Like they take collective ownership for the results. They should all feel responsible for the quality of this. And as far as possible, understand all of the system and get involved in all the activities. So they shouldn't be just specializing in one part of the system or another, and then should get involved in analysis, design development, testing, and deployment development teams have three to nine committed developers.

So I think any smaller than three, and you're really too small to be cross-functional you probably don't have all the skills in such a small. And in the larger team, the communication and coordination just gets too hard and people get left behind and the scrum teams too big at that stage. So 3000 members, that's the sweet spot.

I call them committed because the best scrum teams are made up of people who aren't sharing their time across other projects. They're committed to this one and they're not working in any kind of business as usual or support tasks for product X. Scrum master it's called master as an expert in Scrum there to serve the product owner, the development team, and the organization by helping everybody to understand and embrace and apply Scrum to your dynamic sixty-five project.

So that person needs to be an expert in Scrum. I don't think you can take a two day scrum training course and be a scrum master and come back and coach a scrum team. You probably need to have spent a year or two working in a scrum team before you can be at school. They're a great coach. So great coaches ask leading questions instead of providing definitive answers.

And they know when to know, they know when to hold the team's hand and when to let them run free, they've got great people skills and they're good at resolving interpersonal conflict. My, um, my advice here is to hire an expert. If it's your first scrum team or first scrum project, and don't send one of your script project managers off on a course, hire somebody with experience and have them coach your teams.

First project. You can, if you need to combine the scrum master and developer roles on a smaller team, but please don't try and combine the product owner and scrum master roles in a single person. There needs to be a natural tension between the product owner and the dev team to get the most out of Scrum.

And there needs to be complete trust between the dev team and the scrum master. So it's best to keep those roles, separate stakeholders, stakeholders, everybody else that could be the project sponsor. It could be a head of a department. Um, anybody who's got an interest in the product. They provide the requirements into your product backlog and they can observe your scrum events, particularly the sprint review.

We want to invite them along to that. And sometimes they, they stand in and observe our daily scrums, but they should not be active participants except for this. Be transparent with your stakeholders, make your product and sprint backlogs visible. And if they're electronic, makes sure everybody else has got a login for those systems, encourage questions and stimulate feedback, demonstrate your progress and be open and honest about any issues or risks that you're facing or anything that's blocking progress.

One of the stakeholders is probably the right person to help you unblock that impediment. Don't let stakeholders control the product, honor that product. And like I said earlier, it needs to be somebody with sufficient decision-making. If they keep having to go back to a senior stakeholder to get decisions, then it's a good sign that the product on there, it probably isn't the right person, stakeholders can influence and lobby and they can request features.

But if they're controlling the product owner and demanding features, then again, you've got the wrong person in the next one. I'd take a look at deliverables. There are three deliverables. Scrum. The product backlog is the first one and it's the list of all the possible requests. Those requirements are prioritized only by the product owner and nobody else.

Technical practices, a compliment Scrum. Um, I use user stories and user story mapping for describing our requirements and getting a big picture of the, of the system. And then I use story points and planning poker for estimation. I don't recommend you use cases. They're too long. I'm too technical or writing or publishing requirements specifications.

That's a throwback to a waterfall mentality. We wanted the product backlog to be agile, meaning it can change often. And that can happen when we have to write everything down and publish it and get it signed off. The sprint backlog is the second Scrum deliverable. It's a slice of work that the team has committed to delivering.

It's a subset of the product backlog with a plan for how the work's going to get done. Usually we've got some design ideas. We've maybe got a few tasks outlined and that sprint backlog is summarized by our sprint goal. That's the overarching goal for the sprint that we're going to try and achieve. My advice here from, from a lessons learned on my projects is to be negotiable about the sprint backlog with the product owner will cover that a little bit more later on and that's during the sprint review event, but commit to it for the duration of the.

And resist the temptation to change it. That's really up to the product owner to try and make that commitment. The team's going to commit to delivering all of the items in the sprint. The product owners got to commit to not changing it. And the developer one team gets to decide which items they're going to work on and how those are going to be delivered neither of the product owners or the scrum master.

Any stakeholder should be deciding exactly what goes into the sprint backlog or how it's going to be get delivered or what they estimate should be for each of those items. And the last deliverable. Is the product increment. So the product increment is a set of enhanced features of dynamics 365 features that are ready to release into production.

My advice, I use two types of solutions. I call them item solutions and release solutions. Item solution is a solution package in dynamics 365 that contains just a solution components required to meet one single requirement. That could be just a single field, or it could be a form or a view or. A really solution then is a combination of all the items solutions that have been successfully tested and packages them up ready for deployment into production.

You can use managed or unmanaged solutions depending on your preferences and your product increment needs to be ready to release into production. You don't have to release it into production at the end of every sprint, but I definitely encourage it. And that's up to your product line when they want to do that.

So let's take a look at scrums events. There's five events that we're going to cover off this afternoon. First of all, those is a sprint. So sprint is a timeboxed iteration of work. When we turn ideas into features, we do all the analysis, design development, integration, testing, and deployment, and every sprint, the Scrum Guide says a sprint is between a week and a month long.

My advice based on trying lots of different durations. Either use two weeks or three weeks sprints one week can work well for short projects, like proof of concept projects. We need rapid feedback, four weeks or one month long sprints. Just take too long to get ideas into place. Um, th this time taken between an idea and the working software is two grit and two or three weeks sprints.

My teams concentrate their development effort during the first two thirds or so on the last third of the sprint we're testing, documenting and deploying our sprint into production. And we're also researching and analyzing items from the product backlog that we're going to start delivering in the next.

Finally on sprints, don't use special sprints. I'm not a big fan of sprint zero or hardening sprints or testing sprints or integration, sprints. They're all just BS. We need to be delivering working software in every single sprint. A dare you try it. Sprint planning is the second event. Sprint planning is the first big event in every sprint and it kicks off the sprint for two or three week sprint.

It's probably a two or three hour long. It's purpose is to determine our sprint backlog. I encourage a practice called story time before sprint planning, Storytime, or short workshops between the product owner or the dev team and stakeholders to onlies and refine some of the high priority requirements just enough.

So the dev team can estimate them. Those workshops can take place in the sprint before our sprint planning. Being negotiable in sprint planning, the dev team needs to trust a product owner to prioritize the most valuable items and a product owner needs to trust the dev team when it selects which of those high priority items to work on the daily scrum.

So it's a 15 minute daily sync for the dev team to catch up with each other and find out what they managed to work on yesterday. What they're delivering today and any impediments that are. My advice is meet the same time and same place every day. Ideally, you're working as a physical team and that's, you're in a room somewhere in a project room, but it might be on the phone and it's not a status report for the scrum master.

It's not a status report for the product owner or any of the other stakeholders. Those people are welcome to participate. And the dev team is to make sure that they get what they need from that daily scrum towards the end of the sprint, we have the sprint review meeting. So it's a critical Scrum event for instance.

So we inspect the product increment and every sprint review. And then we adapt the product backlog in response to the feedback that we get. It's usually two to three hours. If you're running two to three weeks, sprints invite your stakeholders along their feedback is vital. Um, set up a recurring meeting in their calendar.

So everybody knows where it is and when it is never surprise your product owner and the sprint review, um, demo features that are completed during the sprint. If you can, you don't need to wait until the sprint review meeting. And it's ideal. If the product can actually demos features to the stakeholders, that's a good sign that the product owners has accepted them.

And that the product owner feels that they're finished and the sprint review should take, let the team less than an hour to prepare for. I remember some of my early sprint reviews, we'd spend like half a day preparing demo scripts and pushing stuff into a demo environment. It should really just take a few minutes, maybe, maybe an hour to prepare a run sheet and make sure the team knows who's going to demonstrate what does it's been retrospective?

This is the last meeting in each sprint. I think it's usually a short meeting. I try and keep it about an hour. And the purpose of the sprint retrospective is to inspect and adapt your processes. How you're applying Scrum to your dynamics. project. My advice. I like to make it a walking meeting, maybe not a lunchtime meeting, get out and have a picnic.

Um, Don't just sit around a table and have another boring meeting. Make sure you focus on the process, not the people. So we want to talk about, for example, test driven development, not hard. Batman needs to get his act in gear and regression test on his work. Take one or two ideas from the sprint retrospective and try applying those in the next.

Try not to change 10 things about the way that you work. Just take one or two of the best ideas and apply those in the next sprint. And there's lots of different sprint retrospective workshop formats. Try changing the format from sprint to sprint to keep your retros fresh. So last section in this presentation, I want to talk about a case study of an old project of mine at premier medical group.

This is actually my first Scrum project back in 2009. So hold a pretty special place. So premier medical group, they diagnose the injuries of people who've been involved in an accident that's really to support that person's insurance claim. Essentially what they do is they chase ambulance gestures. So this is Debbie she's, the operations director at premier medical group.

And her job was to chase the operation staff. It's just the doctors, it's just the lawyers. It's just the ambulance. Debbie sent my consulting company, a request for proposal for a CRM system to replace an insurance specific workflow system that wasn't meeting her requirements. This specification was only about 30 pages long.

My initial estimate for the implementation was about 900 days of effort to implement dynamic Sierra. And this is serum 4.0 back in the day for about 300 users using the wonderful official Microsoft dynamics. Sure. Step sequential method. The analysis and design phase took about eight weeks. I remember Dan and I were working on some lit lights on it.

I'm trying to get the final solution specification published. That was what 600 pages of requirements and design documents. Debbie wasn't really that happy with the document though. She thought it was filled with jargon, technical jargon about dynamics CRM. She thought some of the requirements were a little ambiguous and she didn't, although it was 600 pages long, she thought there was some bits that could possibly be.

So she wasn't confident that the specification was, was right at all, but it was too long. So go figure, but it's missing, but it's too long. And she thought it was gonna take too long to see working software. Um, I think we estimated about 18 months before the project would be finished. And the last, uh, three or four months of that would be spent in testing.

So she was going to have to wait 12, 14, 15 months before seeing any, any working software. She wanted us to be more agile. And given Debbie's feedback, I thought that Scrum might be a much better approach. It would provide her with prototype software every couple of weeks. It would give her control over the priorities and the scope and the timeline and the budget.

So it put her in the driving seat. So we formed our Scrum project. And 39 sprints litter. We delivered quite a lot. We had lots and lots of CRM Melissa's we built a custom portal before dynamics portals was available back in the day. And we delivered also custom offline client. So doctors could sync all the patient data and their medical files onto their computer and run their clinics with a internet connection less than a year after our first major release in.

But yeah. Premier medical group was acquired by capita and probably one of their reasons that their biggest investor in the mirror was able to attract interest from the blue chip capita was because of PMGs fully integrated. It led medical reporting system, which has dynamics, CRM for lessons I learned from the premier medical group of project.

Number one, find a fantastic product owner. I was really lucky to have had Debbie as a, as a person. That was the operations director. She's a senior enough to make the on behalf of the whole business and represent the board of directors. He was trusted by the rest of the board and she really knew the business back to back.

Our only challenge was Debbie's availability and we worked through a business analyst, Ben roles that Debbie trusted to make lots of day to day decisions for her. So lesson number one, find a fantastic point. Learn how to pitch Scrum. Uh, I learned the hard way, um, after Debbie had agreed that we switched to Scrum and ditch that big requirements specification, I was invited to pitch premier Medical's board of directors, which included an investor from new mirror capital.

So he asked a perfectly reasonable question and I provided the craziest answer that it makes me cringe when I think about it. But I'll share it with you so you can avoid money. His question was, if we're no longer going to use the requirement specification to test that you've completed the work, how will we know when you're done?

So I've heard similar questions since then from lots of other executives and procurement people, especially they're used to knowing exactly what they're going to get before the work starts. They're not used to a contract that says, oh, we're just going to send an awesome team and we'll do fantastic work that you'll prioritize.

So please learn how to respond to that question. Don't use my response, which was you'll know we're done. When you've run out of money. Number three, use a physical scrum board, our scrum master and the premier medical group project was Paul. So my, my company increased CRM partnered up with a bigger Microsoft partner who had more experiences Scrum.

So Paul Fox, he encouraged us to get together in a physical room. He stuck up some sheets of dry erase whiteboard film to protect the rooms wall. And he told us how to manage all of our product backlog items on sticky notes that we moved from left to right across the scrum boards, as those items were complete.

I've used physical scrum boards on several projects. And even on my biggest Scrum project today, we're using a physical scrum board as well as tracking items in aggregate management system that you can use JIRA or visual studio team services. If you're co-located highly recommend using a physical Scrum and lastly hire an experienced scrum master.

So my Microsoft, my small Microsoft consultancy at the time increased CRM. We'd no experience with Scrum. I'd read a few articles about it, but I certainly wasn't disclosed. So we partnered with cyber UK. They provided Paul Fox as our scrum master Paul wasn't a Microsoft CRM expert, but he was a really talented coach who not only helped us learn the mechanics of scrums events and so on, but he was able to help us absorb easily apply Scrum.

And it's principles of transparency, inspection adaptation. If you don't really understand and internalize the pillars and principles of scrum, you won't really be able to apply those, um, events and hit those deliverables. So if your organization or team doesn't have experience with Scrum, there'll be 10 times going to be a hundred times more effective.

If you go and hire an experienced scrum. I've got an online course, if you think that that helps, but great coaching from scrum master who's been there before is even better. I just want to say a big thank you to everybody on the PNG CRM project. Big thanks to Debbie Craig and the board of directors. Uh, Jason Paul, who's the CEO, Harry

Who's the chairman to share Ramalingam from Humira and the cyber team, especially Paul Fox and the awesome team at CRM, especially Dan. So that's it from me. Thanks very much for listening everybody. I hope you've got something out of that session today. If you've got any questions, I can ha happy to answer a few questions now.

Otherwise I'm just about to head to the calc bar. It's 81 Talbot street, which is a short walk from here. Uh, you're welcome to come along and buy a pint of Guinness and answer all your skunkworks. Thanks very much so that's it for another Microsoft dynamics, 365 user group summit. Thanks very much to Tony Stein and all the crew dynamics communities for throwing on another wonderful conference.

It was really good fun. Dublin is a home city for me, so it was great to come back to Ireland and meet lots of people met lots of people who listened to the podcast and I'm taking the scrum 365 training course so great to see all of you and my MVP friends to everybody here. Safe travels home, have a safe trip. Bye.

Thanks so much for listening to the Amazing Apps podcast. You can join the show's mailing list at https://AmazingApps.Show. You'll get a personalized welcome video from yours truly, and a notification when there's a new episode available. 

There are also shortcuts so you can follow the show on all major podcast players and you can follow Amazing Apps Show on Twitter, LinkedIn, YouTube, Instagram, and Facebook.

You can send me a message or a voicemail if you'd like your question answered on a future episode and even support the show through BuyMeACoffee or by buying an Amazing Apps t-shirt.

 Visit https://Amazing.Apps.Show. 

Thanks again for listening. I really appreciate you. Until next time, take care and keep sprinting!