Shorten the feedback loop

What is the easiest thing that can be created that is customer-facing and can provide valuable feedback to guide future development decisions?

This is definitely within your scope to recommend, as opposed to their approach to develop the complete scope along architectural boundaries.

As a Scrum Master, help them to understand the value of incremental delivery of working software, and how Empiricism can manage risk associated with creative work.

my perception is that senior developers are going to spend lot of time in building the backend and there may not be enough feedback/engagement with the stakeholders while the backend is in progress.

What feature-functionality are they using to validate the backend work? Do they have a scenario which exercises a complete user transaction for example? This could be a happy path or edge-case which is quite narrow, but which is enough to prove the foundations being laid.

Well, the thing is that our backend is technically very complex. So, business was never able to define exact requirements. 

So, in the end, Architects took it upon themselves to dig deeper and define scope, which makes sense to some extent.

But i'm afraid that if we go too long without any feedback, it will be too late before the gaps between tech and business start to appear and end product may not be what as expected initially.

Talking about the exact problem, we can say that it is a complete new tool to map the customer journey.

It will take time to build anything customer facing which is usable. that's why I thought wireframing without a backend may be the way to go?

Well, the thing is that our backend is technically very complex. So, business was never able to define exact requirements. 

From my experience this happens when a backend is created independent of the middle/front end that will use it. The builders of the backend will attempt to satisfy every possible thing that could ever potentially be needed at some point in the future because of something that could happen.  Was that sentence complex? Yes but it illustrates my point. 

In agile it is common to hear that "the best architecture will evolve as needs are identified", at least that is how I explain it.  If you attempt to build the "it does everything" before you identify what is needed, you WILL end up with something technically complex and probably overly complex.  Your approach is actually going to continue that practice. 

It will take time to build anything customer facing which is usable.

Scrum, and agile in general, is about providing some working software in increments.  Does it have to do everything the customer wants? No, but it should be enough for the customer to see some value and provide feedback on the future work.  

But i'm afraid that if we go too long without any feedback, it will be too late before the gaps between tech and business start to appear and end product may not be what as expected initially.

If you do Scrum correctly, the part of your comment that I bolded should happen.  How many times have you built something that the users said wasn't what they needed?  In today's world where technology and economic needs change daily, trying to build something based on the input from 3 months ago will most likely result in something not useful.  Increments of usable, valuable software allows you to change direction/requirements to deliver what the customer needs now, not what they needed months ago.  Could it take longer to finish?  Yes, it could but what you finish is what is needed.  Could it take less time?  Yes, because the customer may find that you have done "enough" based on changing needs.  They may also identify that the work is no longer needed and ask for it to be stopped.  

As a scrum master, how can I influence the DEV team to find ways to shorten the feedback loop?

Coach them on empiricism.  Coach them on incremental delivery.  Coach them on why both of those are not only good ideas but essential in today's constantly changing global environments. 

Thank you Daniel for your advice. I hope I can make some progress there.

In the end, it was not so difficult as I expected. I just brought up the concept of building "Mockups" and present it to stakeholders before building the entire backend and surprisingly, team accepted.

It is probably a sign that they are maturing in Agile

Thanks for an interesting and valuable discussion! I have faced the same struggles, but now, with the advice discussed in this thread, I perhaps can change things for the better.  

Another question on the same topic: 

As this is a huge project with plenty of documentation on the design strategy and different development phases. Everything is in Confluence.

We are supposedly working on phase 1 and the team has created a single epic and they keep adding stories to the epic.

It means that If I look at the jira, I don't have any clarity on the scope of this project, no clarity about the end goal and absolutely no visibility on the different phases.

Do you have any suggestions about the level of detail, we should maintain in JIRA? 

I was thinking of creating an epic for each design phase.

For the current phases, I think, we should have all the user stories for this phase in JIRA (unrefined stories are fine). In my view, this at least provides clarity on the scope of the phase 1, otherwise it is a never ending stuff.

Looking forward to your suggestions and feedback;

What location provides the most visibility to the stakeholders and organization in general?  Visibility includes being able to understand the work that is being done in order to satisfy the captured user needs. 

And I'm going to provide this Principle from the Agile Manifesto for Software Development.  It is listed 3rd from the bottom.

Simplicity--the art of maximizing the amount of work not done--is essential.

You shouldn't get into a practice of duplicating information as they is prone to failure where only 1 location is updated. Based on your description is appears to me that Jira might not be necessary at all.  You can create backlogs in Confluence and even create some mechanism for managing it. A Scrum Board can be made in Confluence by creating a table. You then move an item across the board and each row would be a swim lane based on Story. Jira makes it easier but if your organization/team has decided to define all of the work on Confluence then is it really necessary to use another tool?

I will also suggest you read this page created by Atlassian on how Confluence and Jira connect. It has a couple of sections that I feel could be useful for you. 

https://confluence.atlassian.com/doc/use-jira-applications-and-confluence-together-427623543.html

I was thinking of creating an epic for each design phase.

Leaving aside matters of scope for the moment, are you confident that the Definition of Done in this “design phase” will be of release quality?

I'm not too convinced that adding things in JIRa is duplication of effort. 

In the end, we are using jira epics to add new stories on the subject. So, JIRA in some way is more up to date than Confluence.

If the Product owner comes to me and asks for an estimate, I have no answer as there is nothing in JIRA and I can't rely 100% on Confluence as i'm convinced that moving pieces are not updated on Confluence.

@Ian Mitchell, I'm not confident about the whole project, when I hear the team speaking about it, I get the impression that they are not sure of the scope themselves.

If the Product owner comes to me and asks for an estimate, 

Why would he come to you and not the Development Team?  The Development Team are the ones doing the work so they have better information with which to make an estimate.  

I'm not too convinced that adding things in JIRa is duplication of effort

So, JIRA in some way is more up to date than Confluence.

 I have no answer as there is nothing in JIRA and I can't rely 100% on Confluence as i'm convinced that moving pieces are not updated on Confluence.

All three of those statements tell me that you have no source of information to rely on and that there is indeed duplicated information. You also contradict yourself by saying JIRA is more up to date and that there is nothing in JIRA. More circumstantial evidence to suggest lack of information and coordination.

To me, the method you are using of having disconnected information in more than one place is causing more confusion than clarity. 

Why would he come to you and not the Development Team? I'm also part of Development team but not working on this project. But it is very common in our setup for PO and IT manager to come to scrum master for these questions.

Sorry for the contradictory statement, what I wanted to say is that: in future, team will use JIRA to manage epics and stories, so in that sense, JIRA is more likely to be more up to date in future than Confluence.Confluence is just a placeholder for initial analysis.

So what do you suggest? Am I worrying too much?What really should a scrum master do in this case? What are things scrum master should watch out for when teams set for such long and complex projects (it is a full re-design of the existing pricing system.)

I think you should:

1. Coach PO to have 1 single source of information about things to be done in project. Having some general phase explanation and breakdown on Confluence is fine, as this might be lost among crowd of PBIs in JIRA, but the list of things to be done should be in 1 single place, for example JIRA.

2. Balance architecture effort with delivering something that could be released, even small.

3. As it will be the Development Team doing the work, they should provide estimations during Backlog Refinements. Then this should be readily accessible by PO / any stakeholder. You as Scrum Master should make sure that data is in the Product Backlog, but not answer specific questions - you can teach anyone how to look at Product Backlog for already estimated data.

Thanks Filip for sharing the suggestions, I'll keep my focus limited to this.

Unfortunately, I'm afraid that Development team has already spent lot of time in architecture planning, I was not involved in it, but it has been done. And now certain team members are saying that we are using more a waterfall approach to this project.

Hopefully the already done architecture work will not be wasted time.

You might tell them it is great that they now know how to approach future project - learning has happened. Now they have to focus on how to avoid more waterfall in this project. It is about improving based on data, so not all hope is lost :)

Try not to think of the thing you want to get away from ("less waterfall" / "avoid more waterfall"), because, if you try to get away from something, anything which is not that something is good and where will you end up?

Think in terms of where you'd like to go: more scrum. Or whatever you'd like to go to.