Shorten the feedback loop

Last post 09:32 am May 25, 2019
by Jacob Miller
7 replies
Author
Messages
11:13 am May 15, 2019

My team is undertaking a huge project, for the moment, only a senior DEV and Architect are involved in the design and coding.

They have done the nice work of splitting stuff into epics and stories, which is fine. As a scrum master, I have not been involved in the project.

But as an outside, 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.

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

One of the lessons from Lean startups says that: We should ideally make wireframes before building the core backend.

But i'm not sure, if it isn't my scope to tell them to build X instead of Y...., they know how to do their job.

My concern is only about frequent feedback.

 

Any suggestions please?

 

09:35 pm May 15, 2019

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.

04:26 am May 16, 2019

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.

02:22 pm May 16, 2019

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?

05:54 pm May 16, 2019

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. 

08:57 pm May 19, 2019

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

02:44 pm May 22, 2019

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

09:32 am May 25, 2019

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.