Right now I'm reading through the book by uncle bob called "Clean Agile: back to basics".

The first two chapters are mostly about the history of Scrum and some of Uncle Bob's experience.

So I also wanted to talk about my experience in different companies with different levels of scrum/agile processes.

And again this is from a view from a developer! Not a Scrum Master or Product Owner or tester etc.

Okay so let's start now.

PO is too technical and assumes how long it will take

The best product owners I worked with where nontechnical and also did not even where thinking about technical details. On the other hand the worst product owners I worked with where ex-developers and would think they know the project from the software side still good enough to assume how features should be implemented.

I'm not saying that developers can not be good product owners but they need to think about the feature and the benefit for the client and not technical details.

In the best case, this can leave developers annoyed and frustrated at worse this can lead to false promises to the client and a higher churn rate because of dissatisfied clients.

The problem is that even if they don't try to think about how to implement it, in the back of there mind they are still doing it without really knowing all the implementation details they should think of while implementing that feature.

People are in meetings they should not be in

In some companies, they allow having silent listeners to meetings. This silent listener can be a stakeholder, a manager, a c-level or the PO. Just to name a few examples that I have seen over the years happen.

Let's take the sprint retrospective as an example. This meeting is just for the scrum team and if there is on the scrum master. This meeting should be a safe space for the team where they can talk about everything and how they can improve the next sprint.

If there is even one person not from that team and people don't feel safe anymore you will have a big problem. Most of the people will say that everything went good and you will have nothing to improve. The moment you have nothing to improve is the beginning of the end for that team. You can always improve the sprint. Starting from preproduction or the testing at the end of the sprint. It is never perfect.

Do you really want to talk about the strange features or the strange promises given by the higher-ups and their unrealistic user stories while they are listing? Of course, you should not only say how bad they are but you should be able to freely discuss in your team if only you feel that way or maybe it is a problem for other people too and how best to solve it.

Silent listeners in meetings are not silent

Also, it happens too often that these silent listeners are not silent at all.

Usually, they just want to clarify things or say that this is not how they meant it. This is a fair point but again its neither the place or the time to discuss this.

Silent listeners should be silent and people by nature want to straighten out things and explain.

I'm highly against silent listeners in any meeting. In the real world, it just not works.

Communication is only going while the daily scrum

For the start: I'm not the biggest fan of the daily scrum. Often Scrum Masters will tell you that you need how the sprint is going and what others are doing. When I ask back why do I need to know it on a daily base, they answer that we need to see if we will finish the sprint. When I then say that I can take a look at the burndown chart all the time and look at it they usually come up with other stuff.

Back to the topic. I see this often with junior developers they will wait with there problems and get frustrated at 1pm and wait until the daily scrum next day at 10 am to tell there problems and frustration. And yes they just wasted around 6 hours of not doing anything except looking at a screen and being frustrated.

Again from my experience, the best teams could finish their sprints on time and with good quality when communication would be as fast as possible.

This does not mean that you would blindly go to your colleague and talk to him while he is focusing. We have slack and you can write that person and that person should come back to you as soon as he is done focusing. This is usually not longer than 1 hour. More often it is like 15 minutes. Still, both are under 6 hours.

Product Owners should protect the scrum team

This is also a common problem in scrum working environments. The Product Owner has this role between the scrum team and the stakeholders/clients. Both sides are pushing either to get features out faster and developers that want to create the perfect system that will take 10 sprints but we only have like 2.

So the job is to find the perfect balance between pushing back on both sides! Sadly what happens too often is that the scrum team gets a feature that is impossible and the product owner just forces it on the scrum team and they should think how they could deliver it. Sometimes you can cut the fat from a feature but sometimes it is not possible and what you will get in the and is a poorly implemented feature that nobody likes to use and nobody wants to touch and will rot away.

The problem here usually is a trust problem from the Product Owner side. Trust in the agile/scrum world is very important. If one side does not trust the other then you have a big problem because scrum is also about openness and that everybody can say what they think and still be trusted

Do you need help with your agile process?

Drop me an e-mail at michael@lampeweb.de and we can work it out together on how to get your agile process up and running!

Like, Comment and share so that I can see that you like this story!

👋Say Hallo! Instagram | Twitter | LinkedIn | Medium | Twitch | YouTube