Vertical Scaling with Scrum

One team for multiple projects

7 July 2014

Holger Berndt
BiDcore GmbH


We started with Scrum in 2013. It was an amazing change, and the whole company decided going forward this way was right.

Well, we've all read these lines a hundred times. Why is this worth writing about?

In short, our company is young and small, but we have many concurrent projects with changing team members. All the tools we need to build individual software products are basically Agile:
  • Using collaboration tools such as Wiki and unified communication
  • Using a flexible task board that works with Scrum and Kanban
  • Using continuous integration tools
  • Meeting periodically with our customers
  • Using tools such as Maven for standardized projects

We started a short and effective transformation.

Until this transformation began, none of our customers had heard about Scrum or Agile. We calculated in hours and days. Only colleagues who were assigned to a particular project worked on that project. These things had to be changed. Read on to learn how we transformed our customers, our teams, our business, and the way we work now.

First, we started to involve our customers. As with most organizations, there didn't seem to be time to introduce the entire framework, so we identified the people for the different Scrum roles internally, and then discussed the objectives. It was an amazing process. Every role member on the customer side emerged with quite a good understanding of the requirements of his/her role, even without knowing the role's real definition and name. We now had product owners, stakeholders, and team members on the customer side with no introduction (yet) of new terminology in their environment. We just defined the responsibilities.

Next, the whole team began rotating over all projects. We recognized improved quality in our software and a better service level for our customers. We handle the Daily Scrum via conference tools. The sprints are a little bit longer than usual, an average of six to eight weeks. Our customers, however, have a better understanding of value and price.

Related to this is the fact that calculating in story points and business value is a big improvement. Prior to this company change, we had to explain every day of work. We now define price ranges for story points and complexity. They relate to the business value and much discussion becomes needless.

In fact, we are not finished transforming on all projects. We have to discipline ourselves every day. In retrospect, however, it's clear to us that this way is much better for us than operating under the old-school Waterfall method.

The next step will be to offer transformation projects for our customers. It would be awesome if our customers and their teams became Agile and started to think in this same way, wouldn't it?


Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.



Article Rating

Current rating: 3 (1 ratings)

Comments

Be the first to add a comment...


You must Login or Signup to comment.


The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.