The term agile team is an often misunderstood concept. 

What does Agile Team mean in practice?

In the small, this guidance is clear, it’s the system.  All the way from user interaction to data and back and all the abilities to deploy and install said product into production. However, in the large, forming a team like this isn’t usually possible, and often not advisable—even if it is possible.

Also, in the large, a product is actually a sub-system of a larger systems-integration.

When you look at a product this way, it’s often possible to create a small, cross-functional group of people that has everything—and everyone—necessary to produce a working, tested increment of product.

Business Capabilities

You should organize around products, or features, where it’s possible can. Organize around subsystems where you have shared functionality. We collectively call these business capabilities. Once you have the business capabilities understood, align the business capabilities with the technical architecture and ultimately the organizational architecture.

The intersection and alignment of business, technical, and organizational architectures is where you form a complete cross-functional group.  A team of people that have everything—and everyone—necessary to produce a working, tested increment of their part of the product.

Because your business, technical, and organizational architectures are probably broken—you will have dependencies between these teams that you are going to have to manage - for now.

Dependencies

Over time, the job of the Transformation initiative is to break these dependencies. As you move forward and break these dependencies, you will be able to treat each of these teams as pure agile teams.

Start forming teams that align business capabilities with technical and organizational architecture. Then, you are ready to begin the hard work of breaking dependencies. If not, all you can do is go through the motions of Scrum. Until you break the dependencies, you will never get the value you are working towards.

The reason you’re not feeling very agile is because you don’t have these kinds of teams.  You have way too many dependencies.

No amount of daily standup meetings is going to fix this problem. (An agile culture won’t do the hard work for you.)

Agile vs. Scrum

The key difference between Agile and Scrum is that while Agile is a project management philosophy that utilizes a core set of values or principles, Scrum is a specific Agile methodology that is used to facilitate a project. Meaning that Agile is a philosophy, and Scrum is a way to implement it into the product’s workflow, and it’s worth noting here that Scrum isn’t the only Agile framework. Another popular approach is Kanban, which emphasizes teamwork on fewer items at a time and focuses on reducing the time spent on each stage of development to reduce the time between start and of tasks. 

How to measure the success of an agile team?

Many indicators can help to measure the success of an Agile Team. Just to name a few:

• On-time delivery that can be tracked by a software or a platform - just like SCIENCER for example
• Completed Points during the Sprint
• Customer Satisfaction
• Business Value
• Product Scope
• Productivity
• Visibility 

Source: BigPicture, Small Business Trends