Better, Bit By Bit: Delivering Useable Increments,¡Saludos amigos de People Ops y Agile HR! El final de marzo está sobre nosotros y es un alivio sentir el clima más cálido filtrando su camino en nuestras vidas por fin - al menos aquí en Massachusetts. Acabamos de tener nuestro primer día cálido, así que aproveché el buen tiempo y salí a respirar el aire primaveral. Mientras caminaba, reflexioné sobre el tema del boletín de este mes: "Entregar incrementos útiles en cada sprint". Para una persona de operaciones de personal, el término "útil" probablemente parezca una jerga de software o de fabricación que da miedo. Pero también se puede aplicar a muchos resultados en muchas líneas de trabajo. Tengo una historia para compartir sobre cómo hemos utilizado los incrementos, pero primero, vamos a aclarar algunos de estos conceptos para que sepamos cómo podemos aplicarlos.,¿Producto potencialmente despachable,? ¿Incremento de producto? ¿Qué significa todo esto?,¡Buenas noticias! En la mayoría de los casos se trata de expresiones sinónimas. En el Glosario de términos de Scrum Inc. tenemos una definición muy detallada, pero en términos sencillos: en cada sprint queremos hacer algo, por pequeño que sea. ¿Por qué? Para poder dárselo a la gente y que nos digan cómo mejorarlo. Cada incremento tiene valor, igual que cada capítulo avanza en una historia. Usted puede decidir construir un coche. Decides qué características debe tener, lo diseñas, lo fabricas, empiezas montando el chasis, luego las ruedas, luego la carrocería. Al cabo de 18 meses, se lo das a los clientes y puede que les encante, o que vuelvan y te digan: "¡Necesito que vuele!" o "¿Puedes hacer que parezca la cara de un gato?". Si quisiéramos resolver la necesidad de transporte mediante incrementos, podríamos empezar con un simple monopatín. Que sólo tomó dos semanas para armar. Cuando se lo enseñemos a nuestros clientes, puede que digan: "Bueno, está muy bien, pero es difícil de maniobrar". En el siguiente sprint, entregamos un patinete, recabamos opiniones, pasamos a una bicicleta y, bueno, ya nos entendemos... Cuando nos ocupamos de cosas relacionadas con las personas, ya sean procesos, asistencia, cualquier cosa operativa, este concepto puede ser francamente aterrador. Las personas son extremadamente complejas. Nuestros sistemas también lo son. Por eso, a veces parece instintivo mantener las cosas en secreto. No queremos asustar a la gente con el cambio, ¿verdad?,Esto me lleva a mi historia.,En esta historia, no sólo vamos a explorar cómo crear algo viable en incrementos, sino también cómo crear e iterar de esta manera tiene la ventaja añadida de ayudar con la gestión del cambio!,Y en People Ops, ¡hacemos un montón de gestión del cambio!,Necesitábamos un nuevo sistema de compensación.,Contexto:,Cuando llegué por primera vez a Scrum Inc, éramos muy pequeños. Once personas. En cuanto a la remuneración, decidíamos los salarios basándonos en lo que creíamos que debía ganar una persona en comparación con lo que ganaban los demás. Dábamos aumentos salariales a discreción cuando considerábamos que alguien había crecido. No teníamos un calendario concreto. Para añadir complejidad, hacemos visibles los salarios de todos los empleados. Cualquiera puede ver lo que ganamos. Para todos los empleados.,A medida que crecíamos, era obvio que esta forma de decidir la remuneración no sería sostenible. ¿Por qué? No teníamos una forma concreta de explicar cómo decidíamos lo que pagábamos a cada persona. No indicábamos qué tenía que hacer una persona para aumentar su potencial. No vinculábamos este tipo de reconocimiento a la promoción de nuestra misión como empresa. Además, no podíamos estar seguros de ser equitativos en toda la empresa. Como grupo pequeño, Scrummy, basado en equipos, sabíamos que teníamos que pensar mucho para asegurarnos de que inspirábamos sinergia y colaboración, creábamos equidad y trazábamos un camino de crecimiento. Para ser claros, si hay ALGÚN tema en el mundo de People Ops que ponga nerviosos a empleados y líderes, es la compensación de los empleados. Así que cuando hablamos de un enfoque iterativo en el mundo de los RRHH, este parecía el lugar más arriesgado imaginable para probar pequeños incrementos. Pero nos arremangamos y lo hicimos de todos modos. Enfoque:,Si hubiéramos abordado este proyecto a la vieja usanza, en cascada, habríamos investigado, reunido requisitos, creado una estructura de compensación y, al cabo de varios meses, la habríamos presentado en una reunión trimestral.,¿Alguna vez su organización ha presentado un cambio tan radical a los empleados en una reunión multitudinaria? En lugar de eso, empezamos con un incremento. Después de investigar un poco y recabar la opinión de los empleados, tuvimos algunas ideas: un cigoto de estructura que incluía la noción de salario base más ",multiplicadores", para crear una fórmula. Esta fue una idea que tomamos prestada de,Jurgen Appelo, un conocido líder de Agile cuyo liderazgo de pensamiento es tan innovador. En un foro público, presentamos algunas estructuras en las que estábamos pensando.,Esta fue nuestra primera iteración. Nuestro producto. Nuestro incremento potencialmente despachable. ¡Un monopatín! Tuvimos un ayuntamiento para permitir preguntas y lo llevamos a los individuos para entender lo que les gustaba y lo que no. Y digamos que hicieron MUCHOS agujeros. Lanzamos una versión entonces, pero basándonos en los comentarios y en lo que estábamos aprendiendo, nos dimos cuenta de que necesitábamos una conexión más significativa con el crecimiento profesional. Nos preguntamos cómo serían nuestras etapas de crecimiento. Empezamos a pensar en lo que valoramos y necesitamos para hacer crecer nuestra empresa y ¡SHAZAM! Nació una segunda iteración que se alejaba de la remuneración y se acercaba a las vías de crecimiento profesional. Llevamos este incremento a un equipo. Les pedimos que revisaran las etapas y reflexionaran sobre en qué punto del camino se encontraban, y que nos dijeran dónde y por qué. Por otra parte, les pedimos su opinión sobre las propias etapas. ¿Tenían sentido? Tomamos esta nueva información y la reelaboramos. Lo llevamos a otro equipo. ¡ZOWIE! ¿Era otro producto enviable? ¡Sí! ¡Una motocicleta! Recogimos opiniones y volvimos a trabajar. Después de esta iteración, (¡FINALMENTE!), fuimos capaces de vincular lógicamente la forma en que compensamos a los empleados en función de las etapas de desarrollo que definimos.,Resultados y aprendizajes clave:,Aunque está muy resumido aquí, ¡todo este proceso nos llevó 6 meses! El resultado final (y digo "final" porque seguimos iterando sobre nuestro proceso) fue un paso exitoso de ser una pequeña startup a convertirse en una empresa Scrum que ahora tiene un camino a seguir para todos los empleados. Desde ese punto de vista, fue muy interesante ver lo diferente que era la versión final de la primera.,¿Y qué hay de la gestión del cambio? Con cada nuevo elemento que compartíamos, acompañábamos a nuestra gente por el camino de nuestro descubrimiento, de modo que cuando llegaba el momento de dar el salto, estaban allí con nosotros. El resultado final tuvo mucho sentido para la gente. Sabemos que les ha gustado: nuestro control semanal del pulso nos ha demostrado que la satisfacción en este ámbito ha aumentado con bastante rapidez. Los datos. Al liberar el trabajo de reflexión con frecuencia, nuestros empleados se acostumbraron a colaborar de esta forma en un tema que puede resultar incómodo. Esto alivió algunas molestias. Ahora, cuando recogemos nuevos comentarios y realizamos mejoras, cosa que hacemos varias veces al año, no es un shock. Así que, como veis, gente, aunque pueda parecer que el término "producto de trabajo" no puede aplicarse a nuestro trabajo, sí que lo hace, ¡y con primas! Me encantaría saber qué ejemplos reales tienes de "lanzar pronto y lanzar a menudo". ¿Cuáles fueron tus éxitos? ¿Qué has aprendido?

por Jessica Jagoditsh | 26 de marzo de 2021 | Blog

Greetings People Ops and Agile HR friends! The close of March is upon us and it is a relief to feel warmer weather seeping its way into our lives at long last - at least here in Massachusetts. We just had our first warmish day so I took advantage of the lovely weather and headed outside to breathe Spring air. As I walked, I pondered this month’s newsletter topic “Delivering Useable Increments Every Sprint.”

To a People Ops person, the term “Useable Incremento” probably seems like scary software or manufacturing jargon. 

I’ll agree with you there. It sure is. 

But it also can be applied to many outcomes in many lines of work. I have a story to share about how we’ve used increments, but first, let’s clarify some of these concepts so we know how we can apply them. Potentially shippable product? Product increment? What does it all mean?  

Good news! These are mostly synonymous expressions. In the Scrum Inc Glossary of terms, we have a nicely detailed definition but in layman’s terms - In every sprint, we want something, no matter how tiny, that is done. Why? So we can give it to people and they can tell us how to make it better! 

Every increment has value just like every chapter advances a story.

For those of you new to agile thinking, imagine that your customers need some kind of transportation. You might decide to build a car. You decide what features it should have, you design, you manufacture, you start by assembling the frame, then wheels, then body. After 18 months - you give it to our customers and they might love it, or they might come back and say, “I need this to fly!” or “Can you make it look like a cat face?” That feedback would have been amazing to know 10 months ago when you designed this contraption!

If we were looking to solve the transportation need using increments, we might start with a simple skateboard. That only took two weeks to put together. When we show this to our customers, they might say, “Well, that is great, but it is difficult to maneuver.” In the next sprint, we deliver a scooter, gather feedback, then move on to a bike, and, well, you get it.  

When we are dealing with People-related stuff, be it process, support, anything operational, this concept can be downright scary. People are extremely complex. Our systems are extremely complex as well. So, sometimes it seems like instinct to keep things close to the chest. We don’t want to freak people out with change, right?

This brings me to my story. In this story, not only will we explore how to create something workable in increments, but also how creating and iterating in this way has the added bonus of helping with change management! And in People Ops, we do a lot of change managing!

Problema: We needed a new compensation system.

Context: When I first came to Scrum Inc, we were very small. Eleven people small. When it came to compensation, we decided on salaries based loosely on what we thought a person should make compared to what everyone else was making. We gave comp bumps willy nilly when we felt like someone showed growth. We had no particular schedule. We stuck our finger in the air and let the wind guide us.  

To add complexity, we make all employee salaries visible. Anyone can see what we are making. For all employees.  

As we grew, it was obvious that this way of deciding compensation would not be sustainable. Why? We had no concrete way to talk about how we decided what to pay individuals. We provided no direction as to what a person needed to do to increase their potential. We didn’t link this type of recognition to furthering our mission as a company. Additionally - we could not be sure we were being equitable across our company. As a small, Scrummy, team-based group, we knew we had some heavy thinking to do to ensure we inspired synergy and collaboration, created equity, and outlined a growth path.  

To be clear - if there is ANY single topic in the world of People Ops that will make employees and leaders nervous, it is employee compensation. So when we talk about an iterative approach in the HR world, this felt like the riskiest place imaginable to try small increments. But we rolled up our sleeves and did it anyway. It’s how we roll.

Approach:

Now, if we had tackled this project in the old-school waterfall way, we would have done some research, gathered requirements, created a compensation structure, and, after several months, presented it at a quarterly meeting. 

Has your organization ever dropped a sweeping change like that on employees at a large gathering? How does that typically go? 

Instead, we started with an increment. After doing some research and after gathering employee feedback, we had some ideas - a zygote of a structure that included the notion of base salary plus “multipliers” to create a formula. This was an idea we borrowed from Jurgen Appelo, a well-known Agile leader whose thought leadership is so innovative. In a public forum, we presented some structures that we were thinking about.  

This was our first iteration. Our product. Our potentially shippable increment. A skateboard! We had a town hall to enable questions and took it to individuals to understand what they liked and what they didn’t. And let’s just say, they poked a LOT of holes. 

We podría have launched a version then, but based on feedback and what we were learning, we realized we needed a more meaningful connection to professional growth!  

We shifted course a bit. We asked ourselves, ‘What might our stages of growth look like?’ We started thinking about what we value and need to grow our company and SHAZAM! A second iteration was born that stepped away from pay and toward professional growth paths. A scooter!

We took this increment on the road - to one team. We asked them to review the stages and reflect on where they might be along the path, then let us know where and why. We separately asked them for feedback on the stages themselves. Did they make sense? What was missing?    

We took this new feedback and reworked it. We took it to another team. ZOWIE! Was that another shippable product? Yep! A motorcycle! Gathered feedback and reworked. After this iteration, we were then (FINALLY!) able to logically link how we compensate with employees based on development stages we defined.   

Results and key learnings:

While it is very distilled here, this whole process took us 6 months to complete! But this example nicely illustrates what an increment of working product might look like in People Ops.  

The endish result (and I say ‘endish’ because we continue to iterate on our process) was a successful step from being a small startup toward becoming a Scrum company that now has a path forward for all employees. From that vantage, it was so interesting to see how different the final version was from the first.   

And what about Change Management? With every new piece we shared, we were walking with our people down the path of our discovery so when it was time to actually jump, they were right there with us. The end result made a lot of sense to folks. We know they liked it - Our weekly pulse check showed us that satisfaction in this area increased quite quickly. Data! Hooray! 

By releasing thought work often, our employees became accustomed to collaborating in this way on a topic that can be uncomfortable. This eased some discomfort. Now, when we gather new feedback and make improvements, which we do a few times a year, it’s not a shock. It is our company getting better in a super visible way.  

So you see People people, while the term “working product” might feel like it can not apply in our work, it absolutely does, with bonuses! I’d love to hear what kinds of real-world examples you have of “releasing early and releasing often.” What were your successes? What did you learn?  

Que tengas un mes de abril estupendo y no te dejes abatir por los chaparrones. Se anuncian flores y colores. Hasta el mes que viene.