Living by the Agile principles
One of our customers, a medium-sized company providing software and hardware solutions for the transportation sector, introduced Agile methodologies in the form of a Scrum team. The Scrum team did not produce the expected quality, which internally led to a lot of resistance towards Agile. The customer asked us for help. We held a workshop to understand the issues and conflicts between the stakeholders and invited people from various departments and top management. During the workshop, one participant presented a typical process that was causing a lot of friction. It quickly drifted into a “blame game” where each participant blamed the others for problems in the handovers.
Most importantly, outputs from the Scrum team did not have the quality everyone expected, and people felt powerless because they were not allowed to interfere with the team’s inner workings. As the moderator tried to get to the source of the problem, it became clear that there was a deep misunderstanding of what Agile means. The company wanted to do Agile, but they didn’t live by the Agile principles. For example, we found out that the requirements that were fed into the system were not of sufficient quality, but there was no process in place for improvement as the requirements were coming from outside the Agile team.
There was no way for the author of the requirements to know of the problems these were causing. Introducing Agile in one team, but leaving everything around it intact, is typically bound to fail. Once the audience understood that Agile is not only for the software development department but also the business areas needed to contribute in the end-to-end value chain, they started to accept that being Agile is far more than what was being done.
Synchronising work and outcomes in a Scrum mode
A well-known Swiss insurance company had been working in a Scrum mode for almost ten years but were facing one major problem: even though all teams were Agile, they had difficulties with synchronizing their work and outcomes. One of our Agile coaches proposed to support the company with a planning and synchronising event and by coaching management as well as teams on topics such as transparency and individual responsibility. Even though the teams did not have much time to prepare, not to mention learn theory, the planning event took a far shorter time than originally estimated. When the participants left, they were all motivated and had a clear plan for what to do for the next couple of sprints. Why? For the first time, even teams who were usually involved only very late, learned about the project vision and knew exactly who would be using their service at the end, which motivated them not only to work with the customer in mind but also to give their own input on the best solution instead of just following the requirements they were given.
Additionally, all teams got to know the other teams, which had several positive effects: the first, and most obvious, was that people would recognise each other in the hallways. Suddenly there were not just a lot of people working in their building anymore, but different teams, consisting of people they knew and could talk to. The teams started to exchange what kind of inputs they usually received from other teams and what their output looked like. They also found out that the team which provides the output only needs to deliver a part of the information. A typical case for reducing waste and doing continuous improvement.
Over one-and-a-half days, the entire project team finally knew their vision and had a common understanding of the plan, and was motivated to give their inputs and take responsibility for their actions. Perhaps most importantly, a level of transparency emerged that allowed progress and delay to be shared, as well as new ideas.