Sometimes solutions to problems come in the most unexpected way. Like this past January, when some unexpected news sparked the idea that allowed us to create our Research, Development and Innovation group without exceeding our current spent, and generating extraordinary results along the way. In the next few paragraphs, I share our journey from bench to rafting.
It all started back in January 2015, when we got some bad news. After being just a few months with the company, I had to step out of the office for a couple of days to co-train a Certified Scrum Master workshop. The team I was asked to focus on was doing greatly so I didn’t feel any apprehension for not being around for a while.
But our friend Murphy knows how to deliver. In the morning of the workshop’s first day I got some unexpected news: our customer (the company’s largest) was requesting an important temporary downsize in his operation with us. So I got in touch with company’s management and they told me they were going to handle it, to carry on with the workshop as planned.
However, e-mails kept going back and forth and a big concern was present in almost every single one of them: bench. This is a situation that outsourcing companies are used to, nevertheless it is always a non desired one.
Smalltalk and innovation
And so I spent the rest of the morning, split between the joyful experience of spreading the Agile mindset and the downsize situation back at the office. Bench, bench, bench… that word resonated in both the e-mails and the back of my head all that morning.
Then came lunch break, a networking opportunity I always welcome during the workshop. So I get in line for the buffet and do some smalltalk with the fellows around and then look for a spot to sit between complete strangers, looking for an opportunity to jump into conversation. So I start talking with this couple of young developers from a competing company and they tell me they belong to the company’s Research and Development unit. Smalltalk goes on but I start wondering why we don’t have a Research and Development unit ourselves and how do I change that… Lunch finishes and just before stepping back into the workshop room I quickly check e-mail where I find more bench related messages. And that’s when the epiphany strikes! Bench has to become our new R+D+i unit.
Making it happen
The few days after the workshop, I had to deal with the downsizing situation, take care of the logistics, transition plans, knowledge transfers, etc. However, 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 had shown me that sometimes even the brightest of the ideas encounter friction and reluctance to change. And this was the first time I was to present an idea like this to the company, not knowing what the company’s culture around such proposals were like. But there was only one way to know…
I must recognize that I initially tip toed a little when I introduced the idea to Tomas, my boss. He was immediately engaged on it and we decided to spend a business lunch to better shape it. And so we did.
During this lunch, something funny happened: when I described how I envisioned to switch from a boring idle time bench situation to a 1 week Scrum run R+D+i unit, I told him that in my perfect world, falling into bench would be for people like falling in a fast running river, 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 had agreed upon the mechanics and goals for it, there remained some unanswered questions, like:
- 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 that 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 companies (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”. 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 was able to lend 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 on 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 yet effective planning session. Next Monday the team was presenting their first working piece of software.
After that we have had a few people arriving and leaving rafting, which having 1 week long sprints has not been an issue at all. We have been able to deliver most of the time and as I already mentioned, have switched product owner already (I keep orbiting the team as their coach). Overall people is engaged, learning and delivering.
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 have given 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 doing 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 is having fun trying new things as part of it.
- Rafting is also helping us spread the Agile principles and have people familiarized with the Scrum framework throughout the organizations.
So far, so good. And the best part of it? Rafting’s future outlook is exciting and full of potential! For instance we believe we can also use rafting for things like:
- Generating a “wow effect” on our customers, by having rafting solve problems that neither the customer nor our teams can take on due to their daily priorities.
- Use it to more effectively transfer knowledge between companies.
- Have it become a micro-incubator (we have very talented and creative people that we are sure 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, lowering our customer’s entry barrier by allowing them to immediately hire just one sprint with us, so we can show how quickly our teams can deliver value to them.
- Open our doors to interns from technical schools, colleges and similar institutions.
And this is just the beginning…
By Fred Madrigal
Software Development Manager