Because it’s 2015. This was the answer of Justin Trudeau, Canadian premier minister, to a journalist who asked him about the importance for him of having a cabinet with gender balance (similar number of men and women). Although for some people this could be a question difficult to argue, the answer was obvious. There is not much else to explain. The same thing happens today with the need of change in large organizations. The answer is obvious, there is not much to explain. And perhaps this is the year in which all the large organizations are leaping into the abyss of Digital Transformation, or rather the ones that are missing, because many of them have already started their path with greater or lesser success. Sometimes without knowing what a Digital Transformation process really means. What it implies.
Change bells are ringing, and unlike a few years ago, now everyone is listening.
The year began with the article written by Mary Poppendieck titled The End of Enterprise IT, describing some aspects of the change at organizational level at ING, the Dutch bank that among other countries also operates in Spain. It tells how the organization empirically discovered that this change requires reinventing itself at structural, hierarchical and business level, and that it would implicate, of course, the consequent cultural change in the company. Organizations have already discovered that they are late in this topic, they should have started this kind of Organizational transformations three or more years ago, but right now some of them are ready (not all), so everything has been conveniently baptized at market level with the label Digital Transformation, which maybe is not the most correct name, but Business is Business.
Much has been written and said about the transformation of large organizations: it is impossible, they do not want to change, it is easy, I do it in 20 days, it is not worth it, etc. Curiously, many of these phrases are usually from people who have never been part of a truly transformation process, involving all levels of the organization and not just working with some technology teams to get them doing Scrum from its’ silo on the 2nd floor of one of the organization’s building.
Since I started working with Agile some years ago, there are tons of doubts that people ask me in my work with different clients, in community meetings or at my day to day, but there is a question that lately many people repeat me, and that seems like its more difficult every day for not initiated people: Which is the best Scrum Master certification program?
Given the explosion that we live in recent years with everything related to agile methodologies, and not only at the level of software development in small niche companies or start-ups, but also at large organizations, it is not casual the appearance of many companies willing to be providers of Scrum Master certifications. Companies that do not necessarily have a long career in the Agile world, and that are not backed by recognized entities, but who have created new certification programs that have flashy names, difficult to distinguish, and all of them written as three-letter acronyms, which makes it certainly difficult to differentiate between them.
Is quite easy for the people who is involved in the community to identify the most recognized certifications, but it is not a simple task for those who just arrived to the Agile world. And although there is no a direct answer for the question of which certification is better, as this depends of the preferences and possibilities of each person, it is true that exists certain information that can be analyzed to take the best decision for each personal situation.
During the agile retrospective, also known as retro, the team reflects on what happened in the iteration and identify actions to focus on the continuous improvement.
In those meetings, identified as one of the ceremonies of Scrum framework, and timeboxed to three hours or less, the team reflects about the daily work of the team itself, both qualitative and quantitative way, endeavoring to uncover what is working well, what isn’t, and what can the team do better the next time.
The quantitative side of the agile retrospective is relatively easy to address and understand, provided that we have access to data about work and team performance. Metrics about team velocity, value delivered, defects density or even data about team’ happiness are really relevant in every day life of a good agile teams, and may provide clues to proposing improvement actions. Having a history of all the data that as a team we consider relevant we can do comparisons and identify trends and breaking points that have affected productivity, and we will obtain conclusions about what has been happening in the team over the time.
Thus, the quantitative side of an Agile retrospective seems a simple task, but it is not the case of the qualitative side…