It was a crystal-clear mission. Thought the management. Develop and launch a new software product. The project objectives were defined and announced. It was not the first time the various teams from product development, software development, IT operations, marketing and sales faced a challenge this big. After all, processes were defined and worked in the past. Still, this time things were different. Given that product requirements were permanently in a flux and management wanted to have the flexibility to react to changing market demands all team teams agreed to embrace an agile approach to product development. That is, software was planned to be rolled out every 2-3 weeks rather than at the end of the project in a big bang. Dedicated teams were formed, regular stand-up meetings to synchronize the teams were set up. From an organizational point of view things were well prepared.
And yet, things did not quite work out as planned: Software could not be rolled out every other week because the various teams did not synchronize their efforts across teams. There was a widening gap between the functional teams, i.e., between the requirements side, the software development teams, marketing, sales and IT Ops. Information was not openly shared and got lost in translation between teams and organizations. While some teams applied Scrum for software development, IT operations and other software development teams favored a sequential waterfall approach and blocked all agile efforts. In consequence, gained productivity gains from agile teams evaporated in conjunction with non-agile teams. In addition, there was disagreement about what would happen after the product launch.
There were a number of reasons for the suboptimal outcome. Project objectives were clearly defined at the beginning of the project. Alas, some project objectives competed against others, were not compatible or did not account for other dependent projects and organizations. Plus, there was no common vision of the product in the first place which would have given every team a direction of the journey. When you asked 3 or 4 teams about the vision of the product and project you got 3-4 different answers. Productive teams were moving into different directions. Energy and effort were wasted.
At the end of the day, project objectives were achieved. The product launch was successful. However, overall spent effort was much greater than principally possible and originally thought. Consequently, team morale and confidence in agile product development approaches were at fairly low levels.
This need not be the case. When you choose an agile approach to product development the first and foremost thing you have to ensure at the very beginning of your endeavor is making sure that people and organizations involved in this project have the same vision and share the same values. In other words, invest time with your teams to develop this vision and let them share it with others. Developing a project or product vision which works requires involving all key parties that will actively work on and in your project. This process may be time-consuming. But it pays off. If you cut it short for short-term gains, chances are you will have to pay the bill in the form of greater effort toward the end of your project.