alpha-board: 8 months with Scrum in hardware

It's almost a year now that I wrote a three-part blog about the agile voyage of alpha-board, a Berlin-based service provider for agile hardware development with Scrum. Back then I supported them in improving their daily routines and especially in implementing a new approach concerning customer requirements. I used a subsequent visit to find out which changes had survived the daily routines and which ones had not gained acceptance. Alongside these questions, I asked the members of the Scrum team what – from their point of view – had changed positively since the introduction of Scrum and what had been better before.

Changes that survived

Two things caught my eye right away:

• The structure of the task board had not changed at all. The team uses it every day and it seems to cover all necessary processes.
• The weekly sprints had survived as well. Every week, users can give feedback on a ready-to-test product increment.

Usually, hardware teams think about expanding their sprints to four or even eight weeks. So I cannot emphasize enough that these high-performance teams in the middle of Berlin are able to deliver usable hardware prototypes every week! Congratulations on that, alpha-board!

What didn’t work?

A consistent estimation practice. We tried to estimate complexities and we tried to estimate functionalities but it did not work out as well as we intended.The statistical data derived from story points and time was very volatile. Because the team could not rely on its own estimation, it was challenging to communicate fixed prices to customers. For enhanced transparency about the units, Julia (ScrumMaster) and Matthias (Product Owner) will ask for several metrics for each story separately during the next months and they will look for patterns.

The retrospective on Scrum

If Scrum is lived as an agile management framework, we need to critically inspect and adapt the status of framework implementation regularly. Since the introduction, alpha-board strictly followed the process and the team learned what it takes to do Scrum.In a trustful retrospective reviewing the last eight months, I asked for critical and truthful feedback. Thank you alpha-board for having the courage to publish this, so others can learn from it. Here are the key points:

What changed positively

• Transparency within the company
  • Increased knowledge transfer (between developers, sales and marketing)
  • Goals are clearer
• Communication within the team
• • Better communication
  • Pressure of work is shared in the team
• • Better coverage of work progress (e.g. when someone is sick)
• Quicker billing because of smaller product increments

What was better before Scrum

• The mood between the teams (scrumming and not scrumming)
  • Less competition
• Estimates were more exact

What makes Scrum implementations successful

While the people were voting problems and prioritizing measures, I had some spare moments to do my own retrospective:On a long-term basis, even if there is a sense of urgency to change, people must have the will to do Scrum. This is a major challenge for managers when they want to introduce the agile framework in their departments. The natural inner resistance to change often leads to “Scrumbut” implementations. People cherry-pick certain aspects of Scrum they are familiar with or they find easy to use. Usually these kinds of implementations do not work. If the term is stained once, it is hard to introduce Scrum again properly.That is why companies need practicing Scrummers from the beginning. They can share experiences, adapt the framework in a way that works under special conditions and they can react confident in challenging situations.With this in mind, yoursMarcus.