#130. Sprint 1 is a magical, wonderful, beautiful thing. Find out how my messy, unstructured and un-estimated sprint 1 unfurled on a recent project to build a Power Platform app for a mid-size Microsoft customer in financial services.
In-person conferences I didn't attend:
Upcoming online conferences I'm presenting at:
Learn how to qualify, pitch, propose and close more agile projects:
Tools we're using in sprint one:
Neil Benson: [00:00:00] G'day, and welcome to Amazing Applications. How you doing? It's good to be with you again. This is Neil Benson, and you're listening to episode 130. That means you'll find show notes with a summary and a transcript, and links to anything interesting I might say at https://amazingapps.show/130.
Welcome back. I've gotta admit though, I'm feeling kind of marooned here in Australia, a million miles away from all the fun you've been having at Power Platform Conference in the US, at Nordic Summit in Sweden, at South Coast Summit in the UK, and even the upcoming New Zealand Business Application Summit, which is only just across the ditch.
The closest I'm going to get, in the near future at least, is presenting at Power Platform 24, a virtual online conference that's coming up in a couple of weeks. It's gonna be great, I'm sure, but probably not as many hugs as all those wonderful in person conferences that are kicking off. Again, check out the link in the show notes to register for the free Power Platform 24 conference which kicks off on the 2nd of November.
I wonder if I should start organizing the Australian Power Platform Conference and get in on the action. Find some hugs. Hmm that would really be something, wouldn't it? I wonder. Well, I hope you had a chance to attend at least one of the recent in-person conferences lately.
While you were off enjoying yourself, I've had a couple of really busy weeks actually working. Yeah, my team just completed sprint one for a new project this week, and we're about to start sprint one for another new project for a different customer next week.
I've gotta admit I, I love sprint one. I love the possibilities, the enthusiasm, the optimism of that first sprint. Of course, that's a spirit that we try and maintain throughout all of our sprints right through to the first major production release and [00:02:00] beyond.
I thought I'd tell you a little bit about my sprint one just so you can see how it compares with some of yours. I've been using the Scrum framework to deliver business applications since 2008. That's 14 years ago now, and I've had my fair share of sprint ones in those 14 years. I've worked on several complex, enterprise projects that have run for one, two, or even three years, so you might have had more sprint ones than me if you tend to work on shorter projects. That's gonna be an interesting comparison. Let's see how you and I get on during sprint one.
The presales for this engagement started out much like any other. A prospective customer had heard about our reputation and asked us to complete an NDA, a non-disclosure agreement, prior to discussing their high level needs for a team to deliver a CRM project for them.
The customer is a mid-sized financial services organization with a couple of hundred users and they're currently using Dynamics 365 customer engagement app. It's owned by someone else. And, and the customer needs to build their own CRM app because of the constraints with the way that the current app is managed.
Owning their own app will enable them to make lots of enhancements their users have been asking for, for years. And, we're gonna be building lots of CRM features, but we're gonna be starting with probably naked Power Apps. I'm not sure if we're gonna end up with any Dynamics applications installed in this environment. That'll be an interesting one to watch.
But here's the kicker. The prospective customer had just finished a 12 week discovery exercise with another Microsoft partner, then invited us to submit a competitive proposal.
Many, many years ago when I took CRM software sales training with Onyx, this was known as "column fodder". The customer has probably already made up their mind about which partner they're gonna choose, but [00:04:00] procurement needs a comparison to evaluate the, uh, the incumbent partner against. Another partner -- us -- is invited to submit what I describe as a no hope and hell proposal.
If you want, find out how a scrappy startup competed against a global Microsoft partner that had already been working with the customer for three months and then fended off a third proposal from a national Microsoft partner at the last minute, and became the appointed partner, you're welcome to join my Winning Agile Projects masterclass, where I coach teams through my playbook for doing just that. You'll find out more. Uh, follow the link in the show notes to Winning Agile Projects.
We used a user story map to present the customer with a transparent and flexible plan for achieving their desired business outcomes. Our small and mighty team, we've each got, I dunno, probably 10 years or more experience in delivering Microsoft projects.
We've delivered many similar applications before and we reassured the customer that we'd be able to deliver their desired outcomes within their expected timeline, but we didn't actually provide any estimates for specific features in our proposal.
After a fairly typical round of contract negotiation, looking at the terms and conditions and all that good stuff, we agreed an initial phase of 17 two-week sprints for five full-time scrum team members. And I'm chipping in two days a week as a delivery lead if and when the team needs me.
Where're contributing a business analyst, a functional consultant, two pro developers and a senior test analyst. The customer is contributing scrum master -- which is a interesting arrangement; I'll come back to that in a moment -- a full-time product owner and a supporting cast, including a CRM administrator, enterprise architect, an organizational change manager and there's a bunch of subject matter [00:06:00] experts from across the different groups that will be using the new CRM application.
We've agreed the high level scope. Although, of course, the product owner can adjust that based on feedback from his stakeholders and any changes in business priorities. And we've provided an estimated cost per sprint for budget street purposes. But the actual fees that will charge are based on the actual hours recorded by us in our time sheet system during each sprint. We'll provide those time sheets at the end of each sprint along with our invoice to the GM of technology for approval.
All nice and simple. I love simple arrangements. No one enjoys the drama of complex, milestone based payments that we spend days trying to agree up front and then even longer trying to validate that they've been delivered or dispute than they're being delivered.
Drawn out payment terms or customers that don't pay until the third and final overdue invoice notice. Uh, I don't enjoy those at all. Simple arrangements enable my team to get on with delivering the application that the customer wants without wasting billable time trying to get paid.
If you work in delivery for a Microsoft partner organization, you might not be responsible for billing arrangements very often, but I know that delivery teams feel the pressure from their accounts payable department or from an account manager when payments get delayed. So is there any way you could avoid all that distraction just by keeping things simple?
I'd far rather build outstanding applications than chase outstanding invoices. Outstanding. What was the old joke? What did the farmer and the scientist have in common? They were both outstanding in their field. I know you don't listen to this podcast for the dad jokes, but that one's for free, so it's too hard to resist.
Let me tell you. Um, lemme tell you a little bit about the Scrum master and the product owner on first blush.
The Scrum master seems great. It's early days, but she seems to have done a great job [00:08:00] building a rapport with a new team. She's a consultant from an agile, uh, consultancy and a training provider. I think this might be her first Microsoft Business Applications project, and I'm hoping she'll bring some fresh ideas and fresh insights to a Scrum team that's kind of found a groove. I don't wanna say stuck in its groove, but they've been working together for four years, so they've got some established patterns and practices, and I think our new scrum master will be able to mix things up a little bit.
Our product owner, he's the current manager of the Dynamics 365 application, so he comes from quite a technical background and I've been impressed by his focus on his user's requirements and his ability to balance the competing needs of different stakeholders. We had one snafu where he went away and spoke to the architects and came back and said, 'Oh, we've discussed it and we're not gonna proceed with virtual tables, so your design has to not include virtual tables.'
Turns out there was a few assumptions made on behalf of the customer and uh, they hadn't, obviously had no experience with the virtual tables before. So we were able to set them straight and we've opened up that possibility, um, in the future. So gotta watch out for a technical product owner but all the indications are that we're gonna have a great working relationship in the future. So all looks good.
All the folks, in fact, that we've met from the customers team seem open and excited for the project. I'm really looking forward to getting to work with them over the next 16 sprints and beyond.
Here's how sprint one has played out over the last couple of weeks. We spent the first day with a product owner getting up to speed on the project's goals, the existing applications features, and discussing the high level scope for the project.
I, I had known some of this experience, um, writing the proposal, uh, and I had discussed it with the team, but that was a few months ago. So we're all just refreshing ourselves, getting back up to speed.
By the second day, we had a product backlog built in Azure DevOps, [00:10:00] and some items planned for that first sprint. I'd say it's a lot more fluid than our usual sprint planning event, which is pretty structured. The items we selected for this sprint backlog weren't estimated. Instead, we just relied on our experience to know how much work we thought we could get done in the next seven or eight days remaining in sprint one.
Our developers went to work setting up Dataverse environments and the Azure DevOps pipelines. Our business analyst and the product owner led an estimation session and we used story point estimation to estimate the relative size of those features in the backlog. Our tester started to work on the test plan, and I worked with the scrum master and the GM of Technology on a launch presentation for our business stakeholders that we held towards the end of, um, the sprint.
Presentation was in Miro which is a tool pretty new to me. I've done a few boards in Miro before, but using it for a presentation that was, that was fun. That project launch workshop replaced kinda usual sprint review event that we'd normally have with our application stakeholders towards the end of each sprint. The launch event included introducing the team, communicating our scope and our timeline, and our agile way of working.
We did have typical sprint review on day 10, but it was with the customer's project team, so the product owner, the scrum master, the organizational change manager, uh, those kinds of folks.
We reviewed some of the initial items in the backlog, which were a mixture of a few simple contact and account configuration changes. Nothing terribly dramatic there, and lots of nonfunctional deliverables like our draft data model, the ALM pipelines and the test plan.
The rest of the application stakeholders, I hope will join us in sprint two's sprint Review, and I hope they'll get more and more involved in verifying and validating Power Platform features during our sprints as well. I, I love when users can do acceptance testing during the sprint rather than deferring [00:12:00] that until just before we go live.
This customer's got an interesting application landscape that's taken me a little bit of adjustment, if I'm honest. They're not a typical Microsoft customer that uses Microsoft Stack from front to back. We've been using Azure, DevOps for our backlog, our board and our pipelines. But we're also using Atlassian Bit Bucket for source control and Confluence for our application's wiki. Like I said, we're using Miro for visual collaboration. I gotta remember to right-click and drag. That's a story for another day. Uh, we're using Slack for chat. We're using Zoom for meetings. We have got some SharePoint for storing documents and sharing those.
The customer's got a really experienced AWS cloud team, but this is gonna be their first real big adoption of, of Azure. So it's quite a menagerie of of new tools for most of my team and a new experience for the customers team as well.
One new tool I tried out is copy.ai. It's an AI tool that uses the same GPT-3 engine that Microsoft uses, um, to help you create more engaging writing. I thought it might be fun to try using Copy AI to create a more compelling sprint goal. So I asked Copy AI to improve upon our candidate sprint goal, which was something like, "Demonstrate contact management building blocks."
And it gave me suggestions like,
"How to make a contact management app in 15 minutes" Sounds like a Power Platform video you'd see on YouTube, or
"Contact management made easy". My favorite, I dunno where I got this one from.
"Trying to receive a gift on Santa's movie list".
So, uh, I've heard you can even use Microsoft's GPT-3 powered AI with Power Automate to build flows using voice commands. So if Copy AI is showcase for GPT-3, you know, good luck with that.
I can't even get [00:14:00] Alexa to. Thanks Alexa. I can't even get Alexa to play Spotify. Sprint one is, she's talking back to me.
Sprint one is pretty messy. It's intense. There's a lot of workshops. Um, it's probably one of the least productive sprints you'll ever have if all you measure is velocity.
But if you measure relationships, if you measure understanding, if you track empathy and believe in the, like I do, in the power and the majesty of a new project, then sprint one is wonderful. And I'm lucky enough to do it all over again with another new customer and another new project next week.
That's it for my Sprint one, for this new customer. Sprint one is done. If you enjoy this glimpse into my current project work, let me know and I'll record another episode in a few months and let you know. I'll give you an update on how both those projects are going.
If you don't enjoy this episode as much. You can visit my podcast website, https://AmazingApps.Show, where you'll find a link to my Buy Me A Coffee page and you can pay me to stop recording episodes like this one.
No donation is too small to shut me up. Otherwise, enjoy yourselves whatever sprint you're in and keep sprinting.