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 S...
For further actions, you may consider blocking this person and/or reporting abuse
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 🤣🤣
Fun is always good :)
And thank you!
Have a great day/week/month :)
This is all very true. I have noticed quiet retros tend to correlate to bad teams.
Yes quite retros are not good retros and should be a point on that next time we do it better list ;)
Yes it is immature :D
Thank you very much :)
100% agree, you got some great points there!
Some good perceptions here. But check your grammar. "Where" vs "were"?