One major difference that leads to an inconsistent implementation of agile (specifically Scrum) is the makeup of the leadership team. In Scrum, there is one tenant that is stressed more than any other: The Team. Everything is designed around making the team as efficient as possible. Decisions are made at the team level, empowerment of the team to make decisions, communication within the team is paramount, succeed/fail as a team, etc. However, when the leadership or business is not also aligned to the Scrum methodology problems occur.
The development team is meant to be self sufficient. In order to achieve this, roles must come together: development, QA (Manual/Automation), UI/UX, Business (PO/BA), DevOps, etc. The team can achieve whatever is asked of it because they have the right skills and experience across all of the disciplines. However, often the leadership is not aligned with this and each role within the team has a different manager chain that they report up through. So while we ask our teams to work as a single unit, the management of the individuals make that increasingly difficult by not having a unified voice.
Compounding this is the fact that the business is often stuck in the waterfall way of thinking. They are planning functional releases and working with sales to get that new functionality to the end users. They are working with focus groups and trying to build a thorough road map and longer term plan based on what they learn. But a detailed long term plan is barely worth the paper it is printed on. The reality is that the software world is often too fluid to formulate a detailed plan that covers anything greater than a few months that remains accurate and on point. Don't confuse the plan with vision, which is necessary for all parties to stay on task. From my experience, most business partners have failed to make the switch to the agile movement and breaking away from the outdated waterfall school of thought. This is often the cause of friction and confusion between the agile and non-agile groups and usually ends with the feeling of teams of operating in "agile within waterfall".
So how do you overcome this scenario? Well, like agile there is no hard and fast solutions. You need to ask yourself if you are truly committed to being an Agile organization. If you are, then there are several changes that can be made.
Single functional leadership (close to the team)
A single functional leader that spans the different roles within an organization but owns the product or functional area is necessary to ensure a consistent and single voice. You may still have resource managers for the different roles within the team, but the work the team is responsible for requires that everyone is one the same page and is not getting mixed signals from their management streams. There are no "side project" or my manager is asking me to do something for him, etc. It is controlled environment where there is a single focus, the Team.
One of the major concepts behind agile is to work on smaller unit and to deliver benefit earlier. This often means that functionality is delivered and then refined over time. This is especially true in SAAS products. The business needs to set the course and provide information as needed. When the solution is delivered, we need to measure to see if the changes are achieving the goals. If we get positive results than the process should be to iterate and increment. This constant cycle ensure we are moving toward the long term goals.
This idea seems to be very difficult for people to implement as it is human nature to talk about the exciting upcoming features. The problem is the agile way is to deliver incremental functionality and to re-evaluate based on measurement. Unfortunately, that means that what is important today may not be that important tomorrow. So if you are selling based on a promise that we will deliver some functionality in a certain amount of time you are setting yourself and your customers for disappointment. The customers will almost definitely see this as over-promising and under-delivering.
The agile team itself needs to deliver smaller units of work. The idea is that by doing this all time time, it becomes easier to measure and re-evaluate. The process of shipping a new or modified piece of functionality becomes easier due to the frequency and practice. The functionality can be refined over time and the product can grow based on the priorities of today, not the priorities that were based on assumptions from the past.
The Agile methodology is not limited to the functional teams that make up the organization. To fully see the benefit of the Agile methodology all parts of the company need to embrace it. Working within a waterfall environment while conducting the agile ceremonies will not provide the value that these methodologies can.
