From Bench to Rafting at Proximity

From Bench to Rafting at Proximity: How we created our R+D+I group

Sometimes solutions to problems come in the most unexpected way. Like this past January, when some unexpected news sparked an idea that allowed us to create our Research, Development and Innovation group without exceeding our current spend. In fact, we also generating extraordinary results along the way.

So, in the next few paragraphs, I will share with you our journey from bench to rafting.

Unexpected news

It all started back in January 2015, when we received some bad news. After being with the company for just a few months, I had to step out of the office for a couple days to co-train a Certified Scrum Master workshop. The team I was asked to focus on was doing great, so I didn’t feel any apprehension for not being around for a while.

However, he morning of the workshop’s first day, I learned our largest customer was requesting a temporary downsize in its operation with us. So I touched base with management. Fortunately, they told me they would handle it and to carry on with the workshop as planned.

Yet emails kept going back and forth with one big concern in almost every one of them — bench. While this is a situation outsourcing companies are used to, it’s still one that’s undesirable.

Small talk and innovation

So I spent the rest of the morning split between the joyful experience of spreading the Agile mindset and the unfortunate situation back at the office. Bench, bench, bench… that word resonated in both emails and in the back of my head all morning.

Then came our lunch break and a networking opportunity — something I always welcome during workshops. So I stepped in line for the buffet and started looking for spots to sit with strangers, wanting an opportunity to jump into conversation.

This led me to start talking with a couple of young developers from a competing company. They belonged to the company’s Research and Development unit. As the small talk between us continued, I started wondering why we didn’t have a Research and Development unit.

Once lunch finished, I quickly checked me email before stepping back into the workshop room. My inbox was filled with more bench-related messages.

That’s when I had the epiphany — bench was to become our new R+D+i unit.

Making it happen

For a few days after the workshop, I dealt with the downsizing situation and took care of the logistics, transition plans, knowledge transfers, etc. I also started shaping in my mind how I was going to present the idea to transform the usually boring bench experience into something dynamic, fun, and productive.

My experiences in previous engagements showed me that sometimes even the brightest of ideas encounter friction and reluctance to change. And this was the first time I was to present an idea like this to the company. Of course, I didn’t know the company’s culture around such proposals. But there was only one way to find out…

Initially, I tiptoed a bit when I introduced the idea to Tomas, my boss. However, he was immediately engaged and we decided to spend a business lunch to better shape the idea.

During lunch, something funny happened. When I described how I envisioned the switch from a boring, idle-time bench situation to a one-week Scrum run R+D+i unit, I told him that, in my perfect world, falling into bench would be like falling into a fast-running river. It would be a vertiginous yet fun experience… like rafting!

Tomas immediately picked up on the idea and said “You know what? I like that, let’s call it ‘Rafting.’” I loved the analogy and that’s how our R+D+i unit was born like rafting.

However, we were not there yet. After we agreed on the mechanics and goals for it, there remained some unanswered questions, such as:

How do we nurture the backlog?
What tool do we use to keep track of things?
What if rafting turns out to be so cool people won’t want to leave?
What if people who always have a smooth transition between projects or a long-running project engagement become interested in participating in the rafting experience?
How do we make it work with the two-company (Proximity & Isthmus) partnership?
How do we keep the research and innovation efforts going when we don’t have anyone in rafting?

Done is better than perfect

The answer to all these questions came in the form of an Agile proverb: “Done is better than perfect.” So we decided to kick it off right the next Monday and then inspect and adapt as we went.

So we started by defining who the Product Owner would be for the first few iterations. As there wasn’t an obvious fit, I offered to wear that hat (which I quickly passed to someone else). Then we identified a Scrum Master.

There was a developer whose unquenchable thirst for knowledge and passion for coaching was unparalleled. He was not knowledgeable on Scrum, but we saw this just as an extra learning opportunity and positive side effect of this experiment.

So, after having the Scrum Master’s agreement to participate in this new little exercise, we gathered the team for a quick Agile & Scrum 101 session. After that, we conveyed the vision for the first project and had a brief planning session. The following Monday the team presented their first working piece of software.

Since then we’ve had a few people arriving and leaving rafting. Having one-week sprints has not been an issue at all. We’ve delivered most of the time and, as I mentioned earlier, already switched the product owner. (I keep orbiting the team as their coach.)

Overall, people are engaged, learning and delivering.

Having fun

And so that’s the story of how we turned a static, boring and burdening bench into a fun, vertiginous rafting experience.

Are we there yet? No.

Have we inspected and adapted as we wanted? Definitely.

Is it working? Yes, from many different points of view:

People are now clear on what to do the first minute they are not assigned to a client, as long as we have a nurtured and well-groomed backlog and keep the sprints running on short timeframes.

We gave one of our peers the opportunity to be rafting Scrum Master, as another way for him to learn the craft. And he is doing a great job!

Rafting is productive! With just a few weeks into it, we have already delivered a few little (yet usable) software increments.

Peers outside rafting are thrilled by the idea and happy to see their peers be productive when they are not assigned to a specific project.

Rafting has also become our sandbox for engineering practices and technologies, and people are having fun trying new things.

Rafting is also helping us spread Agile principles and familiarized people throughout the organization on with the Scrum framework.

So far, so good. And the best part? Rafting’s future is exciting and full of potential! For instance, we believe we can also use rafting for things such as:

Generating a “wow effect” on our customers by having rafting solve problems that a customer or our teams can’t take on due to their daily priorities.
Use it to more effectively to transfer knowledge between companies.
Have it become a micro-incubator. (We have very talented and creative people who have brilliant ideas they would like to develop with us.)
Have it function as an A-Team, ready to kick off as part of our sales efforts. This would lower our customers’ barrier of entry by allowing them to immediately hire just one sprint with us. So we can prove how quickly our teams can deliver value.
Open our doors to interns from technical schools, colleges, and similar institutions.

And this is just the beginning…

By Fred Madrigal

Software Development Manager