Full Stack Stories in "Scrum Team"

Is it possible to deliver full stack stories within a sprint in a siloed team? 

It sounds as though silos are accepted, and people are trying to optimize around them.

Why not maximize transparency over the various delays, bottlenecks and other inefficiencies and challenge those silos which cause greatest impediment?

Some great questions from Ian.

I've worked with a Scrum Team running 1 week Sprints where the Devs split the work vertically (i.e. front end React, NodeJS, and Mongo database tasks). They try to spilt the PBIs as thin as they can so they can finish in less than 2 days at most. They also try to pair as often as possible to catch issues and to gain collective code ownership. Now every thinly sliced verticle PBI isn't always released, it only has to be potentially shippable by the end of the Sprint without cutting corners. Scrum only requires at least one Done Increment by the end of the Sprint. In Scrum the Increment can be released anytime during the Sprint or not at all.

If not, should we be splitting the business requirement into layers?

The challenge with splitting the work by components (i.e horizontal layers) is that the work has to be integrated at some point, which usually comes at the end of the Sprint bringing on the risk of not meeting the Definition of Done. When one component isn't finished, it isn't transparent and can't be inspected at the Sprint Review.

Hi Ian and thanks for your rapid response. In fact it is a relief to hear that silos are accepted in teams. 

challenge those silos which cause greatest impediment?

There's some food for thought right there. 

Splitting the story to break out the frontend would not be advisable then? 

Hi Chris,

My main concern in splitting the stories horizontally is exactly what you point out - the integration ! I am in favour of full stack delivery but it's not an opinion shared across the team. 

We do slice the stack quite thin and we have 2 week sprints. For the most part we manage to deliver, however, if a story needs extra discussion, or something is misunderstood and the story gets delayed there is pressure on the frontend to get finished. 

I had thought our fundamental issue was with working in silos but that seems to be accepted. So it would appear to be our process, and specifically in our planning. We probably need to pay more attention to detail in the planning.

This is helpful. Thanks again Chris.

I work with many teams organized like this that are quite successful.  The keys are refinement and communication.  During the refinement of the stories all disciplines should start discussing potential architecture.  Come together to develop a planned implementation. That way the frontend will have an understanding of how to interact with the backend and vice versa.  When work commences there should be constant communication so that any "layer" can quickly know if they need to adapt based upon new information. I recommend that even the Daily Scrum is not enough communication.  It should be constant.  If they are in office, sit nearby to make it easy. If they are remote, open a channel in whatever communication tools you have available that is always open and ready for a discussion.  

As @Chris Belknap mentions the integration portion is where things usually start to fall apart.  But the more the team communicates the less of a risk that becomes.  There is no reason that the frontend can't have the backend's branch to use for testing while they are building and, again, vice versa.  Just because you have a speciality doesn't mean that you should not know how to use the other layers in a development environment. 

I strongly recommend against splitting the Product Backlog Items horizontally.  It will lead to a lot of confusion, context switching and delays.  At least that has been my experience when it was attempted. 

hi Daniel (how do we @mention in the forum?)

Thanks for your reply. My preferred way of working is exactly as you describe. And we have been working that way until our UI team member expressed his/her concerns. 

We have 2 options as far as I can see:

1) split the UI into separate user story & sprint (in this case we are giving way to one person on the team because most of the team would like to avoid this option)

2) work to improve the refinements and planning to reduce the pressure and risk on UI (preferred strategy)

For now it's obvious we should work on option 2, refinements, planning and communication and see what happens. 

Hi @Seamus - One more thing. Don't lose sight of the Sprint Goal. It's more about meeting and committing to the Sprint Goal than trying to finish all the 'stories'. If a delay becomes apparent and a discussion is needed or something is misunderstood, the Sprint Goal can guide the Scrum team in those conversations. The Developers should immediately engage the Product Owner for negotiation of the 'story' to see what might get adapted, with a laser focus on the Sprint Goal. The Sprint Backlog is expected to change throughout the Sprint.

If by UI work you mean html, javascript and CSS, where possible I would not recommend splitting the UI work into a separate story and Sprint. UI work alone is not potentially shippable nor is it transparent. It may even be wasteful if the Product Owner decided to pivot and have the Scrum Team work on something different next Sprint.

If by UI work you mean low fidelity prototyping or photoshop diagrams, by all means, consider that work to fall into Backlog refinement.

Scrum on!

Hi @Chris,

UI in our case is a frontend service which provides the UI (CSS/HTML,etc.). For now, it has been decided to split the frontend piece out and see how it works for us. So I am taking the attitude "don't knock it until you've tried it", but I remain sceptical.

As I know They also can start by developing a minimal web application. After achieving a certain level of success, they can move to advanced web applications and develop an eCommerce site, a social networking site, or a corporate website.

Agreed @Kim, but we are passed the MVC stage of the application now.

Hi @Seamus,

Has the team looked into testing frameworks and methodologies that would decouple front-end from requiring a back-end for testing? i.e. With TDD, the front-end developers really ought not to be dependent on a working back-end.This would be a QC design issue that would be brought to the team as a whole and investigated if plausible.

Hi @Paul,

Yes, in fact the frontend developers write unit tests and maintain a high test coverage. I think the issue is deeper than being a technical one.

What is a "QC design" ?

I suggest use https://mlsdev.com. Apps get popular very quickly. They reach the top of the charts and are featured on the app stores within days after being released. This is great for everyone involved, as it means more downloads and more revenue for the owners. The cost of creating an app is dependent on monetization. You can either put in your own money or purchase revenue sharing through sponsorship, advertising, and other monetization methods. This means that the potential revenue from an app will be dependent on how you monetize it.

Cross-functional teams means there are people with skills in each discipline that is needed to deliver an increment, which means that in a way there are mini silos inside each team. However, in my experience, this is felt much more as silos when teams are new and not used to working together but in time they learn to collaborate.

With regards to the UI issue, I've gone through the same where the UI being under pressure was the topic of each retro. We have found that UI working on wireframes a sprint ahead is working quite well. The BE dev will then implement the wireframe and the UI resources will just do some tidy up before delivering to production. We use Angular and CSS. We've only just started using React so I don't know if it will work in the same way.

I also agree with the others about spending more time on planning and communication as that will help foster the collaboration needed to get something completed within a sprint.

I've worked in multiple organizations where User Experience (UX) is actually part of the Product Organization.  As part of defining product enhancements, the UX team will create frameworks and validate them with stakeholders before the Developers start working on a story. It is considered part of the refinement activities for a story.  When the developers start working on the story, the User Interface (UI) will be implemented via the frameworks. It has been successful and prevented a lot of rework on multiple occasions.  Granted this isn't a solution for everyone but offering it up as a possibility to consider.

The frontend developers feel a lot of pressure to finish their work because they have to wait for backend deployments.

I had thought our fundamental issue was with working in silos but that seems to be accepted. 

As Scrum shines a light on problems, it's common for teams who don;t feel safe to hide within their Silo.

You've not raised any problems around your current way of working, apart from the stress on the UI to deliver. Within Scurm, no-one should be stressed. The work forecasted should be delivered without stress, rush or over-time and this should be a sustainable for long preiods. 

I'm supprised to see that one one has issued the "There is no UI, coders or UI, there is only developers". This is a mix of cross functional skilled "developers" who get the work forecasted, done. Having silo's breaks this model.

Questions to ponder.... you don't need to answer.

How must communication does it take to plan, spec a Sprint between these silos?

How many times does the API, Data Layer, UI not align?

How many times do the UI team have to rush last minute changes due to a miss understanding on spec, requirement or just simple naming conventions?

How does the UI silo feel about being forced into these last minute changes due to a backend problem?

Is this creating an Us vs Them culture? 

Are backend developers allowed to work on delivering a UI PBI (and vise versa)? How do you cross train and share knowledge? 

Is the whole process getting better every 2 weeks, or is each silo enforcing a status quo?

Even better, is anyone delivering full stack stories with a siloed team?

However, trying to implement Scrum into a company that's not able/willing to change is a grass roots problem, It is possible to use Scrum of Scurm and deliver value to the business over a shorter sprint, therefore forcasting less work. for example, the backend Sprint will delivery 20 (lets say story points) and they normally deliver 50 in a 2 week sprint. The UI sprint is aligned with the end of the backend Sprint, The process is adapted within a joint Sprint Retrospective and problems are identified, prioritised and solved.

This can work, but it takes a long time for the teams and POs to get aligned. It also reduces the amount of work the team can deliver as there is more refinement required. When something is wrong and work needs to go back to the backend, they have already started a new sprint and the bug can't been fixed! This is a nightmare. the Teams accept new BPI's (the bug fix) into the current Sprint and it break their process (Scrum But).

So, get 5 developers who have all the skills needed to design, build, test and deploy. Give them a business problem and let them solve it. Remove anything that gets in their way like phase gates, sign off, red table. Just let the highly skilled, highly paid team get the work done as a team and not a collection of disjointed silo'd individuals.

Ref:

https://www.cmswire.com/leadership/5-signs-your-organization-is-too-sil…

https://www.scrum.org/forum/scrum-forum/6731/meaning-cross-functional-t…

@garry taylor not everyone has the luxury of FS dev in every team. as much as one wants to strive towards having T-shaped people with cross-training, etc. the reality is that you will have one or two people from each discipline working in a team, each responsible for one part of that PBI. You don't all have to have the same skills to collaborate as an agile team, as long as your communication is effective and everyone understand dependencies, priorities and each other's work. It might take a while to get people to collaborate rather than just co-operate but it's a process to go through.