When we kicked off the development of our new suite of products in early 2016, we quickly realized that we had to improve our approach to workflows. Even with increased manpower, initial development wasn’t as productive as we had hoped. In a bid to improve teamwork, we came up with the idea of having smaller teams iteratively work on defined sets of tasks over short timespans. Once written down, it dawned on me that we had just described a very simple version of the Scrum framework.

Since then we have come a long way in transforming our product development to follow Agile principles and using Scrum for product development. Like in most organizations, it has been quite a journey and we learned a great deal about ourselves and Agile at every step. While we still have a lot of work ahead of us, the first six months gave us insights into what a transformation to Agile Scrum really means.

You Can Start Immediately

We didn’t prepare much before we started our first “sprint” (work phase). All we had was a small backlog and a team of six people. We wanted to just try it out for a week to see how we’d do. One morning, we held a short meeting and selected a couple of tasks from our backlog that the developers thought they could finish in the next five days. The results exceeded everyone’s expectations. The increase in focus and efficient teamwork resulted in the selected tasks being finished after just two days. We had to scramble to find more work and increase our scope. The developers loved it and so did the project management. Productivity was high, and we had the numbers to prove it, too. The second sprint followed immediately after, and three weeks later, we began rolling out Agile and Scrum across the whole company.

If You Get the Core Values Right, Everything Else Will Fall into Place

Faced with a need to improve our project, and being aware of existing time constraints, we were prevented from planning our Agile workflows in great detail. That didn’t stop us from becoming skilled at implementing Scrum, particularly within our development teams. What makes this implementation possible is a clear understanding of the core values of Agile Scrum, and the reasons the methodology works. At EQS, Scrum is used for one reason only: to provide clarity and efficiency for everyone involved. We want to make life as easy as possible for developers and product owners, so everyone can focus on delivering great work. If a part of the process helps, we implement it, if it feels burdensome, we remove it. We constantly monitor processes to identify problems as quickly as possible. We also don’t set numerical properties, such as velocity or cycle times, as targets that must be reached. Instead, we use them as measurements to track if our Scrum implementation is working.

Scrum Is Only Half the Story

Scrum is a great methodology for streamlining product development. But, if you look closely, it only describes processes once you have items in a backlog. However, it does little in terms of instructing teams on how to create those items. During the first couple of months, we struggled to supply enough backlog items for the increasingly-efficient development teams. This may sound like a dream situation to find oneself in, but it became a steady struggle not run out of work. We soon began developing our own processes to create workable stories from various stakeholder requirements. And while this isn’t hindering development processes anymore, implementing and refining this workflow is an ongoing task with room for improvement.

Tooling Helps

Once we began improving our workflows and processes, the value of JIRA Agile software became more obvious. While Scrum can, in theory, be done on a whiteboard with Post-its to keep things quick and simple, using powerful tooling does pay off quickly. We now integrate the data of our Scrum teams and project teams all in one place. At this stage, we can fine tune resource planning on a company-wide level in near real-time.

You Can’t Go Back

When I said earlier that the development team loved using Scrum – I wasn’t exaggerating. This lead to a situation where parts of our development department were very happily sprinting away, while other developers still used earlier methods. As is common at EQS, the various teams weren’t shy about how they felt, and we had to respond quickly. Even though our Scrum processes were still in their infancy after just two months, we decided to start using them for all product development teams going forward.

You Won’t Regret It

The changes that occur when introducing Agile and Scrum are far-reaching, and the process itself is not without hardship. But, when looking back, the only thing I regret is that we didn’t start much sooner. Productivity, especially among some of our more long-standing teams, is on a different level now, all while having happier, more relaxed developers and project managers. It’s no surprise that Scrum is quickly becoming the most widely-used product development methodology out there.

Tips For Introducing Scrum

Introducing Agile and Scrum went very well for us, in large part due to our corporate culture, which emphasizes freedom and experimentation. We still have a lot of work ahead of us, but even now, the benefits vastly outweigh the costs. We are now in the fortunate situation of improving an already working process, and getting even better.

If you are interested in trying out Scrum like we did, these three steps will help ensure your trial is a success:

  1. Explain your experiment
    Be upfront about experimenting with Scrum, especially with your team. Give them a short introduction about Scrum and Agile. Explain which parts of Scrum you’re going to use, and which parts are not being included yet. Set realistic expectations and get feedback before you start.
  2. Take a little time to prepare a backlog
    Your first sprint will be most effective if you have well-defined items in your backlog. These items should have clear acceptance criteria, and completing these items should be doable within your defined time-frame (e.g. one or two weeks). Have a meeting with your developers to discuss the items and rewrite them if necessary.
  3. Make sure your developers can focus on your sprint
    When you start with Scrum, what you’re really focusing on is efficiency. It is vital that your team can focus and the backlog tasks during your first sprint. Only then will you get an idea of what Scrum really feels like.

 Want to join our happy developers? Check our job offers.

Related blog posts

Back to home