Monthly Archives: October 2018

Breaking SCRUM

 

Here is a Scrum-related problem which I’m sure has been discussed before and will be discussed again.. so it’s just me thinking out loud.

We have developers, we have testers, and we have business analysts on the team. Our product owner is not a single person but a group of people where various stakeholders come and go. And, yet, we are still trying to do scrum.

To start with, why are we trying to do scrum? I think that’s because scrum is offering something.. it’s almost like a promise.. a promise of bringing some order to the chaotic process we used to follow before. With its product backlog, sprints, product increment, and well defined timeboxes, it seems to be just what we need.

And, then, well-defined scrum theory collides with the reality – we don’t have a single product owner

image

We were not given one.

I think that’s the single most important problem any Scrum team could have, and I am wondering if there are, really, Scrum teams that don’t have itSmile Really, I can only salute the organizations that understand the importance of this concept.

Instead of the product owner, we have to have a few business analysts constantly chasing different SME-s for the requirements. This is not unusual, sometimes those business analysts are called proxy product owners.

But, of course, the idea of having a single product owner is all about having a single point of contact and a single product authority on the Scrum team. When we have so many people responsible for the user stories, the whole thing is turning into a bit of a zoo quickly.

There are questions all around – for example, as a member of the dev team, am I supposed to ask the BA or am I supposed to ask the SME-s when I have questions about the user story? Anyway the BA-s will likely have to confirm the answers with the SME-s, so why not to ask directly? But, then, the BA-s might find themselves a bit out of the loop, and there is a reason they need to be aware of all those discussions – developers can’t just start chasing all the SME-s, there has to be at least some order.

Actually, are we supposed to treat business analysts as members of the dev team?

My personal opinion – we probably should not. Sure they would be members of our scrum team, but not the dev team, right?

Well.. On the flip side, what is right for the product owners is not necessarily correct when it comes to the BA-s. Just like, from the dev team standpoint, BA-s are representing the product owner, from the SME-s standpoint BA-s are representing the dev team. And they can’t do it unless they get involved into the dev team discussions etc.

Then how far do we get it? Should the business analysts participate in the estimation exercises? It’s a bit of a stretch if they do, since they really don’t have much to say as far as development/testing is concerned, but, on the other hand, if they go back to the client to discuss those estimates.. they have to be prepared. It’s hard to be a proxy.

See, what was, once, a well-defined framework, is quickly becoming a set of assumptions, questions, and workarounds which we have to come up with to accommodate just a single change in the framework.

Which is, we don’t have a dedicated product owner.

So now I’m wondering.. would it be possible to sort of turn a BA into a product owner? To make the Scrum whole again? It would definitely be a challenge – business analysts will have to become much more familiar with the business in this scenario, but, as a result of this transformation, a lot of communications and decision making on the project might become much more simple.

It is not for the Scrum team to “raise” a product owner, though, it’s for the organization to do. Did anyone try doing this?

“Share/Unshare” Relationship Behavior – something to keep in mind when working with the hierarchies of records

You might be creating a number of new entities, all related to each other through a hierarchy of relationships, and, then, you might have to set up security so that, if a user were given permissions to the top-most entity in that hierarchy, that user would also get access to the other entities.

Imagine, for example, that you had a Parent and a Child entities like this:

image

And the security permissions for regular users are set up like this:

image

image

So the users can do whatever they want with the records they own, but they can’t even see somebody else’s records. The record above was created using a system admin account, and here is how a user having only “user-owned” read permissions can’t see any of those:

image

So let’s say the system admin decides to share that parent record with the user:

image

The record shows up:

image

But there is still a problem – the user can’t see any of the child records:

image

Remember there were supposed to be two kids there?

And of course they would not show up since we only shared the parent record, so all the child records would have to be shared with the user separately.

Is there an easier way to do the same?

This is where “Share/Unshare” properties of the relationship behavior might be very useful. By default, you will get “Referential” behavior there which will look like this:

image

What if we change that to “Configurable Cascading” and update “Share/Unshare” to use “cascade all” instead so it looks like this:

image

Save, publish all.. Re-share the Parent record(may have to actually un-share, and, then, share).. ask the user to reload their “Parent” screen, and, lo and behold, those lost kids have just been found:

image

Most importantly, those Child records are not shared directly with the user:

image

It’s all taken care of through the relationship.

And why is that important? Because there are all sort of scenarios where this can come into play. For example, consider the access teams. You can create an access team template for the parent entity only, and, if the relationships are set up as described above, just by adding a user to the parent record’s access team, you will grant that user access to the whole hierarchy of records without having to do it individually on each of those records.

Entity Relationships in the Business Process Flows

There was an interesting story today which came out of the It Aint a Problem experiment.

Basically, a question came in with an example of a business process flow which looked more or less like the one below:

image

There is a branch in that BPF – basically, if there is an existing account, then the BPF is supposed to skip account creation, and, instead, there is a stage where a contact will be created/updated. So the question here was why, when navigating to the final stage, we can’t choose the account and we have to create it instead? Even thought that contact has “Company Name” field populated with the correct account already:

image

Actually, I did not get it, at first, what the problem was and it took me a little while to even understand what we were trying to do. Then I was confused – indeed, why is it not showing up? Especially since, when using the other branch (where the account is already there), we can go smoothly from one stage to the other:

Pick the contactimage

Then go back to the account – no selections are required

image

Turned out it’s the story of relationships – it’s all about who is the parent, and who is the child.

Those two branches are working off the different relationships which may not be obvious when looking at the BPF definition.

The “normal” branch is using the following relationships/lookups:

  • From leads to accounts: Origination Lead
  • From Accounts to Contacts: Company Name
  • From Contact to Accounts: None (to use the account that’s already linked to the process)

So, in this scenario, Account is the “parent” and Contact is the “Child”.

In the alternative branch, however, the contact is linked to the process first, and, then, there is a “switch” to the account. That switch is supposed to happen over a certain relationship/lookup, but, in that case, since the Contact is already linked to the process, it’s the Account that is the “Child”. So the relationships are different this time:

  • From leads to contacts: Origination Lead
  • From Contact to Accounts: Primary Contact

Here is how it looks like in the BPF definition:

image

So, once there are a couple of account that have this particular contact set as a primary contact, it all starts to work as expected:

image

And what is the takeaway? When we have a business process flow with different branches(actually, this may probably happen with just one branch, too), the same entity can be added to different stages. So we might intuitively expect to see the same selections whenever we are switching from a different stage to one of the stages for that entity. However, the business process flow might be using different relationships in those cases so the selections may end up being quite different.

It Aint a Problem – a simple offer for anyone having questions about Dynamics

 

imageWhat kind of questions do you have about Dynamics? Are you about to start a new trial to evaluate what’s doable? Are you facing a technical/functional issue where you are not sure how to do something? Is there a tricky security question that’s bothering you? Is there a plugin that’s not working as expected?

Whatever the problem is, I have a simple offer for you: let me have a look at it and see what can be done.

And if you wanted to ask what it’s going to cost you, here is the kicker.. it’s free. As in absolutely free.

But no worries, there is certainly a catch – I have a few conditions:

  1. Whatever the question/problem is, it should be related to the online environments, and it should have an element of a problem in it. In other words, it should be something that cannot be easily answered just by looking at the documentation or by asking Google
  2. By allowing me to look into it together with you, you are also giving me permission to blog about it. Which may mean I’ll be taking some screenshots, but I’ll certainly remove all sensitive data from those screenshots before posting them anywhere (and you can choose whether I should be mentioning any names or not)
  3. I cannot guarantee my unlimited availability, so it’s all going to be based on the “best effort” approach. I can choose to say upfront that I’m not interested, I don’t have time, I have 5 hours, that we need to have a look at it first, etc
  4. Last but not least.. I’ll certainly be doing this in good faith, but things happen. You won’t hold me responsible for the possible loss of data and/or for any other problem that may arise as a result(or as a perceived result) of us looking at it together

 

Is it a fair offer? Get in touch and let me know what you think