The important thing that always gets missed about this is interests. The employees of a company often have interests that conflict with each other. None of the agile methodologies have anything to say about this, much less practices that could ameliorate the conflicts. Hiring an outside coach exacerbates this. So some distant executive whose only interaction with line level employees is through all hands meetings hires some person to come in for a little bit and to tell the line level employees how they're doing everything wrong? Gee, i wonder why they don't trust the coach! Imagine if this was reversed: some programmers (or other line level employees) hire an executive coach to tell their executives what to do. Do you think the executives would be eager to listen to that coach?
Lol and to top it all off, the coach that comes in usually has zero skills in ACTUAL software development. It would be a bit different if a really good, well trusted programmer came in and sat down with teams to learn about what they were building and helped that team come up with a solid plan. We would actually trust the person and work together to on the plan. Most of us who are software engineers have spent most of our lives digging in the weeds of technical details to become half way decent at what we do and still know we have mountains to climb, just to have a spot in this industry. Then u have people like these agile gurus, who believe software development boils down to just having the right meetings, saying the right things, learning how to split stories into smaller chunks. It's insulting.
@@PoppySeed84The thing is, building anything non-trivial requires collaboration. You’re right that having programmers good at their craft, with experience to know the right solutions to a problem etc is very important. But having a bunch of great programmers and letting them focus on what they’re good at - the technical aspects of the project - is not enough. Do that and you’ll usually end up with a beautifully architected, well coded, scalable program that does meet the goals of the customer (all their goals, including their budget). There must be coordination. There must be someone fighting for the customer experience (and what they care about is nothing to do with the plan you came up with with the other great programmers, nothing to do with the technology used, nothing to do with how clever a given code block is etc). I find the programmers that fight hardest against anyone non-technical being in the process are exactly the ones that need it the most.
Given how little most companies care about employees it’s a bit of a stretch to expect me to put the project or the company above my own career. My most recent employer seemed good on the surface at first. It didn’t take long to realise that they lied constantly to try and keep staff working long hours and on the payroll. As such I only did the work that looked good on my CV and moved on. Agile is about collaboration, working together, etc. and companies need to learn to work with employees and not against them. It isn’t a zero sum game nor is it a fight to squeeze every last drop of productivity from employees. People who hate agile have probably been manipulated with lies. People who hate scrum have probably never seen any benefit in it, and that’s not hard given that scrum people like to poorly define scrum and most scrum people don’t even seem to understand it. I’d rather use almost anything other than scrum these days. That’s totally different to agile though, I like what the manifesto says and the principles behind it.
It used to be (like around 2005 - 2010) that people would try and adopt new ideas (from Scrum, lean, Kanban or wherever) without much prejudice. We were learning as we went and it felt quite positive. Some of the original writers of the texts like Highsmith and Cohen had years of real experience to bring to their texts and so it felt credible. The movement now has become so steeped in dogma and opinion, all driven by the market for training and accreditation. Now everyone is an expert and my expert is better than yours. We stopped listening to the teams around 2013 and it's been getting worse ever since!
As someone who has persisted with the Agile "thing" for about 15 years, I can see all the reasons why people get irritated by Agile dogma in this short video. Most people in corporate tech are savvy enough to know when they're being manipulated or told what to think. The skill is in not acknowledging skeptics. Instead, it's about making your skeptics feel unthreatened, so we can get on with adding value, so our skeptics don't feel the need to disrupt that. I learned early on that teams that "deliver" don't get the strong-arm-the-law foisted on them, so skeptics leave them alone. The key then is to focus on the impediments to delivery. This is the most powerful thing a scrum master or agile proponent can do. This is in Kaizen and other teachings from Japan where companies like Toyota made it their business to "destroy" Western competition through new thinking. I'm sure they had a ceremony or two, but it wasn't core to their eventual success. This is worth remembering when we start laboring over whether we have one standup or two or a pre or post-standup to mop up all the things no one was willing to discuss in the first standup, cos they know they'd be another one - so stopped showing up to the original meeting!! Enough dogma. It's about the work and fostering collaboration to get the best from those doing it - and that will never change.
@@ericscott5895 without wanting to dominate the comments here, I'm stating that if you want to change a situation and change people's perceptions of an approach, it pays not to entertain their skepticism. There will always be people who hold opposing views but success is more likely if we find things we have in common and garner their cooperation, rather than trying to actively change their minds - which often plays into their hands (especially if they hold senior office). This is true in many walks of life. It's the basis of all good negotiation and I feel this often gets overlooked when we start discussing "Agile"!
"teams that 'deliver' don't get the strong arm of the law foisted on them" Thing is, teams in most companies are dependent on each other, cogs in a greater machine. It's not really possible to measure the performance of a team in isolation in such a structure. For example, see Deming's red bead experiment. So working hard to "deliver" could be futile. In any case, a company run by people who think that the job of a manager is to identify "weak" teams and make them work harder isn't using systems thinking. They are getting much less out of their agile transformation than they could be.
I am a skeptic, but what I watched here does not address the concerns behind my skepticism. I see ideas being sold as exclusive solutions, but these problems were already solved without complicated middleware. For instance, the daily standup doesn't solve any problems that weren't already solved by posting status updates in real time to a dedicated chat channel for the team. The difference is that you have to wait to catch the next one for the day, and it's another scheduling obstacle to work around. There's so much excusing the practices when they don't work as "bad management", or "you're doing Agile wrong", but the common dysfunction seems to be that attention is depleted by all the ceremony and meetings, leaving little left over to deliver quality results. If people want reasons to gather and be social at work, that's fine, but the actual expectation is that this is all mandatory and infallible.
I have no problem with scepticism, I think it is the best rational response to everything, however... The trouble with "Agile" is that it is so poorly practiced that nearly every judgement is made on the basis of something that is the opposite of agility. For example, you mention stand-ups being replaced by status reports. Treating a stand-up as a status meeting is a common anti-pattern, it is absolutely NOT the goal of a stand-up. I say that without thinking that stand-ups are essential to agility. But if you end up merely reporting your status, you are missing the real value of the standup entirely, so how can we judge "agility" that way? I agree with you that treating "agile" as a series of ceremonies is a bad sign, it is, but at its heart agility is about being able to inspect and adapt, I don't think that you can credibly criticise that, since that is how science and engineering work, and they, pretty much by definition, work better than anything else. Just to be clear, the intent of a stand-up is to ask for help if you need it, or tell people about stuff that you did that you think may be helpful to them "I found a cool way to add new features to service X yesterday" Not - "I completed task 'Y'".
@@ContinuousDelivery - I've never understood how this is not a status report: "I'm did this, am doing that, and another thing is in the way." In order to communicate better what interpersonal involvement is needed in the context of that status, it's simply not allowed during standup, hence the followup ad-hoc meeting. Now in the ad-hoc meeting, because this information had to wait for standup and was not relayed earlier in a chat thread, the people needed to help are not available because they've already budgeted their time for the day. This same information could easily come to light sooner than waiting for a daily meeting, dare I say with more agility. As much as I'd like to feel comfort in being able to inspect and adapt these processes, the reality is that for software developers looking to earn a living, criticism or perceived criticism is received as dissent. These practices are meant to be followed, not questioned.
@@travispulley5288 Well for a start, don't say "I did this" or "I am doing that", the last one "I have a problem with this" is fine, someone may be able to help. I think a good rule of thumb is to always be offering or asking for help, or shut-up. I know that is how they are often practiced, but that is NOT how stand-ups or agile were defined. "Agility" is DEFINED as the opposite of of "practices to be followed not questioned", yet we criticise it because that is how ignorant people have chosen to mis-interpret it. We are in danger of throwing the baby out with the bath water, yet again. I HATE common "Agile" practice, but "agility" is still the right target to strive for.
@@ContinuousDelivery I am so sorry for being disagreeable here, but (from Wikipedia) the daily standup is defined* as a "brief, daily collaboration meeting in which the team review progress from the previous day, declares intentions for the current day, and highlights any obstacles encountered or anticipated." Companies pay good money for certified consultants to declare that this is the way, and they're not exactly receptive to hearing that it isn't. As a software developer wanting to make a living, the value prospect of challenging the status quo here is not good. The Manifesto for Agile Software Development doesn't even mention standup meetings. *: This definition is according to the PMBOK (7th edition) by the Project Management Institute
@@travispulley5288 Sure, I am a pragmatist not a dogmatist, I think that the fundamental definitional attribute of agility is that you change what doesn't work! So sure, Wikipedia has a definition that I'd say was wrong, though a common misinterpretation, this description used to be used widely as an example of "what not to do" for stand-ups. Surprise, training companies found that they could make money selling faux-agile training to big companies and destroyed what "agility" meant in software. But the real thing here, the real point that, to me, makes all of this about "counting angels on the head of a pin" is that agility - written into the manifesto, is that if something doesn't work for you, change it! If stand-ups aren't working, do something else! That's it, that is what "Inspect & Adapt" means. It is the opposite of dogma and ritual, and it is ultimately the ONLY THING THAT WORKS which is why science works the same way. Have an idea, try it out, keep the ideas that work and discard the ideas that don't - repeat. Everything else is noise, but we MUST NOT loose site of this core which is really why "Agile" is called "agile"! Oh, and please don't apologise, nothing disagreeable here, other than that we disagree 😉😎 I don't take that personally, talking to people that we disagree with is how we learn new things.
Most Agile coaches I've seen, fail to grasp the 'nature' of the work that teams they've been asked to guide are faced with. It's not easy being an engineer - in software or whatever. You want someone who's got your back; whether it is your investor, manager, or your spouse. Sadly, most investors' support tails off once the first years' revenue projections fall short!! I've always tried to be the manager who sees beyond that in an attempt to see how far we can go and what we can get done. I've fallen short of a few fences, but that's the nature of it. The only thing that kept us going was a tireless need to unblock "stuff" as it came up. "Stuff", like SSLs expiring on the eve of the launch. "Stuff" like your video ingester that can't transcode the 1000 movie titles you need in time for launch. "Stuff" - the shit you can't plan for!!
@@nickjcresswell I would agree with this. It seems some of the agile coaches I have run into just want to follow SAFe to the letter and that ends up frustrating people enormously. I love CI/CD, testing, KANBAN, and even the daily standups can be useful. The people we have on our team are all specialists. Usually there is only one person that can do any one item in the backlog so doing some kind of group backlog refinement is not very useful. Prioritizing tasks also tends to not be very useful since you don't do the next higher priority task instead you do the next highest priority task that you are capable of doing. We also have other teams who build things to make the highly technical team more effective. There is no real reason to plan more than a few weeks ahead at most because you don't truly know what is coming up. Instead a KANBAN approach and keeping people updated helps respond quickly. Code quality is really important because technical debt really slows down the process.
@@Immudzen I'm part of a stream-aligned team which helps the other teams with CI/CD and build engineering. We're doing Kanban with daily standups and smaller, weekly meetings, focusing on the different teams. Each of us is part of different meetings with different teams too. Essentially, we're what connects them. We obviously can't do Scrum, because the teams we're supporting aren't following the same release cycle, and issues are getting prioritized as they are brought up. So much work is never put into a formal issue anyways and can't wait to be planned for the next sprint. The other teams (apart from the system administrators who work like us) are all doing some variant of Scrum / Agile Development (with a sprinkle of long-term planning on top). I was part of one of them a year ago, and had the pleasure to work for multiple years together with a very good "Scrum Master" (I was his vacation replacement). He'd basically always have our backs, and organized the meetings with other stakeholders. We changed the process quite a bit over the years, always improving it. There's good value in that, but you need the right environment and team for it (which we needed to fight for at first). I do miss working with him (nowadays I only see him in corporate meetings). My new manager is doing this on his own, because the process is already good enough, and there's not enough work to require a separate person (we're a small team of six people, two working students, and him). We're managing hundreds of machines and many pipelines (hundreds of automated jobs) for multiple big teams, as well as their build and dev environments.
I actually like agile coaches even though I am a developer. They provide a useful service. I have accumulated quite a bit of knowledge over the years and like to quitely work on myself. Still I like to make time for helping team mates on a topic. It often gives me opportunity to discuss things from a different angle. I always try to encourage people to ask me for help. That does not always work as intended. People sometimes fear that they may ask "dumb" questions. My favorite approach is to not overload. tell people to come back for the next portion when they are ready and go then into the next loop. I also try to avoid to be or be viewed as "rock star developer".
The problem with the Ad Hoc meeting here, is that the developers are not trusted to be able to talk to each other themselves. A simple: Who can help? Ok, good, then can you two talk it over after this meeting, is quite good enough in most cases, and it is much more respectful.
I totally get it and feel the same way. Too much hand-holding can feel like not being treated as an adult to some. But with others, that is necessary to get them to communicate - sadly. I have worked with both kinds of team members and I'm working with a mix of both right now. Some people simply learned that not communication means no scolding for asking dumb questions.
We call the items in the ad hoc meeting parking lot items. Its an easy and unoffensive way of keeping standup moving. If someone has taken to much time or is going into to much detail, the coach can ask that the topic be "moved to parking lot" i ask for it all the time. The ad hoc meeting should not require attendence.
"is quite human to react negatively to change, unless is a change you have decided yourself". I do say the same. People don't want imposed change (so the objective is to make them want the change)
I dont know of any devs that dont like agile. Most devs have an aversion to business applying agile in a purely busisness way, then biz wonders why they get the same reaults as waterfall. The latest i am hearing from POs is that points are equal to value. When did this happen?
I have been a team leader for 2 years, and instead of the scrum daily meeting I used to sit on the side of the persons to have a 1to1 session with each one to understand their progress and what's blocking them if anything is. I find this much more effective.
It might be, for you personally. But it blocks everyone else from getting the knowledge too. This might be fine, if you're in a research department, where people are working on their own things, but it may not be, if you're in an actual team where people now need to talk to each other much more outside of the meeting which you prevented. And if they just don't, or are now missing important information, mistakes happen.
@@N1ghthavvk Probably that's the real problem, we think meetings are the only place we should talk to eachother while all the rest of the time we should close all our communication lines and just code. But that's furthest from the truth, i believe my job as a team leader is to give focus, help the junior improve and keep things organized so that i know and can respond to anything happening on my team, while communication between the members of the team goes on all day uniterrupted without meetings and if someone is shy and tends to "hide" i facilitate it by telling him what the others are doing and to ask him to ask them for informations on their work perhaps to solve a bug they left or to implement a new feature.
Micromanagement or no team. IMO managers should focus on people development, organization issues, and HR stuff instead of on product development. They should leave product development to experts - developers and a product manager (owner).
All those things that Agile Coach does, devs would do otherwise. Taking from the team „responsibility” for identifying organizational issues doesn’t enable them to do more of their specialization - it kills all the values companies try to establish - like taking ownership. It actually kills it because of Scrum Masters, Agile Coaches and other incompetent people not specialized neither in MBA, nor Software Development
I have worked with some really, really good software developers. They are almost always willing to share what they know with others. That is how they got so good at what they do in the first place. They shared what they know, so others shared with them, to mutual benefit. Extremely good programmers have strong social networks. Look at people like Kent Beck, Martin Fowler, and Ward Cunningham. They all know each other, have worked together, and have collaborated closely on developing their ideas. The loners are rarely that good. It is difficult to develop a very high level of skill in isolation. The loners can be extremely smart, and good problem solvers, but it is very rare that they are as good as the experts who share and help each other out. The most common reason people want to sit alone, is that they do not want others to see the mistakes they make. Unfortunately, that makes it difficult for them to improve.
In our team we have modified the meetings quite a lot. Just giving a status update does not seem very useful because gitlab already captures that. Instead we focus more on if anyone is stuck, what resources they need, that kind of stuff. Since I do science and engineering programming sometimes people have actual hard issues and having a bunch of brains to help can really cut through the issues quickly. We do CI/CD and a KANBAN style of working. I sometimes wonder if the way we have modified agile just would not work for more normal software teams.
So long as the individuals involved enjoy the collaboration, and can easily change to something better if needed, it is probably pretty ordinary for what agile is.
Totally agree. At the end of the day Agile is about iterative and incremental delivery of small batches of value. With “small” being the key. The shortcoming of Scrum is that it requires everything to fit inside of a Sprint calendar. Things can be small without perfectly aligning to the calendar dates of Sprints. That’s why the flexibility of Kanban is better. Or even striping all process away and just using Story Maps
@@timgwallis I couldn't agree more about the sillyness of "sprints" and that the pipeline model of Kanban is much better. Also... a lot of these frameworks seems to assume that all IT work fits the same model. SCRUM specifically seems to take offset in a larger group (4+ people) working on the same homogenic project and everything being about "user stories" of that project. And sure ... they all say that it's about adapting the methods to what suites the team best, but in the end (as Upton Sinclair pointed out), if that is not SCRUM, then it's going to be an uphill battle. The Agile manifesto was one of the best things happening to the IT world ... that the poster child ended up being SCRUM, one of the worst.
If the only promoter for effective communication within a team is an "Agile Framework" that needs coaches and masters 24/4 to be minimally functional, then the problem is the team itself! Scrum and "Agile Frameworks" alike are not the answer, never will!
It is because most of the Agile/Scrum coaches come from a point of arrogance. They have to "teach" us how to be agile, they have all the answers, they know better... Agile is not a science. Just give a work to a group of developers who sit in the same room and they will start working in an agile way. There is no need for "guidance" or teaching us something. Second thing is, most of them never worked as developers and they just preach theory and implement processes. Can I as a developer come to a hospital and organize doctors work or help them be more productive? Of course not...I am not a doctor with years of experience myself. People need to understand that if you wont to work in tech, you have to have a hands on experience in the field. Period (I am not talking about upper management)
But the culture of "asking for help" is terrible. No one should ask for help on the first encounter of a problem without even giving it a try. This creates a dysfunctional organization with tons of helpless people. Also, sometimes describing the problem and writing it down helps you solve it. But in the daily meeting, no one would do that because they'll just share the screen and point at the problem which would skip the "writing it down" part.
It is always a balance. You shouldn't ask for help for every tiny problem that you could have solved yourself with a bit of thinking and research. But you also must not go through days of struggling. Also, it is very important that people feel safe to ask for help if they need it. When they do, never make them feel bad about it. Help them, but also show them, how they can help themselves.
“instead of leaving them [novice developers] alone to fuck things up, you can have a very short chat every day to make sure they’re on the right path” Yikes! Not only is this language unprofessional, the core message is problematic. Instead of agile being used to foster a culture of growth, what we see here is framing that senior developers are a problem and agile can correct bad behavior through micromanagement. What we need to see are transformative ways of integrating parties to work towards a goal and what we’re seeing are rehashes of management approaches from the gilded age.
I swear listening to this people makes me understand why big companies are all holding hands in the agile hell, not doing much but feeling agile. Also I really wonder if these agile coaches and agile experts are really just demented rejects from psychology.
@@anonforever123 functional teams and people do all these things intuitively and naturally to make their work effective. They don't need to pay scammers for a pretense of work
@michaeldesanta749 A lot of training companies sell agile as a "product," which comes off as a scam and re-interprets agile as nouns rather than an adjective/mindset for a team.
Love this lady. Even if she is an Agile coach.
good one!
Says more about you than her.😂
@@taz_brown It's a joke. Riffing off her own jokes about engineers are often anti-agile and anti agile coach.
The important thing that always gets missed about this is interests. The employees of a company often have interests that conflict with each other. None of the agile methodologies have anything to say about this, much less practices that could ameliorate the conflicts. Hiring an outside coach exacerbates this. So some distant executive whose only interaction with line level employees is through all hands meetings hires some person to come in for a little bit and to tell the line level employees how they're doing everything wrong? Gee, i wonder why they don't trust the coach!
Imagine if this was reversed: some programmers (or other line level employees) hire an executive coach to tell their executives what to do. Do you think the executives would be eager to listen to that coach?
Lol and to top it all off, the coach that comes in usually has zero skills in ACTUAL software development. It would be a bit different if a really good, well trusted programmer came in and sat down with teams to learn about what they were building and helped that team come up with a solid plan. We would actually trust the person and work together to on the plan. Most of us who are software engineers have spent most of our lives digging in the weeds of technical details to become half way decent at what we do and still know we have mountains to climb, just to have a spot in this industry. Then u have people like these agile gurus, who believe software development boils down to just having the right meetings, saying the right things, learning how to split stories into smaller chunks. It's insulting.
@@PoppySeed84The thing is, building anything non-trivial requires collaboration. You’re right that having programmers good at their craft, with experience to know the right solutions to a problem etc is very important. But having a bunch of great programmers and letting them focus on what they’re good at - the technical aspects of the project - is not enough. Do that and you’ll usually end up with a beautifully architected, well coded, scalable program that does meet the goals of the customer (all their goals, including their budget). There must be coordination. There must be someone fighting for the customer experience (and what they care about is nothing to do with the plan you came up with with the other great programmers, nothing to do with the technology used, nothing to do with how clever a given code block is etc). I find the programmers that fight hardest against anyone non-technical being in the process are exactly the ones that need it the most.
Given how little most companies care about employees it’s a bit of a stretch to expect me to put the project or the company above my own career. My most recent employer seemed good on the surface at first. It didn’t take long to realise that they lied constantly to try and keep staff working long hours and on the payroll. As such I only did the work that looked good on my CV and moved on. Agile is about collaboration, working together, etc. and companies need to learn to work with employees and not against them. It isn’t a zero sum game nor is it a fight to squeeze every last drop of productivity from employees. People who hate agile have probably been manipulated with lies. People who hate scrum have probably never seen any benefit in it, and that’s not hard given that scrum people like to poorly define scrum and most scrum people don’t even seem to understand it. I’d rather use almost anything other than scrum these days. That’s totally different to agile though, I like what the manifesto says and the principles behind it.
It used to be (like around 2005 - 2010) that people would try and adopt new ideas (from Scrum, lean, Kanban or wherever) without much prejudice. We were learning as we went and it felt quite positive. Some of the original writers of the texts like Highsmith and Cohen had years of real experience to bring to their texts and so it felt credible. The movement now has become so steeped in dogma and opinion, all driven by the market for training and accreditation. Now everyone is an expert and my expert is better than yours. We stopped listening to the teams around 2013 and it's been getting worse ever since!
As someone who has persisted with the Agile "thing" for about 15 years, I can see all the reasons why people get irritated by Agile dogma in this short video. Most people in corporate tech are savvy enough to know when they're being manipulated or told what to think. The skill is in not acknowledging skeptics. Instead, it's about making your skeptics feel unthreatened, so we can get on with adding value, so our skeptics don't feel the need to disrupt that. I learned early on that teams that "deliver" don't get the strong-arm-the-law foisted on them, so skeptics leave them alone. The key then is to focus on the impediments to delivery. This is the most powerful thing a scrum master or agile proponent can do. This is in Kaizen and other teachings from Japan where companies like Toyota made it their business to "destroy" Western competition through new thinking. I'm sure they had a ceremony or two, but it wasn't core to their eventual success. This is worth remembering when we start laboring over whether we have one standup or two or a pre or post-standup to mop up all the things no one was willing to discuss in the first standup, cos they know they'd be another one - so stopped showing up to the original meeting!! Enough dogma. It's about the work and fostering collaboration to get the best from those doing it - and that will never change.
Can you expand om this, please. Very interesting view, thank you 🙏
@@ericscott5895 without wanting to dominate the comments here, I'm stating that if you want to change a situation and change people's perceptions of an approach, it pays not to entertain their skepticism. There will always be people who hold opposing views but success is more likely if we find things we have in common and garner their cooperation, rather than trying to actively change their minds - which often plays into their hands (especially if they hold senior office). This is true in many walks of life. It's the basis of all good negotiation and I feel this often gets overlooked when we start discussing "Agile"!
"teams that 'deliver' don't get the strong arm of the law foisted on them" Thing is, teams in most companies are dependent on each other, cogs in a greater machine. It's not really possible to measure the performance of a team in isolation in such a structure. For example, see Deming's red bead experiment. So working hard to "deliver" could be futile.
In any case, a company run by people who think that the job of a manager is to identify "weak" teams and make them work harder isn't using systems thinking. They are getting much less out of their agile transformation than they could be.
I am a skeptic, but what I watched here does not address the concerns behind my skepticism. I see ideas being sold as exclusive solutions, but these problems were already solved without complicated middleware.
For instance, the daily standup doesn't solve any problems that weren't already solved by posting status updates in real time to a dedicated chat channel for the team. The difference is that you have to wait to catch the next one for the day, and it's another scheduling obstacle to work around.
There's so much excusing the practices when they don't work as "bad management", or "you're doing Agile wrong", but the common dysfunction seems to be that attention is depleted by all the ceremony and meetings, leaving little left over to deliver quality results.
If people want reasons to gather and be social at work, that's fine, but the actual expectation is that this is all mandatory and infallible.
I have no problem with scepticism, I think it is the best rational response to everything, however...
The trouble with "Agile" is that it is so poorly practiced that nearly every judgement is made on the basis of something that is the opposite of agility. For example, you mention stand-ups being replaced by status reports. Treating a stand-up as a status meeting is a common anti-pattern, it is absolutely NOT the goal of a stand-up. I say that without thinking that stand-ups are essential to agility. But if you end up merely reporting your status, you are missing the real value of the standup entirely, so how can we judge "agility" that way?
I agree with you that treating "agile" as a series of ceremonies is a bad sign, it is, but at its heart agility is about being able to inspect and adapt, I don't think that you can credibly criticise that, since that is how science and engineering work, and they, pretty much by definition, work better than anything else.
Just to be clear, the intent of a stand-up is to ask for help if you need it, or tell people about stuff that you did that you think may be helpful to them "I found a cool way to add new features to service X yesterday" Not - "I completed task 'Y'".
@@ContinuousDelivery - I've never understood how this is not a status report: "I'm did this, am doing that, and another thing is in the way."
In order to communicate better what interpersonal involvement is needed in the context of that status, it's simply not allowed during standup, hence the followup ad-hoc meeting.
Now in the ad-hoc meeting, because this information had to wait for standup and was not relayed earlier in a chat thread, the people needed to help are not available because they've already budgeted their time for the day.
This same information could easily come to light sooner than waiting for a daily meeting, dare I say with more agility.
As much as I'd like to feel comfort in being able to inspect and adapt these processes, the reality is that for software developers looking to earn a living, criticism or perceived criticism is received as dissent. These practices are meant to be followed, not questioned.
@@travispulley5288 Well for a start, don't say "I did this" or "I am doing that", the last one "I have a problem with this" is fine, someone may be able to help. I think a good rule of thumb is to always be offering or asking for help, or shut-up.
I know that is how they are often practiced, but that is NOT how stand-ups or agile were defined. "Agility" is DEFINED as the opposite of of "practices to be followed not questioned", yet we criticise it because that is how ignorant people have chosen to mis-interpret it. We are in danger of throwing the baby out with the bath water, yet again.
I HATE common "Agile" practice, but "agility" is still the right target to strive for.
@@ContinuousDelivery I am so sorry for being disagreeable here, but (from Wikipedia) the daily standup is defined* as a "brief, daily collaboration meeting in which the team review progress from the previous day, declares intentions for the current day, and highlights any obstacles encountered or anticipated."
Companies pay good money for certified consultants to declare that this is the way, and they're not exactly receptive to hearing that it isn't. As a software developer wanting to make a living, the value prospect of challenging the status quo here is not good.
The Manifesto for Agile Software Development doesn't even mention standup meetings.
*: This definition is according to the PMBOK (7th edition) by the Project Management Institute
@@travispulley5288 Sure, I am a pragmatist not a dogmatist, I think that the fundamental definitional attribute of agility is that you change what doesn't work! So sure, Wikipedia has a definition that I'd say was wrong, though a common misinterpretation, this description used to be used widely as an example of "what not to do" for stand-ups.
Surprise, training companies found that they could make money selling faux-agile training to big companies and destroyed what "agility" meant in software. But the real thing here, the real point that, to me, makes all of this about "counting angels on the head of a pin" is that agility - written into the manifesto, is that if something doesn't work for you, change it! If stand-ups aren't working, do something else! That's it, that is what "Inspect & Adapt" means. It is the opposite of dogma and ritual, and it is ultimately the ONLY THING THAT WORKS which is why science works the same way. Have an idea, try it out, keep the ideas that work and discard the ideas that don't - repeat.
Everything else is noise, but we MUST NOT loose site of this core which is really why "Agile" is called "agile"!
Oh, and please don't apologise, nothing disagreeable here, other than that we disagree 😉😎 I don't take that personally, talking to people that we disagree with is how we learn new things.
But wait! Isn't the Agile Coach just there to get paid and be a Yes-man to management, giving therapeutic talks to devs?
ua-cam.com/video/bB340S0tGf8/v-deo.html
ua-cam.com/video/A-H-xZ5ZXgo/v-deo.html
Most Agile coaches I've seen, fail to grasp the 'nature' of the work that teams they've been asked to guide are faced with. It's not easy being an engineer - in software or whatever. You want someone who's got your back; whether it is your investor, manager, or your spouse. Sadly, most investors' support tails off once the first years' revenue projections fall short!! I've always tried to be the manager who sees beyond that in an attempt to see how far we can go and what we can get done. I've fallen short of a few fences, but that's the nature of it. The only thing that kept us going was a tireless need to unblock "stuff" as it came up. "Stuff", like SSLs expiring on the eve of the launch. "Stuff" like your video ingester that can't transcode the 1000 movie titles you need in time for launch. "Stuff" - the shit you can't plan for!!
@@nickjcresswell I would agree with this. It seems some of the agile coaches I have run into just want to follow SAFe to the letter and that ends up frustrating people enormously. I love CI/CD, testing, KANBAN, and even the daily standups can be useful. The people we have on our team are all specialists. Usually there is only one person that can do any one item in the backlog so doing some kind of group backlog refinement is not very useful. Prioritizing tasks also tends to not be very useful since you don't do the next higher priority task instead you do the next highest priority task that you are capable of doing.
We also have other teams who build things to make the highly technical team more effective. There is no real reason to plan more than a few weeks ahead at most because you don't truly know what is coming up. Instead a KANBAN approach and keeping people updated helps respond quickly. Code quality is really important because technical debt really slows down the process.
@@Immudzen I'm part of a stream-aligned team which helps the other teams with CI/CD and build engineering. We're doing Kanban with daily standups and smaller, weekly meetings, focusing on the different teams. Each of us is part of different meetings with different teams too. Essentially, we're what connects them.
We obviously can't do Scrum, because the teams we're supporting aren't following the same release cycle, and issues are getting prioritized as they are brought up. So much work is never put into a formal issue anyways and can't wait to be planned for the next sprint.
The other teams (apart from the system administrators who work like us) are all doing some variant of Scrum / Agile Development (with a sprinkle of long-term planning on top).
I was part of one of them a year ago, and had the pleasure to work for multiple years together with a very good "Scrum Master" (I was his vacation replacement). He'd basically always have our backs, and organized the meetings with other stakeholders. We changed the process quite a bit over the years, always improving it.
There's good value in that, but you need the right environment and team for it (which we needed to fight for at first). I do miss working with him (nowadays I only see him in corporate meetings).
My new manager is doing this on his own, because the process is already good enough, and there's not enough work to require a separate person (we're a small team of six people, two working students, and him). We're managing hundreds of machines and many pipelines (hundreds of automated jobs) for multiple big teams, as well as their build and dev environments.
@@nickjcresswell this is what every manager says about themselves.
I actually like agile coaches even though I am a developer. They provide a useful service. I have accumulated quite a bit of knowledge over the years and like to quitely work on myself. Still I like to make time for helping team mates on a topic. It often gives me opportunity to discuss things from a different angle. I always try to encourage people to ask me for help. That does not always work as intended. People sometimes fear that they may ask "dumb" questions. My favorite approach is to not overload. tell people to come back for the next portion when they are ready and go then into the next loop.
I also try to avoid to be or be viewed as "rock star developer".
The problem with the Ad Hoc meeting here, is that the developers are not trusted to be able to talk to each other themselves.
A simple: Who can help? Ok, good, then can you two talk it over after this meeting, is quite good enough in most cases, and it is much more respectful.
I totally get it and feel the same way. Too much hand-holding can feel like not being treated as an adult to some. But with others, that is necessary to get them to communicate - sadly. I have worked with both kinds of team members and I'm working with a mix of both right now. Some people simply learned that not communication means no scolding for asking dumb questions.
We call the items in the ad hoc meeting parking lot items. Its an easy and unoffensive way of keeping standup moving. If someone has taken to much time or is going into to much detail, the coach can ask that the topic be "moved to parking lot" i ask for it all the time. The ad hoc meeting should not require attendence.
"is quite human to react negatively to change, unless is a change you have decided yourself". I do say the same. People don't want imposed change (so the objective is to make them want the change)
I dont know of any devs that dont like agile. Most devs have an aversion to business applying agile in a purely busisness way, then biz wonders why they get the same reaults as waterfall. The latest i am hearing from POs is that points are equal to value. When did this happen?
I have been a team leader for 2 years, and instead of the scrum daily meeting I used to sit on the side of the persons to have a 1to1 session with each one to understand their progress and what's blocking them if anything is. I find this much more effective.
It might be, for you personally. But it blocks everyone else from getting the knowledge too.
This might be fine, if you're in a research department, where people are working on their own things, but it may not be, if you're in an actual team where people now need to talk to each other much more outside of the meeting which you prevented. And if they just don't, or are now missing important information, mistakes happen.
@@N1ghthavvk Probably that's the real problem, we think meetings are the only place we should talk to eachother while all the rest of the time we should close all our communication lines and just code. But that's furthest from the truth, i believe my job as a team leader is to give focus, help the junior improve and keep things organized so that i know and can respond to anything happening on my team, while communication between the members of the team goes on all day uniterrupted without meetings and if someone is shy and tends to "hide" i facilitate it by telling him what the others are doing and to ask him to ask them for informations on their work perhaps to solve a bug they left or to implement a new feature.
Sounds like micromanagement to me.
@@madmanX1314 what part
Micromanagement or no team. IMO managers should focus on people development, organization issues, and HR stuff instead of on product development. They should leave product development to experts - developers and a product manager (owner).
All those things that Agile Coach does, devs would do otherwise. Taking from the team „responsibility” for identifying organizational issues doesn’t enable them to do more of their specialization - it kills all the values companies try to establish - like taking ownership. It actually kills it because of Scrum Masters, Agile Coaches and other incompetent people not specialized neither in MBA, nor Software Development
Wow this is actually really good stuff
I have worked with some really, really good software developers. They are almost always willing to share what they know with others. That is how they got so good at what they do in the first place. They shared what they know, so others shared with them, to mutual benefit. Extremely good programmers have strong social networks. Look at people like Kent Beck, Martin Fowler, and Ward Cunningham. They all know each other, have worked together, and have collaborated closely on developing their ideas.
The loners are rarely that good. It is difficult to develop a very high level of skill in isolation. The loners can be extremely smart, and good problem solvers, but it is very rare that they are as good as the experts who share and help each other out.
The most common reason people want to sit alone, is that they do not want others to see the mistakes they make. Unfortunately, that makes it difficult for them to improve.
In our team we have modified the meetings quite a lot. Just giving a status update does not seem very useful because gitlab already captures that. Instead we focus more on if anyone is stuck, what resources they need, that kind of stuff. Since I do science and engineering programming sometimes people have actual hard issues and having a bunch of brains to help can really cut through the issues quickly.
We do CI/CD and a KANBAN style of working. I sometimes wonder if the way we have modified agile just would not work for more normal software teams.
So long as the individuals involved enjoy the collaboration, and can easily change to something better if needed, it is probably pretty ordinary for what agile is.
The thing is... You can like Agile, but not trust SCRUM.
Totally agree. At the end of the day Agile is about iterative and incremental delivery of small batches of value. With “small” being the key. The shortcoming of Scrum is that it requires everything to fit inside of a Sprint calendar. Things can be small without perfectly aligning to the calendar dates of Sprints. That’s why the flexibility of Kanban is better. Or even striping all process away and just using Story Maps
@@timgwallis I couldn't agree more about the sillyness of "sprints" and that the pipeline model of Kanban is much better.
Also... a lot of these frameworks seems to assume that all IT work fits the same model. SCRUM specifically seems to take offset in a larger group (4+ people) working on the same homogenic project and everything being about "user stories" of that project.
And sure ... they all say that it's about adapting the methods to what suites the team best, but in the end (as Upton Sinclair pointed out), if that is not SCRUM, then it's going to be an uphill battle.
The Agile manifesto was one of the best things happening to the IT world ... that the poster child ended up being SCRUM, one of the worst.
If the only promoter for effective communication within a team is an "Agile Framework" that needs coaches and masters 24/4 to be minimally functional, then the problem is the team itself!
Scrum and "Agile Frameworks" alike are not the answer, never will!
It is because most of the Agile/Scrum coaches come from a point of arrogance. They have to "teach" us how to be agile, they have all the answers, they know better... Agile is not a science. Just give a work to a group of developers who sit in the same room and they will start working in an agile way. There is no need for "guidance" or teaching us something. Second thing is, most of them never worked as developers and they just preach theory and implement processes. Can I as a developer come to a hospital and organize doctors work or help them be more productive? Of course not...I am not a doctor with years of experience myself. People need to understand that if you wont to work in tech, you have to have a hands on experience in the field. Period (I am not talking about upper management)
the windows bashing was hilarious :) it is mind boggling how this is still a thing in 2023
But the culture of "asking for help" is terrible. No one should ask for help on the first encounter of a problem without even giving it a try. This creates a dysfunctional organization with tons of helpless people. Also, sometimes describing the problem and writing it down helps you solve it. But in the daily meeting, no one would do that because they'll just share the screen and point at the problem which would skip the "writing it down" part.
It is always a balance. You shouldn't ask for help for every tiny problem that you could have solved yourself with a bit of thinking and research. But you also must not go through days of struggling. Also, it is very important that people feel safe to ask for help if they need it. When they do, never make them feel bad about it. Help them, but also show them, how they can help themselves.
Great video as always
“instead of leaving them [novice developers] alone to fuck things up, you can have a very short chat every day to make sure they’re on the right path”
Yikes! Not only is this language unprofessional, the core message is problematic. Instead of agile being used to foster a culture of growth, what we see here is framing that senior developers are a problem and agile can correct bad behavior through micromanagement.
What we need to see are transformative ways of integrating parties to work towards a goal and what we’re seeing are rehashes of management approaches from the gilded age.
worst is to have to work with so called "rockstar devs" really
I swear listening to this people makes me understand why big companies are all holding hands in the agile hell, not doing much but feeling agile.
Also I really wonder if these agile coaches and agile experts are really just demented rejects from psychology.
Or more accurately. A day in the life of a scammer.
@@anonforever123 agile coaching is a rort.
@@anonforever123 This is a person who doesn't like systemic change in a development team :)
@@anonforever123 functional teams and people do all these things intuitively and naturally to make their work effective. They don't need to pay scammers for a pretense of work
@michaeldesanta749 A lot of training companies sell agile as a "product," which comes off as a scam and re-interprets agile as nouns rather than an adjective/mindset for a team.