Mis reflexiones después de leer “Fifty Quick Ideas To Improve Your Tests”

Este libro escrito por Gojko Adzic, David Evans y Tom Roden presenta una colección de ideas que podrían mejorar las practicas de testeo de un equipo. Sin embargo creo que no debe confundirse, este libro no es para testers, es para equipos multidisciplinarios que hacen del testing parte de su día a día.

El libro enfatiza ideas resumidas en cincuenta prácticas que podrían aplicarse, pero más importante que eso enfatiza que los desarrolladores mismos deberían testear su código.

Por mucho tiempo se creyó que testear el código de uno mismo no es efectivo pues uno tiende a tener una “vision de túnel”. El libro si bien reconoce que tal vision sesgada podría existir en algunos casos, enfatiza que la ineficiencia de tener roles especializados (que provocan desperdicios como cuellos de botella, dependencias y fallos en la transferencia de conocimientos) es mucho peor.

Los autores recomiendan que un grupo multidisciplinario puede reunirse y hablar de que testear, que escenario, en qué plataformas, etc. Al tener esta participación grupal la “vision de tunel” queda neutralizada y el siguiente paso es que cualquier persona que es parte de ese grupo multidisciplinario se dedique a realizar el testeo.

Finalmente, más allá de las técnicas propuestas por los autores −que no deberían tomarse como recetas sino más bien como ideas− rescato el hecho de que testing no es una actividad propia de un rol sino más bien una aliada de la artesanía de crear código limpio.

Después de leer Agile Product Management With Scrum

Roman Pichler escribió ya hace diez años este libro que se ha convertido en un clásico pero que al igual que cualquier cosa que se vuelve clásica, contiene conceptos buenos para su época pero no necesariamente para el tiempo presente.

Mi principal observación es que en el libro siguen mencionándose resabios de la vieja noción de que el Product Owner es el manager del equipo, ejemplo de esto es que el autor menciona que en el Sprint Review el equipo presenta para el Product Owner lo que pudo lograr y que el Product Owner puede o no asistir al Daily Scrum Meeting para enterarse de que esta haciendo el equipo..

Yo llamo a estas conceptos de “viejo Scrum” porque fueron ideas y practicas útiles hace una década cuando Scrum se encontraba en una fase más temprana de maduración. En “Scrum moderno” entendemos que el Sprint Review es un evento que involucra stakeholders para que ellos usen el Incremento de Producto y así podamos recolectar feedback directo. También entendemos ahora que él Product Owner al ser parte del Scrum Team y al éste tener una jerarquía plana no tiene excusa para no ser parte del Daily Scrum Meeting.

Pichler visionariamente en su libro ya decía una década atrás que el Burndown Chart para un Sprint no era buena idea y que no debía usarse como una herramienta de reporte. Pichler también expresa su preferencia por utilizar Release Burndown/Burnup charts que deben dibujarse en papelógrafos y ser trabajados y discutidos por el equipo.

Una década atrás Pichler, al igual que muchos autores de esa época, proponían Scrum of Scrums como un mecanismo de escalamiento y coordinación. En “Scrum moderno” aprendimos que Scrum of Scrums no acaba siendo efectivo y tiene el efecto colateral no deseado de crear una jerarquía implícita en torno al rol del Scrum Master, qué es exactamente lo que no queremos.

En resumen, Pichler escribió un gran libro para su tiempo presentando conocimiento de manera resumida y directa, el problema surge cuando ese conocimiento cae en obsolescencia. Personalmente esperaría con muchas ganas que Pichler escriba una segunda edición actualizada de su libro.

Ways To Improve The Product Backlog

Keep the Backlog at a Manageable Size 

A Product Backlog with hundreds of items clouds visibility and demoralizes the team that can not clearly see the light at the end of the tunnel. What is even worst the cost of maintaining a huge backlog is so high that consumes the Product Owner’s time preventing her/him from working in more important things.

For the reasons stated above is very important to keep a backlog with the least number of items possible. Empirical evidence from several sources including my own experience show that less than one hundred items seems adequate. 

Be Proactive and Groom it

The Backlog Refinement Meeting is an event specifically designed to keep the backlog away from growing unnecessarily and with the wrong level of detail. This event an other mechanisms should be used to keep the backlog in good shape and as a valuable artifact for the team. 

Making an analogy with gardening, grooming is an essential activity that needs to be performed weekly or bi-weekly at the most, if not plants and trees grow wildly and eventually the whole garden ecosystem starts to degrade. Not grooming the backlog will cause the same effect: degradation. 

Share the Backlog with Stakeholders

Having stakeholders input about the backlog is very valuable because it helps the team to gain reassurance if they are building the right product with the right features. From the stakeholders perspective it’s very valuable to learn if the team is correctly interpreting their needs and concerns and crafted a possible solution that is being represented in the form of backlog items.

Trying to share the backlog with stakeholders will fail if communication is not effective and for this high bandwidth communication like face to face dialog is always recommended. Avoiding concussing terminology in the communication is another recommendation.

Techniques to Organize and Filter a Product Backlog

The best way to think of filtering the Product Backlog is to imagine it -or actually have it- in a spreadsheet and apply a condition that will display only the rows that meet that condition hiding the rest.

Filters can provide views of the Product Backlog without necessarily changing priorities. In fact, by seeing just a portion of the Product Backlog that meets certain criterion we might discover that we need to reorder the Product Backlog by changing priorities.

Organizing items in the Product Backlog around certain characteristics is another form of filtering, for instance we might decide to organize the backlog putting high risk items first.

By ordering the Product Backlog we may change priorities or just do something more temporary like applying a filter for visualization purposes only. Next you’ll find two techniques that can be really handy for organizing and filtering a Product Backlog.

Specific user/customer types 

Which basically means filtering all items that a particular user/customer will use; in other words, the filtering criterion will be user/customer type.  An example of this could be having a Product Backlog for a product similar to Uber in which you filter by driver or by customer.

Feature areas

In this other techniques the idea is to filter by observable functionality that end users would be able to use and interact with. In simpler terms, the filtering criterion will be the feature area name that represents functionality. If we take the Uber app example again a feature area could be “Request a Ride” that has a lot of backend functionally but more importantly is directly observable and has great value for end users.

One last reflection, both techniques can be combined to narrow down the displayed items, for example we could filter the Product Backlog to only see items that correspondo to the feature area “Request a Ride” and that will be used by the “Driver”.

When and How to Test Hypothesis

The Scrum Framework is not specifically prescribing when and how to test product hypothesis and perhaps that is one of the reasons why many teams and organizations out there are building entire products without incorporating stakeholders’ feedback.

The consequences of such practices could be severe as teams might build a product that is not serving stakeholders needs or not in the way stakeholders are expecting. 

If the hypothesis validation could be completed before starting Sprints then the team is in a much better position to plan. A word of caution though, waiting for all hypothesis and assumptions to be validated before starting a single Spring might be the equivalent of working in phases and that would lead to waterfall development.

A more dynamic approach could be that the Product Owners validates assumptions a Sprint or two ahead of the of the Development Team. This validation with stakeholders could be done using paper prototypes (see page 47) or any other technique.

It’s important to mention that regarding of the technique or tools that used for this validation this is just a resemblance of the “real thing” that the team would be building. The corollary of this is that paper prototype should be good enough to provide insights and allow feedback but then the team will need to build the “real thing” as fast and as good as they can.

The Scrum Team should align its Spring Goal to deliver results to really test the assumptions, otherwise the Scrum Team might end up building something that looks great from a technical stand point but that is not contributing to validate hypothesis that were formulated based on stakeholder’s needs. 

Lo que me dejo el leer “Behind Closed Doors”

Johanna Rothman y Esther Derby escribieron el 2005 el libro “Behind Closed Doors: Secrets of Great Management” que fue uno de los primeros libros que trató de abordar cuál seria el rol y las competencias de un manager dentro de un entorno ágil.

Desde mi humilde perspectiva el libro tiene algunas concepciones que contraponen a la agilidad, la mas notoria es que trata de perpetuar el rol del manager tradicional pero ahora en una version ágil.

La contraposición se produce además porque hace más efectivo el rol del manager sin empoderar totalmente al equipo ni tomar el coaching como una herramienta fundamental de autodesarrollo del equipo mismo.

Sin embargo creo que aquellos quienes se encuentran actualmente en el rol de managers encontraran algunas técnicas y herramientas valiosas. Como las autoras mencionan en su libro típicamente las organizaciones promueven a sus mejores técnicos a posiciones de management sin proveer entrenamiento alguno, lo anterior produce un efecto negativo pues el conocimiento no es pasado al nuevo manager a través de mentoría ni entrenamiento guiado.

Algunas de los puntos principales que rescato del libro vienen a continuación:

Parece un consejo básico pero valedero, el ofrecer ayuda sin poder realmente brindarla acaba sonando a sarcasmo.

Este ultimo párrafo en la fotografía detonó en mi otro pensamiento: un manager que sólo hace tareas de management no esta en capacidad de ofrecer ayuda con temas técnicos.

Muchos dirían que para los temas técnicos tenemos el rol de Technical Lead, ¿pero qué pasara cuando esa persona que es Technical Lead quiera ganar más dinero? ¿Deberá buscar una promoción a manager?

Si la respuesta a la ultima pregunta es sí entonces el mensaje que la organización esta mandando es que la carrera de management paga más y es más valorada que la técnica. Lo malo de eso es que el código limpio no se hace con mejor management.

Manager que fuerzan el trabajo en múltiples frentes al final producen desenfoque y baja productividad.

Un buen manager, o cualquier persona que simplemente leyó acerca de neurociencias, debería saber que el cerebro humano no fue diseñado para hacer efectivamente tareas cognitivas en multitasking.

Por tanto es management by wishful thinking pensar que la gente de un equipo podrá hacer bien muchas cosas al mismo tiempo (aunque se ofrezcan incentivos y se compren pizzas).

Otro ejemplo de management by wishful thinking es pensar qué despidiendo a sólo una persona problemas de amplitud sistémica se acabaran resolviendo.

El corolario de la anterior frase también es cierto: contratar a una sola persona con la ilusión de que arregle ella sóla todos los problemas de una organización es wishful thinking.

Pensar qué una colección de personas que se conocieron recientemente son un equipo es otra forma de wishful thinking.

La gente, a diferencia de los recursos, necesita tiempo para aprender juntos, equivocarse juntos y crear ese espíritu de equipo del cual tanto hablan los libros. Conformar un equipo no algo que simplemente ocurre, es el resultado de una conjunción de factores que a veces se dan y a veces no.

Un manager que piensa que hacer staffing de recursos es lo mismo que construir equipos una vez mas estará haciendo management by wishful thinking.

En conclusion puedo decir que valió la pena leer el libro, tengo mis desacuerdos pero me sirvió para identificar mas formas de management by wishful thinking. Mi sugerencia es que los manager lo lean con ojos receptivos pero críticos porque al final el punto de un libro es siempre hacer que uno piense.

Después de leer Pragmatic Thinking & Learning de Andy Hunt

En un vuelo largo ayer termine de leer el libro “Pragmatic Thinking & Learning: Refactor Your Wetware” de uno de mis autores favoritos Andy Hunt.

El libro me dejo sabores mezclados por lo acostumbrado que estoy a esperar del autor lectura de temas profundamente técnicos. Hunt se aventura a explorar en su libros temas de psicología cognitiva, aprendizaje de adultos y neurociencias.

Si observamos desde una perspectiva holística todas esas disciplinas pueden contribuir grandemente al rápido y efectivo aprendizaje que se vuelve imprescindible para que la gente que aspira a crear código limpio.

En general del libro me llevo tres reflexiones, la primera de ellas viene del clásico modelo de aprendizaje de Dreyfus:

Este modelo muestra la progresión desde hacia un conocimiento experto que opera de manera natural, casi inexplicable y reservada para los maestros.

El modelo de Dreyfus, que me parece una alternativa interesante al sobre utilizado modelo Shu-Ha-Ri tomado de las artes marciales, muestra que no es posible llegar a un nivel experto sin haber invertido tiempo, esfuerzo y mentoría dedicada para alcanzar nuevas habilidades.

Este modelo resulta válido para cualquier disciplina manual o cognitiva, si pensamos por ejemplo en los mecánicos de automóviles ellos se vuelven expertos con muchos años de practica, metoría y un cumulo de errores cometidos. El nivel de expertise de un mecánico le permite diagnosticar con solo ver, escuchar e intuir la falla en un motor pero difícilmente puede verbalizar cómo sabe que ahi.

Similar nivel de expertise es el que puede observarse en software craftsman que intuyen que hay que refactorizar porque “huelen” que el código no esta bien.

Un corolario interesante de esta analogía con los mecánicos es que no se puede llegar a un nivel experto sin “hacer” el trabajo por mucho tiempo. Mi segunda reflexion del libro tiene que ve precisamente este punto, ver la siguiente ilustración:

La distribución poblacional indica que un porcentaje muy pero muy pequeño realmente alcanza el nivel experto.

Si la gráfica anterior es cierta, como parece serlo para muchas profesiones y oficios, ¿porque será que muchas gente en nuestra profesión del software se considera experta pocos años después de haberse graduado de la universidad?

Mi ultima reflexion tiene que ver con la poca efectividad de los cursos de capacitación dentro de la empresas, esta analogía la ilustra magistralmente:

Las ovejas pasan por este procedimiento forzado de desinfección que tiene un efecto temporal y debe realizarse periódicamente.

Los empleados de una empresa son enviados, a veces sin ser consultados a un curso de capacitación o certificación, aprenden con la mejor se su voluntad (o a veces no) durante los días que dura el curso pero luego regresan a sus puestos de trabajo a hacer las cosas como siempre solo cambiando pequeñas detalles y con el tiempo acaba olvidando todo lo aprendido.

Al igual que con la analogía de las ovejas, un nuevo “baño de conocimiento” es necesario quizás con un nuevo curso o un nuevo instructor. Este ciclo desde luego que genera negocio para muchos capacitadores, incluido su humilde servidor.

Pero habrá que preguntarse si genera beneficios duraderos para las empresas pues si estas no capitalizan esos beneficios la idea entera detrás de la agilidad puede diluirse.

Hunt propone algunas alternativas para hacer que los efectos del entrenamiento sean más duraderos, a saber:

  • Clubes de lectura formados por los mismos empleados
  • Grupos de práctica
  • Pair reading y mentoría cruzada
  • Y por sobre todo practica constante y dedicada de lo aprendido

Desde luego lo anterior requiere un mayor compromiso y apoyo de parte de la empresa pero principalmente de los estudiantes que participaron en el aprendizaje. Al fin y al cabo cada uno es dueño de su carrera y no es responsabilidad de nadie el forzarnos a aprender.

Finalmente creo que leer este libro fue una gran inversion de tiempo pues me sacó de mi zona de confort de conocimiento y eso es precisamente lo que hay que hacer para “refactorizar nuestro wetware”.

Reflexiones acerca de The Agile Samurai

Recientemente termine de leer el libro “The Agile Samurai” escrito por Jonathan Rasmusson. Debo en principio decir que encontré su estilo de escritura, con buenas ilustraciones y comentarios de un sensei imaginario, muy entretenido y valioso.

Varias cosas de este libro me llamaron la atencion, la primera de ellas fue esta grafica:

Analisis, pruebas y desarrollo todo en el mismo Sprint.

La razon por la cual me llamo la atencion es porque enfatiza la necesidad de realizar analisis “just in time” y “just enough”, analisis que al ser minimalista y oportuno posiblilita que historias sean codificadas y probadas dentro de la misma iteracion. Desde luego esto no seria posible si se comenten dos errores conceptuales: uno, escribir las historias en lugar de hablarlas, y dos, tener historias de varios dias de duracion.

Esta segunda grafica me parecio magistral porque ilustra bellamente un concepto clave:

La integracion continua implica integrar continuamente en una escala de tiempo de minutos.

El no integrar en una escala corta de tiempo (minutos) trae consigo serios problemas que repercutiran directamente en el exito de la iteracion.

La integracion continua es un tema que tecnologicamente ya se resolvio hace decada con la creacion de herramientas de software que compilan codigo de un repositorio compartido, sin embargo el tema humano que implica la comunicacion y disciplina necesarias para integrar codigo al final de cada ciclo corto de TDD es uno de los desafios pendientes de los equipos agiles.

Finalmente esta otra ilustracion me parecio mas que descriptiva:

La refactorizacion y frecuente constante es una herramienta valiosa para combatir la deuda tecnica.

Sin embargo una palabra de adavertencia, no es factible refactorizar constantemente si se carece de test unitarios y los test unitarios tambien se refactorizan. Esta parece una reflexion metacircular que incluso va mas halla pues todo codigo se debe refactorizar con el afan de introducir el conocimiento (tecnico y del domino del problema) mas reciente.

La no refactorizacion o la refactorizarion irresposablemente hecha que no considera pruebas unitarias, se vuelve una practica vacia y contraproducente.

En lineas generales puedo decir que despues de varios meses finalmente encontre un libro que describe adecuadamente el delicado balance entre las practicas ingeniereles y humanas que son necesarias para que la agilidad tenga chance de florecer.

Scrum Mastery

Introduction

Scrum Mastery doesn’t come from repeating the same practices over and over again and thinking always the same way, instead it comes from doubting your own knowledge and keep learning.

Even if it’s true that constant practice is a path to mastery it’s not the mechanical and repetitive practice that will make a great Scrum Master; the opposite is true though, without practice of any kind there is no way one becomes a great Scrum Master.

Paradoxically only practice without reflection can produce that concepts initially learned deviate from the original form and mutate into something else completely deviated from Scrum.

In order to avoid this deviation from the original Scrum intend a Scrum Master can do two things: actively participate in a community of pairs and keep learning by reading good books.

¿Why are you a Scrum Master?

Asking me this questions over the years I’ve found different answers:

  • I needed the job
  • For the prestige 
  • I’ve been ordered to take the role
  • I was sent to a course and took the rol the day after
  • By accident 
  • Because it was a trendy role
  • To be a leader

After answering that question the next questions will require more reflection and analysis:  “do I want to stay in this role?” and base on the answer to that question comes this other question, “do I want to grow in the role?”

Another important question that a Scrum Master should ask to herself/himself is if Scrum values are present and alive in her/his personal life. Preaching Scrum values to the team but not practicing them could produce a fragmentation of the beingness in the Scrum Master.

If as a Scrum Master I talk about values but don’t practice them myself that would be perceived by the team that will question my authenticity and leadership.

Talking about leadership now, in Scrum we don’t favor imposed leaders from above but leaders that emerge from the team and people decide to follow because they want to. This type of leadership is not exclusive from Scrum and there are good examples of organizations that already implement it, organizations like Whole Food, W. L. Gore & Associates, and  Google [Hamel07]. 

The Scrum Master Dealing with Conflict

El Conflict is not an exclusive thing for Scrum Teams or organizations that decided to adopt Scrum. Conflict is in the very nature of human interactions, in all type of interactions that can range from personal to organizational [Kaner07].

Notwithstanding the above, as Scrum Master you need to be prepared to deal with conflicts that can be very destructive and fracture relationships in the team. Generally speaking, conflicts can present characteristics like:

  • Emotionality, that means that someone or several in the team yell, make gestures, hit the table and communicate aggressively
  • Tone of voice, could be the case that no one is yelling but there is a lot of sarcasm and subtle critique in the communication. It’s worth to mention that is possible to hurt each other’s feelings without yelling or using bad words
  • Lack of interest in solving the conflict, worn out relationships present this characteristic,  everybody got used to the conflict and it doesn’t bother them anymore

Once conflict has been perceived, the Scrum Master needs to analyze the causes and what could be possible done to solve it. Taking empowerment into account is not advisable that the Scrum Master deals with the conflict by yelling at people and order them what to do. 

Often times in helpful that the Scrum Master present to the team and the people involved in the conflict what possible reactions they might have, for instance:

  • Neglect that the conflict exist by saying things like “here we always yell to each other, is all business but never personal and we’re even friends”  
  • Concede  always in order to defuse conflict, conceding could also be symptom of indifference like people saying “do whatever that I’ll do just my part”
  • Overwhelme  others using all arguments to always win discussions
  • Withdraw from conflict by simply cutting the discussion or by not talking

Even if there is silver bullet way to deal with conflict, the more we learn and study about conflict the better prepared we’ll be to deal with it.

Servant Leadership

There are many types of leadership approaches and the Scrum Master needs to be prepared to adopt that one that is best for each situation. Of all these leadership styles maybe the more difficult to master is the servant leadership because it requires not only conceptually understanding it but also mastering your own ego [Sinek17].

Mastering your hers/his ego is fundamental  if a leader thinks in serving others and help them grow. It also implies acknowledging that the leader no longer grows in the organization hierarchy by instead she/he is more interested in growing internally as a human being.

Even though there is no single metric for gauging how good or bad a servant leader is, there some attributes:

  • Think in the others first, and put them before the leader’s self interest or like Sinek [Sinek17] said “let other eat first in an act of generosity and respect” 
  • Communicate effectively leaving behind least effective ways to communicate like sarcasm or double meaning; learning how to communicate it’s a journey itself that requires practice and guidance
  • Be a systemic thinker that not only considers here and now but sees beyond and anticipates the effects and implications that important decisions will have on people

Similarly a Scrum Master aspires to be a servant leader for both the team and the organization at large; organizations with this type of leaders tend to have deepen and lasting transformations.

Servant leadership again is no silver bullet, instead is just one more valuable tool for unleashing people’s creative power in an organizations that really encourages learning and experimentation.

Like Hamel [Hamel07] stated the future of organizations is uncertain and the more that its employees can learn and experiment the more chances organizations will have to arrive there, wherever the next great product will be.

Conclusions

The Scrum Master learning and growing path never really ends because like Ohno [Ohno13] said is about being a “lifelong student”.

Scrum is a light weight and barely sufficient framework but at the same time invites to walk a path, like a “do” in Japanese martial arts is not about the destination but also about every step that you walk on the path. 

Bibliography

Hamel07 Hamel G., 2007. The Future of Management, Harvard Business Review Press

Kaner07 Kaner S., 2007. Facilitators Guide to Participatory Decision-Making, Jossey-Bass; 2nd edition

Sinek17 Sinek S., 2017. Leaders Eat Last: Why Some Teams Pull Together and Others Don’t, Portfolio; Reprint, Revised edition

Ohno13 Ohno T., 2013. Taiichi Ohno’s Workplace Management, McGraw Hill

Serving the Organization

Introduction

Traditionally the  Scrum Master has been described as an impediment remover but this can be exhausting, frustrating and not really something the exploits hers/his full potential. Furthermore, depending on a Scrum Master to remove impediments doesn’t create a culture of self organization inside a team, quite the opposite creates dependency from a critical resource.

Interesting case studies about self organized teams came from unexpected sources like the crew of a nuclear submarine. David Marquet [Marquet13] tells the story of how empowering the crew of a submarine that he was expected to command unlocked submariners true potential and take them to unheard levels of excellence.

In his story Marquet came to the realization that he was not qualified to give orders because he didn’t have enough knowledge about his command, for that reason he had to take the leap of faith and give decision power to his crew. This case study documents the potential of self organization and empowered teams in a completely new domain. 

Inspiring stories like that might inspire Scrum Masters and leaders so they can  start thinking in reinventing themselves as influencers and educators for upper management; like in Marquet’s story upper management involvement is key for changing an organization to Agile.

Organizational Change is Possible

It is possible to change towards flat hierarchy organizations, where also exist empowerment and self organization, without sacrificing profits. As Laloux [Laoux14] documented on his book such organizations exist and they’ve been in business for decades and are still profitable.

In his classical management book Hamel [Hamel07] visionary identified several characteristics that management will need to have in the future if it want to stay relevant, for starters management will have to abandon all dogmas inspired in industrial revolution practices and gravitate towards people oriented paradigms. 

Hamel presents postulates like: “without managers, but with many leaders” that might sound revolutionary and anarchic but in reality promotes the culture of cultivating leaders that like to stay close to the gemba, so they can better understand the work and consequently better support continuous improvement efforts.

The Scrum Master role is not just be one of those leaders but also be the champion and upper management coach that explore how to change management. 

It is important to mention that the sponsor or detractor of organizational change is always the head of an organization, and that is way we should start trying to influence upper management  [Ballé14].

Scaling Scrum

There are several approaches for scaling Scrum, among others: Large Scale Scrum (LeSS), Disciplined Agile Delivery (DAD), Scrum at Scale and Enterprise Scrum.

My personal preference is for LeSS because of two reasons: one, LeSS was developed by its creators working in real life products with large teams in different countries, and two, LeSS maintains the simplicity of Scrum.

LeSS is Scrum plus a few additions, but at the same time incorporates influences from ally disciplines, lessons experimentally learn and solid engineering practices [Larman08].

The following represent LeSS in a nutshell: 

LeSS principles are summarized in the following illustration: 

Finally this other illustration describes the Sprint cycle in LeSS:

It’s Important to mention that LeSS doesn’t  promotes scaling without control, instead it proposes de-scale Scrum based on the proven fact that a lot of great commercial software has been build by small teams of highly motivated individuals. Having those small teams effectively cooperating in the simplest way possible is the key theme in LeSS.

Conclusions

It’s totally possible to have Scrum working not just for one team but for many, for this to happen a deepen organizational redesign will need to occur and that will require complete buy in from executive level leadership.

Without support from executives change can occur but it will be limited to a team or maybe a few teams, in any case the results will be suboptimal and the risk is that eventually people get disenchanted with Scrum and think that it can not be done at a larger scale.

Scrum hast the potential to be the catalyst that triggers the transformation of the whole organization. The Scrum Master can ignites the transformation but then the  executives of the organization need to be the driving force.

Bibliography

Marquet13 Marquet D., 2013. Turn the Ship Around!: A True Story of Turning Followers into Leaders, Portfolio

Laloux14 Laloux F., 2014. Reinventing Organizations, Nelson Parker

Hamel07 Hamel G., 2007. The Future of Management, Harvard Business Review Press

Ballé14 Ballé M., Ballé F., 2014. Lead With Respect A Novel of Lean Practice, Lean Enterprise Institute

Larman08 Larman C., Vodde B., 2008. Scaling Lean & Agile Development: Thinking and Organizational Tools for Large-Scale Scrum, Addison-Wesley Professional