First of all, you can’t, really, change Scrum framework. If you do, it’s not going to be Scrum anymore. But, since Scrum is just a framework, and a lightweight framework for that matter, it leaves the details of Scrum implementation to the Scrum teams.
Hence, there is some room there for doing things differently, and that’s what I’d call fine-tuning the Scrum. In other words, it’s not about changing the framework – it’s more like this: what is it that you would recommend any Scrum team should probably start doing when they are dealing with Dynamics?
From my standpoint, we can play with at least two attributes of Scrum framework:
- Development team skills
- The definition of Done
As far as development team skills are concerned, it should not be too surprising that everyone on the team should probably have some familiarity with Dynamics and there should be someone who really does know how Dynamics works. The exact balance of the skills will depend on other factors, but, apparently, the more work is to be done on the Dynamics side, the more Dynamics experience/skills your team should have.
The definition of Done is something more interesting.
From my personal experience, I think there is at least one issue that often gets in the way of successful implementations. In Scrum terms, I’d call it the lack of transparency, and it manifests itself in two different ways:
- Out-of-the-box, Dynamics has a lot to offer. However, since the devil is, as usual, in the details, it’s easy to miss some of those details until they become a problem. For example, it’s easy to say that Dynamics is offering out of the box reporting, but what we should look into is whether that out-of-the-box functionality will cover what we need
- Out of the box, Dynamics has a lot to offer. However, that means there is a learning curve, and, more often than not, that learning curve is greatly underestimated. Problem is, we can say that we don’t need to implement search because there is Advanced Find, but how do we actually ensure that Dynamics users can use Advanced Find efficiently?
So, getting back to the definition of Done.. I guess it’s only fair to say that new functionality can only be “done” when and if it can actually be utilized. And that’s not only about the functionality having been implemented and tested – it’s also about that functionality having been explained to the end users so they can start it.
You might say Scrum includes sprint review sessions where the stakeholders have an opportunity to take a look at the releaseable increment. It certainly does, but this is where the complexity of Dynamics kicks in. We can’t walk the stakeholder through everything in those sessions. For example, if there is a new entity, are we going to demonstrate each and every search/reporting scenario that involves that entity? Most likely, we will just assume that the users know that part, and so we will be losing some transparency.
To work around it, we might want to incorporate a bit of documentation into our definition of Done to clarify, for the stakeholders, what are the limitations of our solution and what are the workarounds. And, looking at it from a different standpoint, we might want to make Dynamics training for the stakeholders part of our sprints. So the definition of Done would include something about “if we are relying on a certain feature in Dynamics, we need to ensure that the stakeholders know how to use that feature”. Which, in turn might mean that, for every sprint, the dev team will have to work with the stakeholders providing them the training they need.
That might be one option for fine-tuning.. Is there anything else you would do?