Why your Scrum Team is not performing as it could

Did you ever had the feeling, your team could be better? Have a higher performance? Be able to produce better outcomes?

I'm not talking about successfully finished sprints versus failed sprints or the constant struggle to increase velocity.

I mean your product - that thing your team is building. May it be your company's product or a contract work for another company.

Thinking back a couple of sprints

I was part of a team that was doing good solid work. We had our stakeholders, a clear vision, we gathered requirements, collected ideas, made short term and long term plans and started to work. We produced good quality. I'd say, we were even quite proud about the results. It was exactly what our stakeholders wanted.

After over one year of working, we got more and more frustrated. We didn't understand it back then, but we had a substantial problem going on - and we constantly ignored it while trying to produce the best results for our stakeholders. This was phase one.

We kept going this way but with a slight shift of priorities: we got a new stakeholder. We started again: gather requirements, collect ideas, plan, work, repeat. Entering phase two.

This time, everything was faster. This phase lasted for about three months. Still not very clear about what problem we had (again!), we worked almost in the same way as before. All we tried to achieve, was to build the best solution. But actually, we never had a real chance.

To put a long story short: in the end, all of us were frustrated, miserable and demotivated. The key stakeholder resigned from the initial goal. The job was gone. Eventually, the whole team broke apart.

The omnipresent problem that hindered us from becoming successful

The whole time, we worked on building the desired solution. In an agile way, we thought.

We just missed one thing: we did not have an end user.

Well, we had a client. A stakeholder. Someone with money to pay for our work. But there was no customer we could have given the solution we built to.

There was no way for us to actually verify our solution. This was the major problem we haven't fully realized the whole time.

Working truly agile

Working agile has more to it than doing daily stand-ups and retrospectives. One key aspect of being agile is to be able to react to change. Since agile usually also means that you don't have all requirements - including but not limited to what the end user wants - upfront, you need ways of defining those requirements towards the final result.

By yielding incremental results sprint after sprint, you have not only the chance to solve a big problem by solving smaller subsets of it but also to verify the solution.

Usually it is just not enough to check the result with your stakeholder, especially if it is the stakeholder alone. If there will be end users for the finished product you have to have end users for the product increments. Otherwise, you have no chance to verify what your team is doing.

With end users at your disposal, change can be introduced through gathered user feedback and key measurements. Verifying important aspects of your solution along the way increases the likelihood that your solution and your team will be truly powerful.

Reading Tip

(AL) = affiliate link
The links marked with (AL) are so-called "affiliate links". If you buy something from the seller via this link, I get a commission from your purchase. For you the price remains unchanged.
Die mit (AL) gekennzeichneten Verweise sind sog. "Affiliate Links" (Provisions-Links). Wenn du über diesen Link bei dem Anbieter etwas kaufst, bekomme ich von deinem Einkauf eine Provision. Für dich bleibt der Preis unverändert.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.