(Este artículo es traducción de otro en español. Puedes leer el original pinchando aquí)
“We all have to identify options for improvement, and not the obvious ones, but make a detailed analysis of feasibility study proposals, positive or negative impact, restrictions that might result, margin improvement and quantify the benefit”
What I’ve been finding almost always thinking of an agile project retrospective meeting is that we are somehow “corseted” by the de facto standards of Scrum Framework or the Scrum Masters. However I think our obligation is to take one of the bastions of agility as our logo and flag, the continuous improvement, and not simply apply the framework and walk the steps other marked us before.
Before discussing the technical proposal of retrospective meeting, we must identify the context in which we move.
(It’s interesting to visit the website of Scrum Alliance for those who don’t have familiarity with agile project management and specifically with Scrum, (I think it’s the reference in CSM or CPO certifications). You can read a quick guide on the following link: https://www.scrumalliance.org/why-scrum/scrum-guide)
On the one hand we have the goal of retrospective meeting is:
If we translate to a more understandable language, basically we are answering three basic questions:
And here comes the decisive role of a good Scrum Master. Has an obligation (yes, it is the Scrum Master obligation) to persuade, encourage, facilitate and promote within the Scrum Team to identify issues and options for improvement. And not the obvious ones, but make a detailed analysis of feasibility study proposals, positive or negative impact, restrictions that might result, margin improvement and quantify the benefit.
Scrum is a very serious framework, not by the use of colored pens and post-its roses it is a game. Actually if the team is mature, the margin for improvement is overwhelming, but risk analysis must be taken seriously, impact analysis, analysis of stakeholders and their needs, the viability resources (time, cost and restrictions) the technological impact, technical feasibility or the study of return on investment in those improvements with a great impact in the project, etc.
If you have familiarity with the context, you know that basically what we will find in the vast majority of occasions is the classic “starfish”.
Really looks like
And it certainly is a very suitable technique and has great potential when acting as a catalyst for generating enhancement options, to change the mindset of the team and give a positive and constructive meeting orientation. The main risk in this technique is that retrospectives usually are not as productive as espected. No options for improvement are identified but it identifies problems to avoid (rather than “how” avoid them). It is the duty of Scrum Master (Yes, again, it is Scrum Master duty) to get the team build options for improvement from a SMART perspective (Specific, Measurable, Assignable, Realistic, Time-related), the same concept we are familiarized in the objectives management. It is important to note that the improvement options are goals to improve project implementation.
But the goodness of the technique that accounts for 90% of the retrospectives becomes more times than we think in their main enemy. We move so far away from identifying problems to build options for improvement that we don’t comprehensively evaluate these same problems we want to solve. For me, there shouldn’t exist a “starfish” without a corresponding graph problem analysis. This technique consists of the following.
Igual que me ayudó a mí, es posible que esta infografía sobre Design Thinking ayude a otros.
(This article is the translation of the english version. You can read the original in this link)
“Hay que identificar las opciones de mejora, y no las obvias, sino hacer un análisis en detalle de estudio de viabilidad de propuestas, impacto positivo o negativo, restricciones que pueden derivarse, cuantificar el margen de mejora, cuantificar el beneficio”
Lo que me he ido encontrando casi siempre que pensamos en realizar una retrospectiva de una iteración en un proyecto ágil es que estamos en cierta manera “encorsetados” por el estándar de facto que nos marca Scrum y los Scrum Master de referencia, pero creo que nuestra obligación es tomar uno de los bastiones de la agilidad como bandera, la mejora continua, y no quedarnos simplemente en aplicar el framework y andar los pasos que otros, más intrépidos, nos marcaron.
Antes de exponer la técnica propuesta de retrospectiva, identifiquemos el contexto en el que nos movemos.
(Creo que es interesante, para aquellos que no tengáis una cierta familiaridad con la gestión ágil de proyectos y más concretamente con Scrum, hacer una visita a la Web de Scrum Alliance, para mí la referencia a la hora de certificaciones CSM o CPO en la que podéis leer una guía rápida en el siguiente enlace: https://www.scrumalliance.org/why-scrum/scrum-guide )
Entender la ciudad como un laboratorio urbano podría generar muchas dudas, sobre todo en su proceso de contextualización y en la puesta en valor del impacto de lo digital en la ciudad. La tecnología entendida como una herramienta al servicio de las ciudades y sus ciudadanos (donde ya no es necesario tenerla, sino tener acceso a ella), genera ansiedad en una parte de la sociedad…
Sigue leyendo el artículo completo en Ciudades PoKemon e inteligentes. 6 tendencias sobre la transformación digital de la ciudad. #SmartCities
Os animo a leer este artículo de Francisco Morcillo, es absolutamente recomendable.
Marketing, let us not forget, is an essential element of overall coordination of a company for the orientation to the customer. It is not just the vision purely promotional from which you must address the marketing strategy, but from a much more global perspective, we identify the wishes of the market, going several steps beyond developing a message of sale.
On the other hand, and especially in the industry of IT companies, the customer is being constantly bombarded by information, offers, products and services. This barrage of information, by way of defense for not having to evaluate it and establish criteria and comparative once after another, is instinctively categorized and catalogd by our brain unconsciously. This cataloguing leads us to that, without realising, the perception that we have as a consumer is a complex compendium of scales and rankings in different categories of feelings, preaceptadas impressions and perceptions.
Until now, everything seems to us very naturally…. If we are thinking in a corporate strategy for positioning of my products or services with regard to the brand image that I want to convey to my customers. In the same way we are also natural if we are trying to study the market to establish a strategy for the definition of new products or services.
What I propose in this article, and not only aligned with the retention of talent, is to put a seed to believe that those who have some degree of responsibility for the companies for which we work, we need to design how to move to the rest of the employees or “employable” the idea of company, its strategy, its motivation, its objectives, its “brand” to be considered part of it, not only an exchange of talent and work for pay.
So why not spun both perspectives and consider that employees are also customers of the company? Why we do not think in the same terms of loyalty, positioning, product strategy, communication or mark that we use for consumers but applied to the benefits on the human capital of the organization? Explore how to apply the basic concepts of marketing in the chain of internal communication of the company.