The story of agile transformation started as it probably does in many cases: given a product that was being developed using a waterfall methodology, there were no major new developments in its lifecycle, maintenance was a pretty crucial part. For various reasons and objectives, the management, with the involvement of experts, decided to switch to agile, Scrum development. Scrum teams were formed, with a Scrum master, and with a product owner. Not many of them had deeper agile experience and everyone got a couple of days training on Scrum and thats it. We got acquainted with the ceremonies, established the habits in the teams. It seemed that we started to work according to Scrum.
Because it is very important to remember that it is only an apparent change! The tasks and deadlines have come, but apart from working in small teams and sprints, not much has changed. We were repeatedly told that this and that was the responsibility of the product owner and the teams, but we couldn't do anything about it. We often felt that what was someone else's task and responsibility, they were now trying to 'pass on' to someone else. We lacked a change in mindset, to understand what it means to be agile, not to plan everything in detail in advance, what it means to be empowered (product owners, teams), and not to expect others to tell us what to do, but to define the path to the goal. (Of course, I note that apart from knowing what is important, but without specific goals, it would not be so easy.)
I will pick two examples that illustrate the difficulties and insights:
It soon became clear that the quality of development (testing) needed to be improved. This could not be done, however, because there was constant pressure (from non agile contracted projects) to deliver various developments in a short enough time. In the meantime, ideas were generated on how to improve quality. Many tasks were generated, but no substantial progress was made. In fact, after a while we were lost in ideas, and if there was a little time, it was more like haste. How much more manageable it would have been to define the necessary steps in broad terms, to draw up a roadmap and to work out the detailed tasks for the next one, rather than overwhelming the teams with lot of tasks.
The second example is related to story points. We learned that you need to estimate in order to plan a sprint, and also that the best is not in hours, but in story points. We also worked out a not necessarily simple system, so we were able to give points on a "scientific" basis. Until, after some reading up and watching videos, we realised what it was all about: determining the size of a task based on references, and so when planning, it was easy to determine what would fit, e.g. three of this kind of task would fit, and five of that kind. To put it in perspective, we know how big a basket we have, and we have to figure out how much of the different sizes of fruit we can fit in.We have found that the agile journey is not always easy, especially if support for transformation stops at the point where teams are starting out. Looking back, what do I think could have been done differently? Spend a lot more time learning the essence of agile, Scrum. Not necessarily with formal training, but more with frequent conversations with experts in agile, Scrum, agile coaches, experienced Scrum masters. And this is done at all levels, with team members, Scrum masters, product owners, and people involved in processes outside the teams. I believe that an operation will be agile when people are aware of what it means and part of the thinking. Without this, even if the appearance is there, the essence is lost.
