Better, Bit By Bit: Delivering Useable Increments
par Jessica Jagoditsh | 26 mars 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 Incrément” 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!
Problème : 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 pourrait 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?
Have an amazing April and don’t let those showers get you down. Flowers and colors are in the forecast! See you next month!