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
Top comments (36)
Agile has some lofty assumptions. Primarily, that people can communicate efficiently and well:)
We should be able to go into a meeting and speak our minds regardless of who is at the table. Our statements should be based in non-accusatory/non-blaming behavior statements followed up by how it affects us personally and/or feeling statements crafted with reflection and honesty based in the personal experience as much as possible.
I should be able to tell my higher up how and why her idea negatively impacts the team-- and my higher up should understand that's how agile works: a team working together with full awareness of the situation so they can respond collectively. Impartially.
So, I think the issue lies more with how agile assumes good communication in a world where office communication is a good interpersonal communications course away from being effective.
As a PO and SE/Lead I enjoy knowing the tech. It requires humility and a constant questioning of which decisions are based in ego or laziness and which are customer focused, but at the end of the day, I'm able to understand my team's situation and accurately convert those situations to my clients for clear expectations to be set.
I think it's exactly the opposite. It knows people cannot communicate efficiently. That's why the first idea starts with "Individuals and interactions". If the assumption was that communication is efficient, then processes and tools are the best approach.
This an interesting perspective, and I think I hear what you're saying:
Agile/Scrum is a structure put in place to streamline communication and productivity bc waterfall prevented folks from having the exchanges necessary to act as a team at all moments. Does this capture it?
If so, I agree Agile serves communication and does provide that support/structure. I still stand by my original statement, albeit with a deserved footnote: while Agile/Scrum serves communication in that its very purpose is to support and streamline communication (thanks again for this), it doesn't provide (explicitly) the interpersonal tools necessary to use it.
Put another way, it's been my experience that Agile is a like a drill: a tool that can make life easier if you know how to use it. Deferring back to my original comment here: folks often are not able to speak up or be aware of others' perspectives or the situation in such a way that uses Agile well.
As my other comment in the post said. Agile is just a set of ideas. It is not a tool or process. It's basically "it does not matter how you want to work, but we think that these 4 ideas should be leading."
The agile ideas are to counter problems with waterfall, and other rigid processes. In those there is the assumption that earlier steps had perfect outcome for the follow-up steps. So the created plans, designs, and specifications (which are forms of communication) are efficient and effective. Something which time has proven rarely is the case.
Another part is that the customer might have failed to properly convey the problem. A clear failure in efficient communication. Engaging with the customer more often can result in all parties properly understanding the problem at hand.
You could say that the agile manifesto says that we suck at efficient communication. So we need to do it more.
Thanks for the feedback.
I think ideas can be tools, so I'm unable to split that hair any further. I also think there is no such thing as "no process" (even being agile in response to an obstacle is a process- just not an inflexible one), so I also can't go further down that hole today:D
What it seems like is that we both agree humans do not communicate well. You think Agile helps this. I also think Agile can help this: however...
I think Agile is often misused and misunderstood and cannot help unless the right mentality for communication is set.
You either understand Agile or you don't. I agree with the OP that teams using Agile can fail to actually be agile. Because I've seen folks repeat the phrases from their agile courses and just not have the understanding to actually implement the philosophy behind them, O understand where the OP is coming from.
But nudged with good support and open communication, I've seen Agile thrive as well. It needed the nudge though.
Read another of your comments about scrum v agile and tools. Good point.
I still think Agile is a tool (only bc ideas are tools for me), but I hear your pov. Thanks for the insights.
"As a PO and SE/Lead I enjoy knowing the tech. It requires humility and a constant questioning of which decisions are based in ego or laziness and which are customer focused, but at the end of the day, I'm able to understand my team's situation and accurately convert those situations to my clients for clear expectations to be set."
I agree with this 100%.
From my experience as a SE/Lead and PO, I think it's good to have a PO with some dev experience. Even, if only at a high-level. It's that kind of PO that will be able to see all sides clearly, which is imperative.
Also, I think it largely depends on the person leading. I understand tech but I also don't have the ego to think I know all the answers. That's not my style. If anything, I lead the discussion, ask questions and count on my team to lead with the dev solutions. I make sure that those solutions fall inline with the scope and the needs of the end customer and client. Scrum / Agile is all about open communication and the knowledge that there is a balance between roles.
10000000%
this is how I see Agile, devs are artists, or Journalists having a bunch of pencils and erasers that might rip up the papers. but, we been asked to make things in a short time, that would require Typewriters, and papers recycling.
If it is like this then your team is lucky and should deliever good quality software on time 😊 👍
From my honest pov, the silent listeners should be kept away from the meetings they are not intended to attend. Why?
1-infosec is a thing, if not
2-if that person has no active role in the meeting, then just no. Time is money
3-as you said, the team should be able to discuss design decisions without the product owner there to throw the 10 cents.
On the same note, there seems to
be a lot of small issues to take care of in your company. The fact that a developer has to wait 6h to report an issue does not seem to me like a problem in the methodology, but more like a problem in the work dynamics (unless the methodology itself it's imposed by the PO).
I also understand that these symptoms arise in medium/large companies and it can be quite tricky to overcome them. That is why, having had my own share of big companies, I still prefer the small ones :)
Just to make it clear: This is not from one single company. These are things I have seen at least 2 companies.
I worked with startups where we were 6 people to companies where the dev team alone was 50 people.
Since scrum/agile is part of "work dynamics" yes it is part of it ;)
Speaking about your points:
1) Only your own people should be in any meeting anyway
2) You don't know how much money I have seen burn in meetings in companies ;) If I would just get 10% of that money I would not have to work anymore at all
3) Yes PO's sadly tend to speak to much ;)
Write.
Read.
Relax.
Proofread.
Publish.
I didn't reach the end of the entire article - I couldn't grasp the gist of most of the sentences. Man, use some help of a spell-checker, grammarly, friend, whatever...
As far as the "silent listeners" go - I would first look into why the organizer chose to invite them. Oftentimes, wrong people are invited to meetings. Maybe those silent participants shouldn't have been invited in the first place. Maybe the invitation lacked an agenda, or maybe it was full of errors, hard to understand, you know...
Secondly, if a person keeps quiet, why not ask them openly for their opinion?
Thirdly, it is often the case that there are too many too loud people in a meeting, and it is very wise of the silent ones to remain silent and not interrupt anyone.
Scrum is not a golden remedy to all possible organizational problems. It is just like any other tool - you should only use it if it serves the purpose. Whether it is a proper tool, depends on the people, project, sometimes project phase, and probably more. At any rate, if you use a wrong tool, blame yourself/ves, not the tool.
Funny I'm writing it in Ms word and then checking grammaly 🤣🤣
Ask a friend then ;)
You are projecting. Your post is filled with grammatical errors and typos.
If Scrum is not working, and you are not changing the way you work (because that's not Scrum). The agile is not working for you either.
Scrum is a bunch of processes.
Agile is a set of ideas.
They are not synonyms. You can do Scrum and not be agile (happens more often than you think). You can be agile without doing Scrum. I feel Scrum is a hammer, and all software development activities become nails.
"wait with there" should be "wait with their" and the negation is "it doesn't work" not "it not works".
Silent people should not be in meetings? So being loud equals being productive? Strange point of view. In reality you need a good facilitator to shut up the shouters and get the views of the silent members.
I do agree that any non-team member destroys the retrospective, that's real basic. OTOH the absence of such people is no guarantee of a safe space and open discussion. It still takes a lot to get an honest feedback from a retro, especially when it comes to poor coding; the kind that everyone in the team agrees is wonderful and doesn't need any more tests.
Maybe the silent guy had a different view but he was booted.
Thanks I will change this
Sorry I don't know what to comment to the rest.
Nothing is ever guaranteed in life 🤷♀️
LoL. True. 😂
Happy new year!
"also did not even where thinking about technical details."
What's that supposed to be once it's a proper sentence?
@more_grip
Also, were not even thinking about the technical details.
OR
Also, did not even think about the technical details.
Once I have time I will correct it :)
This article has so many grammatical & spelling mistakes they make it painful to read. Even in the title. Please use a spell check next time. It's XXI century.
I'm usuing grammarly :)
Shows 0 errors
Good job. Agile is a tool for jealous co-workers to make their objects of jealousy look bad and for micromanagers to micromanage more efficiently. I used to think it was good but that was when I was an intern. It is the worst thing that has happened to software development, especially if you want diverse workers.
Thank you for sharing your thoughts! I guess many problems start at the beggining of Agile implementation, when there are some, let's say, hidden or unconscious motives to introduce it. I mean sth like kanbantool.com/kanban-library/why-... here with Kanban. I would add that being too fixed on Scrum/Agile rules may also be a problem. Thank you again for your insight from within being a team member!
I find it hilarious that your post's reactions deal more with grammar than content.
This is how it is usually on the internet 🤣🤣
Some comments may only be visible to logged-in visitors. Sign in to view all comments.