One of the great things gap intelligence does as a company is encourage its employees’ job-related professional growth and development. What this essentially means is gap will cover reasonable expenses incurred in joining professional organizations with the approval of your manager, of course. Well one of these opportunities came up for me recently and I chose to take advantage of it. But…before I get into what I did, a little background first.

We at gap intelligence are an agile development shop. Agile is a methodology, or mindset if you will, defined by a set of values and principles. Here are the 4 values:

  • Individuals and interactions over processes and tools.
  • Working software over comprehensive documentation.
  • Customer collaboration over contract negotiation.
  • Responding to change over following a plan.

And the 12 principles are here if you are curious: https://www.agilealliance.org/agile101/12-principles-behind-the-agile-manifesto/

There are a handful of ways you can practice agile development. At gap we use one of the more popular frameworks, called Scrum. According to the Scrum Alliance:
"Scrum is a framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value."

If you want some insight into how we are practicing Scrum, Natasha Belak-Berger, recently wrote about our Scrum Ceremonies.

So, with that, I was given the opportunity to become a Certified SCRUM Master!!

So in true gap fashion, we always start with the “Why”.

Start with why image

allhealthykids.org

The Why

Why would a software engineer want to get Scrum certified? Well, the answer is simple really. Our current Scrum Master was going on paternity leave soon and we needed somebody on the team to step up and fill this role temporarily. I had already been filling in as the Scrum Master at times, facilitating our daily stand up meetings, so I was a good candidate. It was a win-win situation for me. I would become more knowledgeable on the subject matter and become a stronger member of our Scrum Team. I also felt that I’d gain a better appreciation for the Scrum Master role (as well as other roles). So that is my WHY.

Now, why am I writing a blog about it?? There are tons of sites that explain Scrum and how its used, but this is not my intention here. This is the third company I’ve worked for that has utilized Scrum and each and every company did it slightly different. That’s the beauty of Scrum in that its JUST a framework or a guide. In this blog I’ll talk about my takeaways from the 2-day course that I attended. I’ll also talk about some of the things we do differently in Scrum that work for us. I will tell you about some of the challenges I’m facing as a Scrum Master. Lastly, as an added bonus, I'll reveal some great tips/rules you can incorporate into your Scrum process!!

Person wearing a superman-like shirt, with SM on its chest.

medium.com

Certified Scrum Master Course

The course was facilitated by a gentleman named Peter Green, who is a Certified Scrum Trainer. 

I would say the thing I enjoyed the most about the course, was that it was very interactive. The activities were engaging and I actually had some fun! The final activity was definitely the best, where we performed a scrum simulation (with shorter sprint cycles of course). Our project was to build one huge playground using only construction paper, tape, scissors, markers, straws, and twisty ties. We broke out into about 6-8 cross functional teams and during each sprint cycle, each team would commit to some user stories. In true scrum fashion we would iterate through each sprint cycle, delivering value to our product owner, which was our Scrum Trainer in this case.

The biggest takeaway I got during this exercise was that, when estimating user stories, the actual point sizing is not that important. The most important part is the discussions that come out of the estimating exercise. Yes, there are times where the entire team will come to a quick consensus, but most times that doesn’t happen. When this occurs there is a ton of value in the conversations that are initiated.

Through this scrum simulation, I also got some great advice that we have already put into play in our Scrum process at gap. That is, during the Sprint Review/Demo, that we ask our stakeholders lots of questions. The demo is where you have all the folks that are heavily invested in the product being built, and the feedback we get is invaluable here.

One last lesson I learned along the way, was about the importance of writing good user stories, and the acceptance criteria that goes with them. Here is just a few of the benefits of well written user stories:

  • Helps deliver the highest value by focusing on small and immediate customer needs
  • Fosters collaboration among the development team, product owner and users of the system
  • Increases transparency among team members, product owners & stakeholders
  • Gets everybody on the same page

I’d definitely recommend this course to anybody who wants to strengthen their knowledge of Scrum and of course if they wanna get certified and become a Scrum Master. Despite using Scrum at three different companies, I still learned a great deal throughout the course.

Scrum workflow diagram

scrumalliance.org

Scrum at gap

As you iterate through each sprint, you will make tweaks along the way to improve your workflow. There are some things you will try that won’t stick, and that’s okay. We recently made a big change in the way we Scrum that seems to be working out great for us.

At gap, we have lots of projects that we have to maintain. We are also simultaneously working on new development. So what we decided to do, was split our team into 2 Scrum teams. A road map team, which is for new development, and a prod support team for maintaining our existing software/tools. We have a product owner assigned to each team and we have a developer rotation, in that one developer will never get stuck on the same team for more than two sprints in a row. Each team has their own product backlog space as well in Pivotal Tracker.

As an entire team, we groom the product backlog each and every week for the road map team only. There is no need to groom our prod support backlog, because they are mostly bugs and tweaks to our existing software. A lot of our customers are internal and they report bugs to the product owner, and this is how our prod support backlog gets groomed.

For the prod support team we do not plan the sprint. Developers will grab the user story at the top of backlog and start crushing bugs for that two week sprint. As for the road map team, we don’t really plan the sprint, in terms of committing to ‘X’ amount of stories/points. The idea is that at sprint time we should have more than enough in the backlog for a two week sprint. So with that, it’s really important to keep our road map backlog nice and beefy! With that, backlog grooming is a really important scrum ceremony.

With this new approach we also made a tweak to our daily stand up meeting. The Scrum Master will go thru all open stories and ask each developer these 3 questions:

  • What was done on this story yesterday?
  • What will you do today for this story?
  • Do you have any impediments?

So essentially what you would do during a normal stand up, but on a story by story basis. This keeps us all on track and is super transparent!

So as you see, Scrum can be tweaked in ways that fit your team/company. Early on in our development, we definitely did Scrum more by the book. We know we are drifting away from Scrum slightly, but that’s ok. We like where we are at right now with our workflow. We seem to be headed more towards Scrumban, which is a framework that has surfaced recently. You can read up on it here: https://www.agilealliance.org/what-is-scrumban/

Challenges

They say that Scrum is easy to understand, but difficult to master. It definitely has its challenges and I’m facing one myself. The biggest challenge for me thus far is changing my mindset from a developer to a Scrum Master during some of the Scrum ceremonies, especially during product backlog grooming. My brain immediately goes into the “how” I  will resolve this user story. The Scrum Master should never decide the HOW, but they can ask questions of course. The Scrum Master should JUST be the facilitator during the meeting. So going forward I need to make sure the entire team is always focused on the “What” and not the “How” during grooming and daily stand up meetings. Its definitely work in progress for me.

Freeway sign with the text "Free Advice Next Exit"

atzmut.com

Advice and Tips

And now the part you all have been waiting for…..my Scrum advice! Here is a list of tips we have implemented into our Scrum that have helped us out a great deal. I hope they will help you as well.

  • Don’t be late!! Yes, of course things come up, but so long as you let the team know, it's all good. We want our Scrum ceremonies to be efficient so let's be professional and be on time. Easy peasy!
  • No cell phones/laptops during Scrum ceremonies (except product owner/scrum master). These are distractions and we are able to focus more during meetings without them.
  • It’s worth mentioning again…always have a well groomed product backlog.
  • Communicate like hell (Also one of our company’s core values)
  • Demo Prep! Developers, it's your time to shine and show off the work you have done. Be prepared so the demo can go smoothly.
  • Dev Days. Once a month developers get to work on anything they'd like to (within a certain set of rules of course). It's a great change of pace and gives you time to learn and improve your skills.
  • Get your Retro ON! The most important Scrum ceremony to us at gap! My fellow team member, Natasha, wrote a nice blog on the importance of the retro ceremony.
  • Find something to improve your Scrum process with each sprint iteration. At the end of our retro meetings, we discuss things that didn’t go well in the previous sprint and we try to identity ways to improve our process.

Wrap It Up

In closing, if you are not practicing some kind of agile development, you really should consider it. Scrum is a great choice for a framework, but that’s just where it starts. It really comes down to the people. At its core, Scrum is made up of great values: commitment, courage, focus, respect, and openness.  EVERYBODY has to buy into these values and the process in order to really make it work. I’m very fortunate to work with a great team that lives by these values. I’d also like to throw in that they align so well with gap’s core values.