Scrum Dynamics 31 - Scrum Disaster
Welcome to Scrum Dynamics episode 31 featuring a Scrum Disaster.
In episode 31, I'm going to try something a little different. I'm going to walk you through a Dynamics 365 disaster.
How do I know it was a disaster? Well, I was the practice director accountable for the project. And the project was terminated early by the client before it was released into production and we have to write off some of our consulting fees. By anyone's standards, that's a disaster.
My project disaster is not a disastrous CRM project like the one that Gus Gonzales discussed recently on the CRM MVP Podcast episode 52. It wasn't many years late and hundreds of millions of dollars over budget. It didn't end up in court. It didn't involve BSkyB or EDS.
Here are some other differences: it was a Dynamics 365 Customer Engagement project, strictly it was a model-driven PowerApps project except it was 2017 and we just called it XRM. It was run using the Scrum framework. And it didn't involve BSKyB or EDS, but it did involve me.
I'm going to let you know right now, that I'm taking accountability for the outcomes of this project. I'm not going to name the client, or any of their team members or any of my team members. The buck stops with me, and that wouldn't be fair.
But I'm going to tell you as much as I can remember about that project, and perhaps where I think it went wrong and where I should have seen the warning signs and intervened before the client cancelled it.
It started so well
In 2016 we won a competitive procurement process to deliver a major Dynamics 365 as part of a major CRM programme that would progressively roll-out over three years to a couple of thousand users. The CRM Programme itself was part of a multi-billion dollar, ten year strategic transformation programme.
For those of us directly involved in the multi-year, multi-million dollar CRM project, it felt like a significant piece of work, but in a portfolio of hundreds of projects, many larger than CRM, it was only a mid-sized initiative.
We started the CRM project with a 8 week proof-of-concept project. The idea was that the client could work with my team for four sprints to get to know us, to evaluate Dynamics 365 and make a go/no-go decision about us and Dynamics. The PoC went really well. In fact, the client extended it by a few more weeks and we released Dynamics 365 into production for a small customer care team that were facing an Oracle RightNow license renewal.
Based on several quick wins at the start, the engagement got extended and we continued for many sprints extending Dynamics 365 to meet the client's complex requirements and to integrate it with lots of internal and external systems.
About a year into the CRM project, and we got asked by the Finance & HR departments to help them out. They had embarked on a separate project to digitise some paper-based business processes. The client had a massive PeopleSoft system for finance and HR, but it was 10 years old, on-premise and a few versions behind. It's users had adopted workarounds based on paper and Excel for functions like getting hiring requests approved and submitting expense claims for reimbursement.
Those digitisation projects were behind schedule. Could we use Dynamics 365 and help get Finance and HR back on track.
Sure! Of course! Dynamics 365 is fantastic, and we use Scrum. Scrum will help you reduce projects costs, shrink timelines, mitigate risks, and have more fun delivering business apps that everyone will love. Neil Benson says so!
I didn't know the Finance & HR projects were doomed. I didn't imagine they'd get terminated. I couldn't foresee us having to write off our fees.
Here are the warning signs I should have seen.
Is it one project or two?
Finance & HR both wanted to use Dynamics 365. They both needed paper-based business processes to be digitised quickly, and all their processes ended up in PeopleSoft.
Other than that, they had very little in common. Separate groups of stakeholders, separate timelines, separate budgets, objectives and constraints.
I had seen this situation before. Two separate divisions or departments trying to run a single business applications project using a single Scrum team.
It very rarely works. I've only been able to make it work once before, and this Finance & HR project was a reminder that it's close to impossible.
I should have insisted it was run it as two separate projects, with two small Scrum teams. Even if each Scrum team only had three people, that would have been better than a single team of six people trying to deliver two projects at once.
How many forms?
I'd given the client an initial estimate of the effort and fees it would take to digitise their forms. Under pressure to complete the project to a strict deadline we skipped any kind of workshops to understand the projects' objectives, get to know our stakeholders, map their business processes or understand their requirements and draft a product backlog.
I had been given a list of about 30 forms to digitise. I had been given wireframes for some of them to illustrate what they should look like, and for the rest I was given a copy of the existing form. The forms weren't ordered in any kind of priority, there were no business rules or any other requirements provided. Just the forms.
I think I estimated it would take 10 two-week sprints. Off we went. Day 1 of sprint 1 and my team met the project stakeholders for the first time to try and elaborate the user stories for the first couple of sprints. What a terrible way to start a project.
I should have insisted on running my structured user story mapping process to launch the project. User story mapping provides project teams with a shared vision for the project. The development team gains an understanding of the user roles, business processes and high-level requirements. The requirements are laid out in two dimensions following the business process across the way and prioritised highest to lowest down the wall. After we estimate the complexity of the requirements and the velocity of our team the scope, timeline and budget becomes clear to everyone before we set out.
Starting a Scrum project with no backlog is no way to start a project at all. And I should have known better. Don't be like Neil on the Finance & HR Forms project, develop your backlog before you start sprint 1.
Where are we?
The client had lots of simultaneous projects running at once to support their ten year strategic transformation. Their buildings were filled with seconded staff, temporary staff, consultants and contractors taking up every available desk, meeting room, conference room and picnic bench.
Our Finance & HR Scrum team was shunted off to a large wood-panelled room and we were hunched over our laptops resting on picnic tables with power cords stretching in all directions. We shared the room with three other project teams running unrelated projects. The only thing we had in common with those other teams was a shared whiteboard on wheels. We spent quite a lot energy fighting to make ourselves heard. And, sometimes, fighting over that whiteboard.
The Finance & HR teams were located in separate buildings. We used to meet in random meeting rooms all over the place. But we never spent much time co-located together.
I'm a big fan of co-located Scrum teams. I've run remote teams and they can be successful too, but I find it best when my development team is co-located with the product owner and the people who will eventually use your business application.
I should have insisted on finding a co-located space. I did try to secure space at our consulting offices in the city centre. We had just moved into fancy new offices down town that had great meeting facilities. Anyone who's been to a Dynamics 365 User Group meeting in Sydney in the last couple of years will probably agree. But the offices weren't ready for long-term project spaces that could be shared with our clients. I've heard that this was possible about 18 months later, but it was too late to save my Finance & HR project.
If you try and shove your Dynamics 365 development team into a really unproductive working space, don't be surprised if they do the same with your Dynamics 365 system.
How many pixels to the left?
The Finance & HR teams had already had a crack at a custom development project to digitise their Finance & HR forms. They had engaged a user experience design firm to produce some very impressive-looking wireframes, and then a PHP development team to build a custom web application.
That effort was cancelled, before my Dynamics 365 team got the call. Actually, I'd love to know more about why that project failed. Next time I'm asked to recover a failed project, remind to ask a few more questions about why the last attempt failed!
Anyway, the PHP developers exited stage left but the user interface designers were retained. And in many ways they became the substitute for a single, visionary product owner with the domain knowledge to know the requirements and the authority to make product prioritisation decisions.
We did our best to work alongside the two or three very talented UX designers. But it was always an uncomfortable working arrangement. We were extending Dynamics 365 portals to try and meet their pixel-perfect designs but they expected pixel-perfect control from a configurable form-builder.
If I want to build a rich, immersive user experience for my customers then I'd choose a modern content management system: Wordpress, Sitecore, Adobe Experience Manager, Sitefinity. There are lots to choose from.
Dynamics 365 portals can integrate with any of those to provide an authenticated forms-based experience for customer care, communities, partner collaboration and lots of other scenarios.
But this wasn't an external, customer facing website build. It was a forms and worflow project for Finance & HR. The only external customers were job applicants, who could probably live without a pixel-perfect job application form.
Dynamics 365 is a solid choice for building HR recruitment and onboarding business processes. But we thought that Intelledox might be a better fit. Intelledox builds software for intelligent forms development and workflow and has a proven integration with Dynamics 365. But our client couldn't afford the length of time it might take to buy a more suitable solution. We had to build everything in Dynamics 365 Portals.
One of the user experience gaps in Dynamics 365 Portals was the lookup field. If you want to assign one of your expense items to an internal project or department, you needed to be able to search through very long lists of projects and departments. If you wanted to get your expense report approved by anyone other than your direct manager, you had to search through very long lists of staff with expense approval authority. Using lookups on a portal isn't a great experience. And it took us a couple of sprints to custom develop an autocomplete search field that filtered matching records from a set of 100,000 records as you typed.
We thought that was pretty good. But then the UX designers dropped the bombshell. The whole thing had to work on any employee's mobile phone. And they didn't have a standard corporate phone, so we had to support any employees' smartphones a few years old.
And with that bombshell, we doubled the estimated effort of all the finance forms.
I should have insisted that we stick to the strengths of Dynamics 365 Portals. They are a rapid application development platform for supporting your online interactions with customers, partners and suppliers. Portals are not a world-class content management platform.
Of course, today if you wanted to build a first-class mobile app based on Dynamics 365 you've got model and canvas PowerApps to choose from. And soon, you'll have PowerApps Portals as another option. But back in 2016/2017, Dynamics 365 Portals was our best option.
The client's expectations were not set in the right place. It was my responsibility to successfully realign those expectations and deliver the project, or walk away.
How many project managers?
When we started the HR & Finance Forms project, we were introduced to the Finance project manager, the HR project manager and the IT project manager. Three project managers is a lot for a Dynamics 365 project that's only going to run for a few months. In a Scrum project, there isn't a role for a project manager. They support the team with some traditional project management responsibilities like budget and contract management, and coordinating resources outside the team that the team needs to get their work done. But three. That was ridiculous. All it did was create lots of requirements for status reports.
Since I was based in another city and not on-site full-time, I wanted to find a full-time Scrum Master from within my consulting practice to help us out. Unfortunately, I didn't have anyone available in my Customer Engagement practice and wasn't allowed to hire more team members to support my team's growth. Other parts of our consulting organisation had hired too quickly and had people on the bench available for work. So I was given a very experienced project manager with a lot of experience running Oracle ERP projects, but no experience of Scrum or Dynamics 365 projects. And he because he was a director responsible for growing the Oracle practice, he wasn’t available on-site full-time either.
The left the client's three project manager to run rings around my team and drive them crazy.
The Finance and HR project managers eventually left the project and were both replaced with new project managers. That didn't help much. And just as the mobile bombshell dropped, the IT department replaced their project manager too.
The new IT project manager, to his credit, performed a quick assessment of the Finance & HR Forms project and terminated it. I had to agree with him that we should have done more to escalate the issues, call out the risks and stop trying to heroically save a doomed project, and we agreed to waive our unpaid fees.
The HR forms project limped on with a single consultant from my team working side-by-side with the HR operations manager and after a couple more months they were able to go live with a range of simple HR inquiry forms and case management.
Meanwhile the main CRM project went from strength to strength and delivered on all its expected outcomes for the client. So all was not lost, but I learned a very valuable lesson.
Have you ever had a project fail?
I remember the story of a venture capitalist who preferred to invest in entrepreneurs who had failed and had lost a business. The VC's rationale is that every entrepreneur taking risks and pushing hard will fail sooner or later. This VC didn't want an entrepreneur's first failure to use his money, so he only invested in entrepreneurs who had lost someone else's money, or better yet, their own money, on a previous venture. He figured that they'd have learned the lessons and would be a safer investment.
Maybe it's the same if your responsible for delivering successful projects. You're worth betting on unless you've learned the lessons from at least one failed project.
At least, that's how I console myself as I cry into my pillow thinking about my failed Finance & HR Forms project.
I hope you can learn some lessons from my experience. Perhaps you can relate to some of the critical failure factors: missing product backlog, unproductive working environment, using the wrong tool for the job and still expecting perfection, or too many project managers. I just hope you don't recognise all of them on your current project.