In digital teams, the key deliverable ought to be all about the quality. It is hard to write software at a high quality level without management, discipline, and people. The team must be careful to avoid going down the insular route known as design by committee, otherwise anecdotally known in the business as Conway's law (Melvin Conway's sociological observation, which can be found at https://en.wikipedia.org/wiki/Conway%27s_law).
In order to avoid dysfunction in the final deliverable of the software, the digital team should practice the behavior with the following characteristics:
They should be programmatic when they architect, design, and construct software.
They should aim to develop plans that are wholly manageable.
The team should have very clear ideas on the end state of the software delivery. Does everyone know who they are writing for? How are they achieving it? Why is the project in existence?
Everyone on the team must understand the customer's journey and therefore, prioritize on the customer's needs over the business processes and tools.
They should ensure the digital software delivery makes the best possible use of the technology while reducing the technical debt.
If the team is using an old version of Java 6 or Java EE 5 or Java EE 6, then fight hard to get this upgraded in a new project. The quality will be worse if you allow a digital team to build new software with a legacy technology without a force of change. If you have any issues, consider the bounded context concept (Eric Evan's domain-driven design at http://martinfowler.com/bliki/BoundedContext.html).