We at gap intelligence are an agile development shop. Recently I blogged about how I became SCRUM Master certified. In that blog I discussed how we use SCRUM and how we have tailored our process along the way to find what works best for us. Every SCRUM team is different so what works for one team, may not work for another. Remember…SCRUM is just a framework or a guide. As a team we can iterate with each sprint and improve upon your team's scrum process. We specifically set aside some time in our Retro meeting to discuss how we can improve in our upcoming sprint. A fellow gapper, Natasha, wrote a nice blog on the importance of the retro ceremony.
The Handoff
One of the many tweaks we have made to our process was introducing something we call a developer handoff. Before I expose what exactly a developer handoff is, let me give you some background first about our team structure. We are a distributed SCRUM team. We have an office in Tashkent, Uzbekistan currently housing four of our team members. Working in a distributed team definitely has its challenges, and something we are constantly working to improve upon (maybe I will explore distributed teams in a future blog).
A trend that we caught on with our team, was that at times, we’d have way too many stories opened at the same time. This was one of the main drivers behind why we decided to introduce a handoff process. A very wise SCRUM Master (Michelle Nation Monaco) once told me……10 stories that are 99% done are 0 stories that are DONE, DONE. As we like to say now, “ABC"…always be closing! One of our many great sayings we have as reminders to stay the course on SCRUM. As an added bonus, it was pretty nice having a story being worked on around the clock (especially if its a high priority support ticket).
So in an effort to close stories more often during a sprint, the developer handoff was born!
A developer handoff is simply when a developer passes off their work in progress, from a given story, to another developer on the team so they can keep working on this story. The process is simple….at the end of each developer's day, if there is a story that is not yet complete, the story becomes a handoff. In our first iteration of this process the developer simply had to commit their work to the remote git-branch and then post a link to the Pivotal Tracker story in a slack channel we created called “dev-handoffs”, dedicated solely for stories that need some more love.
Communicate Like Hell
We found out pretty quickly that posting a link to the story wasn't quite enough though. We needed more context around the story and progress in order to help developers understand exactly what got done so far. So we decided to take the “communicate like hell” approach with this process. After all, transparency is one of gap’s core values (you can check out our other awesome core values on our company website).
By applying our gap core value of communication, we definitely saw improvements. This change made the transition easier for developers when they grabbed a handed off story. If there were any challenges or gotcha’s along the way, the ticket was the place to communicate that kind of information.
The most recent change we’ve made to this process, is that we now give the developer who starts the story the option to hand it off. They can hand the story off at their own discretion now, which some may prefer, sometimes it depends on the story. This new rule has been in place for almost two months now, and we are still seeing stories being handed off quite frequently.
We’ve had the handoff process in place for some time. We have had a lot of good, and also some challenges. Lets start by stating some of the benefits first.
The Pros:
- Stories tend to close faster, since we are more focused on getting stories to meet our definition of done
- Critical stories can be worked on almost around the clock, because of the time difference between US and Uzbekistan
- We improve our collaboration and communication skills, both of which are key to making this process work
- Developers get more exposure to each others code, which is a good way to learn new techniques, approaches, styles of coding, etc.
The Challenges:
- Stories can go in lots of different directions, as some developers may take different approaches with an already started story
- Starting work on a handoff story can take time, as each developer needs to take time to understand the scope of work and what’s been done on the story already
In regards to the first challenge, here is a good example:
Developer A takes one approach and runs into some issues with their approach. The story gets handed off and Developer B takes an entirely different approach. Although sometimes this can backfire, it has actually been successful as well. This can of course go bad when the new approach taken doesn’t work. That being said, being bold and trying other things should be commended as well!!
Conclusion
Although this process always has room for improvement, it is something that we have incorporated as part of our SCRUM process for a while now, and in my opinion, that says a lot. Now that we added some additional flexibility to the process, it seems like one that will stick for good in our SCRUM!
For more than 15 years, gap intelligence has served manufacturers and sellers by providing world-class services monitoring, reporting, and analyzing the 4Ps: prices, promotions, placements, and products. Email us at info@gapintelligence.com or call us at 619-574-1100 to learn more.
