War is Peace, Freedom is Slavery, Ignorance is Strength, Scrum is Agile • Allen Holub • GOTO 2020
Vložit
- čas přidán 7. 06. 2024
- This presentation was recorded at GOTOpia Europe 2020. #GOTOcon #GOTOpia
gotopia.eu
Allen Holub - Allen will challenge (and change) your opinion on agile - if it exists at all
ABSTRACT
A few years ago, the death of agile was a meme. Agile was (and is still) being supplanted by #DarkAgile, agile in name only, with few of the benefits of the real thing. In a way, things have gotten worse. Agile has arisen as a zombie, eating the brains of the corporate world. "Dark Agile" flies in the face of basic principles and does active damage.
Allen Holub will pinpoint where we've gone wrong and how to make it right. There is a way out!
All is not lost, though. There are organizations, some quite large, that are “doing it right” and reaping [...]
TIMECODES
00:00 Intro
03:40 War is peace
10:54 Ignorance is strength
18:57 Freedom is slavery
28:09 Scrum is agile
38:25 What is "agile"?
Read the full abstract here:
gotopia.eu/2020/sessions/1466
/ gotocon
/ goto-
/ gotoconferences
#Agile #Scrum #AgileDevelopment #DarkAgile #DarkScrum
Looking for a unique learning experience?
Attend the next GOTO conference near you! Get your ticket at gotocon.com
SUBSCRIBE TO OUR CHANNEL - new videos posted almost daily.
czcams.com/users/GotoConf... - Věda a technologie
My opinion: SAFe, scrum, etc… anything that provides “certifications” is a business and employee management process, not a software engineering practice. I think it’s time for us Software Engineers to start being very clear to our manage that there is a difference and what the difference actually means.
I've been clear about that for several years, especially regarding SAFe, and boy does it piss people off. It's a very very sore spot for alot of people, even to this day when multiple SAFe initiatives have failed.
spot on! I keep telling business and management guys that their Scrum is not actually a process, it is just a wrapper. The real engineering process has nothing to do with Scrum, but still needs to follow agile principles. XP seems to be alot closer to what an engineering process should look like
@@FudgeYeahLinusLAN I almost made my iteration manager cry once 🥶🥶
What about Oxford or Stanford University, mate?
My current job is agile coach, and teams come to me asking what they should do. I say: there are two separate topics here (1) deliver working software and (2) the blueprint. Regarding (1) run your tests a lot, get work all the way to done, read the xp book and keep talking about how to do better. Regarding (2) we will have this set of meetings and artifacts. Don't worry about the bs. If you can use the things in 2 to do 1 then please do, it keeps the management off your back.
I've been doing this gig for about 30 years now. You're spot on. Every agile mistake you mention I've seen and worked with. For ~10 years I was on a very small team that didn't claim we were agile but we were hitting all the important bits. And we did have freedom to pick how we worked, what we worked on, when we released, and if we had felt sprints were of value (we didn't) we could have set the when's and how's of that as well. Then management changed, we became "agile" and all the mistakes started showing up. So I left. And a fair number of other folk did as well. I'm now at a place that isn't perfect, but I'm largely self directed. I pick what I want to work on, how/when I release, etc... So there are good companies out there that get it. But you've got to be ready to jump because nothing lasts forever.
I joined a major car maker last year to lead their Agile practice in a large "Agile" transformation. I can tell you how painful it is that most senior managers did their PO and SM 2day training before I joined, as they were sure they got it and knew better. They never joined any training session on what agility means, and kept declaring success for hundreds of teams "moved to Agile", meaning Scrum, while getting so few benefits from it as the org did not understand what makes it work and so what to do differently beyond renaming roles and getting people "do Scrum". At the end I did fail to get them to see the light (tough when people don't even want to take time to talk - they already know-), and was thanked out for not bending. I can tell you this big company is having most of the costs of a large transformation, but not as many benefits as to compete against Tesla or the new Chinese EV players. Gonna be bloody and I expect lots of job cuts before end of current decade; but those senior managers will certainly manage their way and sell their incredible transformation experience to do the same sh*t somewhere else after. I feel bad for all the teams who did get it and really wanted meaningful change.
@@arnaudviguie Can't teach an old dog new tricks.
@@arnaudviguie It's not impossible for large organisations to become more agile - Toyota is the poster child for that. But it requires visionary and courageous leadership, rather than a group of bureaucrats covering their tails.
@@tullochgorum6323 I never said it is impossible, I said it is difficult when top managers that have worked in the org for 20 years are sent to a two days Scrum training and then think they get it and can do it all, taking the lead on the transformation while having in reality no clue about what it takes to change an org that have 30000+ people in it, as they think and say it s about "moving people to Agile", meaning putting everyone on a scrum team and this is it. Obviously it is not as simple, as Allen explains here. And I m not sure Toyota is a poster child, they re having serious troubles nowadays. They might be a poster child of "doing Agile" but not being agile, looking at the troubles they have on their first generation of EVs.
I feel organisations today so often miss that agile isn't a process, a set of events or a plan you execute to reap the sweet benefits. It's a mindset, a culture, a way of facing and dealing with change, of solving problems. Scrum, Kanban, LeSS, Nexus and so on and so forth can be used to further that... but none of them are agile. It's the people who are agile.
You can have every single event prescribed in the Scrum Guide and not be the slightest bit agile in your organisation. On the flip side you can also be agile and be doing none of them.
That's the definition of religion. Just give your god a name and build a shrine/temple/church. Require weekly sacrifices. :-)
Thank you. It was just like a breath of fresh air.
Truth is born in dispute. Definitely like it. Thank you. Great discussion and we need more conversation like this.
As a self-funded entrepreneur, here is my process I'm zeroing in on:
1. The company is fully remote
2. Work is done by 2-person teams (typically a front end developer and a back end developer)
3. The 2 people must be located in the same timezone, +/- 1 hour
4. The 2 people must speak the same native language
5. I represent the voice-of-the-customer. I write well-defined user stories and groom the backlog in priority order.
7. We actually write documentation, store it in a well-organized portal, and use it as a key piece of our communication and development strategy. Aghast!!! No, it's not big-design-up-front. We design as we go, while looking forward into the future up to the planning horizon. I write most of the documents.
8. We use an online tool to managing our backlog.
9. I have a daily standup with each 2-person team individually. We discuss substantive issues regarding the work in progress.
10. We generally follow a Kanban process to minimize work-in-progress. We don't use sprints.
11. We don't use PRs. Anyone can commit to master at any time.
12. We refactor the code continuously to keep it clean. The goal is to make coding something akin to snapping Lego pieces together.
13. Before starting on the project, I used User Story Mapping to lay out the general design of the project and I conducted informal interviews with friends to get feedback on my ideas. Our decisions are driven by my vision and intuition. We do not yet have any customers and therefore cannot do silly things like conduct experiments or analyze data from A-B tests.
Being self funded has an uncanny ability of zeroing in on just the things that add value. From my experience, having a clear high-level direction on what is needed (point 5) is critical to driving any Agile process to success. If you can't get that right then Agile won't help you. Well done, I like your process.
I'dd also add: each developer can appropriate the code/micro-architecture and produce clear simple manageable, autonomous (if possible) pieces of work. Not forcing TDD. Developer can do marvels when you allow them to use their full creativity - taking more time to have fun coding than trying to fit/pastiche into the often wrong canvas. The key been that an average developer shoud be able to understand the software quickly - using a quick hand-on one pager document. Code review would level up the final result.
Looks amazing…
Since a lot of organizations now know that "project manager" is a bad word in Agile, they have renamed them "program managers".
"Product owners"
“Initiative Leads”
if only we could subscribe for comment replies... 😅
Programme managers have been around since ages tbh
On point! The problem in my opinion... companies buy training where they need coaching... and most of the problem is leadership behaviour
finally someone who can clearly articulate what I think about this whole agile mess
Thank you for the brilliant speech!
Thank you! Finnaly, someone articulated it much better than I ever could to a "decsion makers" whom pride themself for follwing this instanty for so long.
Amazing, thank you.
"Scrum was invented so that non-science people can find job in software development."
I don't know who originally said that but it is so true.
Dealing with a middleman micromanager that has no real idea how complex any of the engineering work certainly is frustrating. Especially when they're paid as if they were a principal level developer.
It's not at all why it was invented, but it eventually got corrupted by the alliance looking for ways to extend its appeal. When you're a consultant, it's great if idiots try to do the stuff and fail, that's a repeat customer. If you're a team member with a broken SM then scrum is just a regular opportunity for people to talk you out of building quality.
Excellent video!
You are truly an inspiration.
Just not convinced that even the term "agile" can convey anything useful about how to work. All these processes seem to disavow that we're doing technical knowledge work.
Give people their current priorities, manage the order of priorities and let them work on it.
Spend the remaining resources on mentorship.
Done. You just built a world class team.
Thanks!
Thank you very much, Cristian, this is much appreciated! ⭐️
I like your marker board. Is that glass or plexiglas? What thickness, which clamps, etc? Looks like B&H might like more of my money.
Nice, thanks
are there slides for this talk?
And this criticism fails in a lot of ways.
There are only two criticisms of the Scrum in the whole talk - is that Scrum defines a roles besides "the team" and that it has some meetings baked in.
The rest of the talk is the criticism of:
Jeff Sutherland. Yeah, why not. I don't particularly like this person either.
Scrum coaches. When we are talking about a field that vast, there are good apples and bad apples. Trying to generalize it in the way that he did is just nonsense, though the general sentiment is correct; as there are a lot of people who don't understand how scrum should work, and how agile should work.
SAFe. Self explanatory. SAFe is not scrum.
Let's start with a definition. Scrum does not claim that it "is" agile. Neither Scrum Guide from Ken Schwaber nor Scrum Primer from AgileAlliance claims so. Scrum, however, maps all of the principles of Agile within it's framework; as you will find ALL principles within the Scrum Guide.
Allen claims time after time that Scrum is a process - which is not. Scrum is a framework in which you can create your own process, your own way of work. What is worth mentioning; he has repeated several times that the Scrum without XP does not work 'because scrum was a wrapper for XP'. This is really ignoring the past two decades of proven teams working with Scrum - XP is not the only way of work, and scrum does not tell you how you should work.
Another issue altogether is this frankly stupid notion that Scrum disallows inspection and adaptation during the sprint. To quote: "The adjustment must be made as soon as possible to minimize further deviation."... And not "at the end of the sprint".
But the first moment that I've started to bang my head off the wall was his critique of the immutability of Scrum. He does not understand this sentence at all. No one is telling you (maybe aside from Sutherland, but to paraphrase - Scrum is not Sutherland, Sutherland is not Scrum) that Scrum is THE ONLY methodology. It's only telling you - follow it, you'll see results. You wish to make changes? Go ahead, but it's not Scrum. See the difference? There is no "It's not Agile". Only "It's not scrum". So when the authors tell you that "if it not fits you, then change it"... It's not agile and bad? Come on...!
The idea of asking users for a feedback is a cute one; or rather his assumption that "every company" can do so, on a daily basis, several times a day. If you can, you are blessed. If not, Scrum offers a solution - schedule it at least once every sprint. It doesn't say "You can't do it more often". But who am I, just the person who actually read the scrum guide ¯\_(ツ)_/¯
Oh, and the releases as well! Scrum does not allow frequent releases... Again, a direct quote: "Multiple Increments may be created within a Sprint. The sum of the Increments is presented at the Sprint Review thus supporting empiricism. However, an Increment may be delivered to stakeholders prior to the end of the Sprint. The Sprint Review should never be considered a gate to releasing value."
What really made me chuckle though is his attempt at rebuttal of the "real world". Problem is, he is living in a bubble. Why am I claiming so? Because I've worked with organizations that had brilliant engineers, and organizations that had people that were not really interested besides 9-5. As an agile consultant, he is called in to the specific workplaces that have already noticed a problem, and are willing to change; and I am NOT talking about the management - but developers. His dismissal of this argument is really telling - "Your experiences are worth less than mine, I know the real truth about how it works!" Kinda preachy, you know?
As for the meetings and roles... This is coming from a general lack of understanding from his part. Throughout the whole talk he really, really shows his attitude towards the methodology, not trying to understand it. I'll center my answer on a self-managed teams. "The teams decide what they should do next". Should I understand, that they have business knowledge & expertise to perform a proper market research? Understand the consequences of their choice? Because frankly, out of hundreds if not thousands of developers I've met during my career, there was NOT A SINGLE ONE that was interested in that. If he was, he moved to being a PO for a very simple reason - it's a full time job. Same thing with the middle managers. He is trying to attack middle management by focusing on the bad - but the industry recognized the EM as the role of servant-leadership. A person who has both the expertise and the understanding that are on a different level of abstraction than developers.
That brings my argument full circle. Is Scrum a one-size-fits-all? Not really*. But I always challenge any critic of Scrum to remove a part of it while keeping the idea intact. You can't remove PO. Not that this role cannot be substituted, but because programmers lack expertise. You can't remove SM, at least not from the framework itself. Teams that are capable of being agile don't need SM and that's perfectly fine. I've met one team that was mature enough. Aside from that, people don't know where to seek improvements, don't care, or have a severe lack of necessary skills. So maybe let's attack any particular meeting? Let's remove Retro... So how you ensure that ANY kind of retrospective is being held? Maybe planning? That surely goes well. Daily? Yeah, why bother talking o each other? ** This is the real world that Allen is so desperate to ignore.**
You can argue the time boxes, the frequency - but you cannot remove any part without creating many more problems in exchange.
* A good example is maintenance - you can't plan for the unknown. Kanban and similar works best here.
Wonderful reaction. I feel that most people criticizing scrum are definition warriors and believe in perfect worlds. Self organizing teams with developers who know everything, are interested in everything and just get a bag of money to do as they see fit. I feel that the rare developers who are this complete, are the kind of people who create startups. The vast majority of developers i know are good at development, not at dealing with all the complexity in the context of a company.
I don't have the solution for the best method in software development, but I've also never heard one from scrum critics. I think we should have more open conversations within the companies about goals and principles. One principle: added value > cost. Another principle: work is done in a sustainable way with a level of autonomy and work satisfaction. Talk about how to marry these principles.
Thanks for this comment. You exposed most if not all of my thoughts and I'm not even a "scrum" geek nor have I read the scrum guide. But just the fact the he is mentioning that every team can self-Manage is quite absurd and it doesn't reflect the real world.
Most developers just want to code, in fact a lot of them think they have to be handed the full list of requirements to just code (which I disagree with). A team will never be able to manage itself without enough experience and expertise in how to manage a project and the complexity it carries, specially if there is a lot of Cross-Team dependencies.
Btw, what is a "team" composed of ? Just developers and a designer for him ?
Does he really thinks developers have the capacity and time to do user research, talk to stakeholders, business leads, setup infra, manage timelines, and more just out of university ? 😩
This talk from him just felt like a contextless rant....
I started as EM since February this year and I can tell you there is way too much stuff to be done outside of a developer's world... Which is why EMs, PMs, POs, l roles exist.
Thanks again for the comment!
Good points.
Awesome reaction and thanks so much. This summarizes my thoughts about this presentation. Unfortunately these opinions have become comfort food for many low agile maturity teams
If I share this video with my company I will get fired! .... but I sooooo agree with you
A few weeks into my deep dive into agile after our company started doing `scrum`. Allen perfectly describes our situation (sprints ending on a Wednesday for every team). What can I do as a developer and pseudo scrum master to make this situation bearable? I'm already finding that we are less agile since moving towards scrum and Martin Fowler's quote of "doing half of scrum badly and tracking projects in Jira" hit the nail on the head.
You can send out your resume and find a better job. ;-)
I’ve been in this industry for 10+ years and have found that, as a developer, you can’t fix this. For the sake of your own mental health, don’t try to fight it.
I so like you talks organization want to be Agile not to want Agility and still do the same with new process that lead theme to new pain and new problem
Thanks
Thank you very much, Laurie. This is much appreciated! ⭐️
5:47
Thank you, just got that book.
If you find the very first book on scrum that was written by ken schwabber and mike beedle back in the very early 2000s. On the back of the cover in big letters its presents scrum as a rapper around xp that makes XP more latable if you will to people in business.
So this notion that scrum is agile and scrum came first that‘s part of these process wars“
To me, this seems to be the long running tension between running a business (which requires certain things in order to maintain viability) and the creatively of software engineers. I specifically say “creativity” here, because I do not see this same tension in other engineering disciplines. Software engineering continues to be different than, for example, electrical engineering. If the CEO of a company has a background in software engineering, it tends to work better. But not every company can have a software engineer in the corner office. All those Harvard business school grads have to go somewhere, right? And they seem to be well schooled in managing companies that run factories, sell widgets in retail stores, sell life insurance, etc… the emotion I observe from developers discussing the agile, scrum, etc… topics seem to be rooted more in their drive for creativity, than in providing engineering services. Artists have been struggling with this uncomfortable relationship with business (making money for their art) since the beginning of time. It’s just that businesses have adopted this “art” as a core function in their operations. It’s not a comfortable arrangement. We’ve not collectively found a solution to aligning business with creative people yet, in my opinion. I think the difference between rock bands being screwed over by record companies years ago and software engineers pushing back on business methodologies is not so different. It’s just that Software engineers know their worth.
When you look at teams that got the job done as part of large enterprises in any engineering field you discover they always work in similar truly agile manner. With minimum oversight and/or feeding the managers with whatever they want to hear. With usually one or 2 managers that really understands people, technology involved and usually both.
Pretty much every revolutionary car was build this way past 100 years. There is actually a running joke that every iconic German car has to be build in spite of upper management. Great example is Mercedes 300SEL 6.3. The prototype was build mostly by one engineer after hours from testing parts and chassis that fell of the assembly line. It was first performance sedan and defined the performance luxury car experience. Even Tesla model S is same thing from UX perspective.
I've been struggling a lot lately as a dev and I think it started when I joined companies with more agile processes. I find myself with 4-6 meetings a week talking about what we are going to work on for that week and why we are behind schedule, rather than letting you use that time to figure out a problem. It seems like the concept that a developer is a person who can also make mistakes and needs to figure out how to implement something is completely lost on the modern processes, the only thing that matters is closing a ticket by the end of two weeks so management thinks there is progress.
As an aside, this video was kind of hard to watch because most of it is just quoting people and citing sources. It breaks the flow quite a lot for me.
"The company that one works for is not the real world." ??? Actually, it really is. The real world is what MOST companies do, not what they could do or what they should do but what they actually do do. We can't all go and work for the few that you tell us actually do it right. In fact, if companies doing agile "properly" constituted a significant proportion of those in the real world then this video would be as pointless as a video about companies existing to make a profit.
Programmers of the world, unite! You have nothing to lose but your schedules!
Why do I have constant conviction that Agile, even properly done Agile, is about low hanging fruits and only functional part of the system? I doubt that you can write Kubernetes or an operating system in Agile way, because its too complex to a User to even comprehend. Web-page buttons are fine to be done in this way though.
So an agile shops sells value increments on products. I wonder if there's any comprehensive guide on how to sell such increments and run a business when the client is not your own shop. How much does Value costs? How to measure product profits? How to deal with feedbacks when you have a queue of customers waiting for their own increments? How to deal with clients who want to buy software as they would buy a car?
about self organizing, what is the statistic study on this human bebehavior ?
None. Is a cult. Cults don't rely on studies or statistics. You have to believe them and if _you_ fail is because you aren't as strong believer or because you are doing it wrong.
Self organising teams do not manage inter team dependencies well. I dont know how they could.
I've definitely worked for people who obviously were never adults. They treated actual adults like children and couldn't understand why their reports didn't like them.
About Rigidity != Agility:
True only for very mature teams. If you start with newbies, some of the rules must be absolutely rigid, the same as with children.
A Kanban without WIP limit makes no sense.
Scrum stories have to fit in one sprint (at least with the knowledge before you start it).
So I think we need both: Rigidity in following the principles and Agility in selecting the right tools and adapting them to the concrete situation.
And yes, Scrum and Kanban are tools and their usefulness shall not be overestimated. On the other hand, there is no need to reinvent the wheel every single time you do some new development.
watched for 20 mins before noticing the plague doctor mask lol
This guy is me as an old man.
❤
Scrum is not agile. SaFe is not agile. But it gets consultants into the door, where they just went through the diploma mill. The scrum coach is the Soviet Union Apparatchik. BTW, BigTech (FAANG) is not using Scrum or SaFe.
Faang doesn't even use Agile. None of these successful products and innovative companies rely on Agile (or agile, Scrum, Safe, however you prefer to name it)
If a company/management have to impose Agile on the "talented team" is because they don't trust the team to be smart enough to do it on it's own. And yes, Agile is never chosen by the talented devs, it's always imposed from the upper management.
@@errrzarrr "agile is never chosen by the talented devs".. really? what do you think they choose then?
@@matswessling6600 To be given a problem and then left alone
@@teammo959 that is exactly what scrum is. 1) you work on one thing. 2) you work until done. 3) nothing changes during the sprint.
which is: during the sprint you take a problem. solve it. take another issue solved that etc.
@@teammo959that's agile
Some quotes that I agree with:
"Jira is not a viable tool for doing things in an Agile way".
"The idea of a hierarchy of epics that contain stories...that's just not the way it really works".
"Kent Beck has said that Agile has come to be a devastated wasteland...it's become a priesthood where the priests don't really understand the rituals..."
"There's an ongoing series of process wars"
"Seff Sutherland...has been hardcore about saying Scrum is the one true Agile to the point where there's been quite a bit of revisionism historically about how Agile worked..."
"if you go find the very first book on scrum that was written by ken schwaber and mike beadle back in the very early 2000s on the back of the cover in big letters it presents scrum as a rapper around xp"
Some quotes that I DISagree with:
"self-organization which is essential to the way that agile teams have to work"
It would help if you articulate why you disagree. As it stands, I disagree with you, and the reason is that I found that as soon as you tell people how to work, it's not really agile anymore. You inevitably box people into something that prevents them from being able to react to change. This doesn't happen immediately, but as soon as you have 5-10 man-years of work in a software project, teams that had the way of work dictated to them (i.e. SCRUM) are completely unable to deal with this because there's no way you can bring a major architectural change through the process. Conversely, you also cannot decide architecture in scrum meetings. I've seen both, and both end in disaster.
On the other hand, a self-organized team of good developers (which does not mean they have to have 20 years of experience, though you *should*have experienced people on your team, or else you end up with address searches in mysql, people shoving all their business logic into Kafka, etc.) can decide to make major architectural changes if and when they become necessary.
At least this has been my experience over the course of 23 years working in many different teams and with different methodologies.
@@ToumalRakeshHi Rakesh. Yes, I agree. But "self organization" is a general description. It literally means that people are on their own, as a group. There is no team lead. That's what the phrase means, and if something else is meant, that needs to be said. Teams need a team lead. An effective lead does not tell people how to work. You are definitely right about that. But good team leads do a lot. They don't boss people around, but they get things organized, they ask hard questions, they make suggestions, and sometimes they make decisions: "We are going to try this", but they prefer not to do that unless they think it is needed to move things forward.
@@agile2academy A read on group psychology is highly recommended, (if you haven't; not trying to be smug...it's just really interesting if nothing else). Humans are social animals and will naturally arrange themselves into a hierarchy if left to their own devices. The short of it is that in each group there will be a (rather short in the grand scheme of things) period where members will argue and bitch about topics and whatnot. This is the natural way groups sort themselves out and a natural leader will emerge that the members accept and respect (because typically he/she tries to keep the group together and in harmony as much as possible). This is what your "effective team lead" needs to be and what seems you were trying to describe. Imposed "bosses" not leaders, and often from outside the group, who only give orders, have not and will not work effectively. Endless words have been spoken on this and fell and will fall on def years. My personal take on it is that what I see as necessary to balance rigidity with agility is to allow the agility within your groups but have them aware of a "greater power" that doesn't interfere much if at all but does have the power up to and including to dissolve the group in the worst case. This gives a sort of need to "appease the god" but which "god" is not actually a part of the group...Where management fails most often is where it tries to infringe upon the group's self determination and inject their control inside the group. And that's the "outside force" that is almost never truly respected by the group.
@@marian-gabriel9518 "a natural leader will emerge" - yes, true, but not always someone who is a good leader, or is inclusive, or fair, or competent, or has good judgment. Sometimes - quite often - a leader emerges who is political, persuasive, narcissistic, or a bully - it depends.
With multiple self-organizing teams on the same product and a common product backlog how can the teams orchestrate cross-team reflection without some sort of cadence synchronization as seen in LeSS or Nexus?
I accept that good engineering craftsmanship practices take care of a vast amount of the cross-team synchronization without any formal process overhead.
Break dependencies between teams instead of managing those dependencies - feature team concept
Haven’t seen true agile since the 90s and early 2000’s. Now it’s all just min waterfalls, part of large waterfall (aka “Safe”) and micro management to the extreme under the pretext of “agile”
Scrum is a deep failure. The Scrum master which is usually a bad developper or someone who hates developping becomes a team manager of developpers.
The Scrum master job consists on helping developpers to communicate.
Each morning, he organizes a status meeting which is called daily meeting.
He organizes ceremonies like a priest or a guru sect.
We mistaken real communication for communication posture...
The george Orwell reference is so accurate.
With self organising teams, or even self managed teams presented here, where would a role as an engineering manager fit in? Is that role part of the team as defined here? Spotify, used as example, defines some of things an engineering manager does as:
Build a highly effective team of search engineers and lead through hiring, coaching, mentoring and hands-on career development
In partnership with a product manager and a team of engineers, build a stack which creates a great search experience that delights users across Spotify
You will support the engineering team in formulating the technical vision and strategy
My takeaway is that the role you'd think of as an engineering manager in agile software development is really a team lead. Most groups of people, including self-organizing and self-managing teams, will either explicitly identify the main person in the group and follow them, or even silently determine amongst themselves who they think their leader is by asking questions of or deferring decisions to one member more often than others. Experience goes a long way, and being able to use what you've learned through coaching others is much more practical and efficient by the mere fact that you're still using your skills to develop the product. You're not just sitting in some out of the way desk generating reports and watching the rest of the team, double-checking "velocity" and "story points".
You'll see the title Manager coming from many organizations, especially in job postings, to convey the level of experience sought while also communicating commensurate salary possibilities as well. I've seen a lot of Technical Lead or Senior Engineer positions that don't pay much more than standard developer jobs within the same company, but you end up doing the type of work the Spotify Engineering Manager is described as being responsible for.
I don't see any contradictions here. Even if the team self-organizes, someone still needs to make final hiring decisions, approve raises and expenses, represent the team to higher management, make final decisions when team members disagree, help align the team goals with the org/company goals, and many other things that don't affect the day to day engineering work
It could be that there are less managers, (especially if you have tech leads that have some authority) maybe one per 20 people instead of 1 per 5, but managers are sadly still needed
Self-organizing team is a delusion. How do people still naively believe so escapes my understanding. Haven't ever met the first developer nor engineer nor architect that have chosen to work with Agile or Scrum or whatever you chose to name it, is all the same to me.
This Agile self-organizing thing all comes imposed from above, from the old man, the certificates vendor, the management or the Consultant.
Answer me this: if the "self-organizing" team is relied to be in fact self-organizing, can they chose to opt-out Agile or any of it's flavors? No, they can't. They have to reformulate it but never leave. Can they change how many meetings per week they have? Can they change that daily call to happen to 2 times per week only? I haven't seen that happening myself.
@@errrzarrr the easiest thing to change is how many meetings and daily calls per week you have. My team can meet tomorrow morning and we just simply decide to make that change.
@@errrzarrr You like the majority have confused agile with scrum. Agile is just a set of principles. Scrum is just a framework to implement those principles.
If a team decides to adhere to agile principles to deliver a project, then they can do it in however framework they choose to. Be it scrum, kanban, or whatever mishmash of methods that they come up with that works for them.
A true self-organizing team can and should decide what and how they want to do things to ultimately deliver value to the customer. Problem is not many companies allow that to happen. Partly the managers at the top don't truly know what agile fundamentally is and partly incompetent, lazy developers who don't want to take ownership and responsibilities and instead would need some 'project manager' to poke them relentlessly to get anything done.
Is this why spotify's app and web services are so frustrating to use?
What is frustrating about Spotify?
I click the song and the music plays.
Is Jira ain’t agile which tool do you recommend?, please help. Thank you. 🙂
Yellow stickies on a wall. But we don't do that anymore because people are scared of the flu and sitting at home.
Meanwhile, Universities Still Teach the Scrum Agile Method Without Debate !! We should have consensus on this.
Scrum™ is Agile™. Agile™ is not agile.
Product owners priorities tasks without knowing how the product works, because they don't use it, and they didn't develop it. Same thing goes for UX designers.
And product managers estimates task without having any idea of how to implement it themselves; but no worries, the points in the estimation don't translate to time... But god bless you if you can't deliver X points per sprint.
Hi Allen, nice video, thanks for making it. I do, however, have a small problem with the premise. I think that you are coming from the perspective that the "self organising teams" are made up from perfect engineers, and perfect social interaction among the team. I'm not sure that has ever been true?
Points that I like:
- Scrum is a wrapper around Agile that makes it more palatable to people that DON'T actually want to be agile.
- XP works fine. Scrum+XP works fine. And in fact, Scrum without XP doesn't work at all.
- Agile is all about flexibility. If you look at Scrum there is no flexibility there. You cannot be rigid and agile at the same time. It's just not possible.
You can't just ignore people... apparently, the tech world today ignored this 😢
This is not about programming at all. This is a video about tribalism. ;-)
"Tools move a way people from thinking in agile way" - so true
When I was using Windows and then migrated to Linux - the way I was looking at a computer, OS, etc totally chanted.
people first: it is a good thing, but people has to be qualified with the mindset, and capable of pushing the work forward, also understand value in term of work and goal defined among team and organization. This will never be an easy thing for any company, especially cultural differences where people are simply too used to be assigned work to, or work as they are told. Self-organized team in such case will potentially bring chaos without understanding what is self-organized mean. Some of the aspects should be taking into account: the boundary between people, team, value of self, business and client.
has to be communicative: Effective communication is hard and many people will misunderstand that we should talk a lot. Too deep technical problem to be communicated with someone who aren't impacted directly would be a waste of time. So the question is really what is the effective communication? Purpose of communication must be clear, then choose the appropriate method for communication, is this should be written down, or face to face, or tooling oriented as such Jira?
Scrum is a good 'agile' process, perhaps it should be treated as a 'pattern' but it's a good place to start on agile.
When we try to answer "what is Agile", 100% of the time, we should refer to the Agile Principles. Second, why do all of these talks waste so much time trying to be esoteric and pseudo intellectual? This is every bit as much of the problem with Agile as the "Agile Industrial Complex". In fact, it's an integral part of that complex. We are engineers. Engineers need data, facts, information presented logically and succinctly. And yet, we have non-engineers constantly pontificating endlessly for hours about something quite simple. Post a link to the Agile Principles and be done with it. And go build some software. We have too many priests in our profession, and not enough carpenters.
21:42 minutes. Say People team, not HR. Startups dont use that term anymore
True. Sadly, in my experience, the name change is mostly a marketing exercise. Same old processes and approach. Humans are still managed as “resources”. So I have found it to be a difference without a distinction.
What is dead can’t die!
So far I'm 16 minutes in and absolutely zero of it is an attempt to "understand the mistakes that were made with Agile", it's all been "no, you're just not doing Agile RIGHT". Still half an hour to go but so far it's not the video that was advertised, or that I was hoping for...
My sentiment exactly. I got absolutely nothing out of this video. Maybe I'm just don't care about scrum bashing.
@20:17: that's the thing, since that is a lie, all of the subsequent logic based on it is flawed.
Can you talk more about what agile *is* instead of endlessly bashing what everyone else is doing?
I agree that jira is a work of the devil. NVIDIA enforced jira internally three years ago, their drivers now became a piece of crap.
this guy is a sophist.
Mostly agree but seems very prescriptive on how you must do Agile while at the same time saying that you can't be rigid and agile. You must release faster than every 2 weeks, you must not work remote, you must or must not do...
First and foremost you must not listen to any of the bullshit on the internet... and it is all bullshit. ;-)
If you change the world Agile to communism, this presentation works the same. Great presentation.
It's more general than that, still: all ideologies and religions are equivalent to bullshit.
Sounds to me like every other cult.
"If you dont get spiritual enlightment it''s because your faith is not strong enough."
Exactly. When a gym coach tells me my running backwards instead of forwards is the reason I'm not getting fit enough, I make the same point. "Oh what so I'm doing exercise not in the One True Way!!!111eleven" I say, defeating his religious nonsense!
Is a cult
But enough about Scrum
Lack of coordination, involving the end user in more and more beta testing and inability to define the term "agile". Gee. I wonder why it's failing.
yet another non sw guy teaching the world what is agile.. why is it good anyhow
Allen Hollub is a well known anti-scrum who is coming to that position from ignorance. He does not know what he is talking about. I explained to him a number of times what is the problem with his thinking and he did not get it. I was there when other people explained to him the stuff he doesn’t understand and he did not understand them either. He just doesn’t understand things he is talking about. If you think Allan is an expert, I am sorry for you.
He is an expert. You probably weren't listening to him, which is a shame.
The irony in this comment.
42:50 "harness good, block bad"
I wish everyone knew and lived the agile values in a way they can understand his message as it is… All of that “junk” he mentions at the end of the video… is only junk for a company that is way way beyond it…. that has been working with agile frameworks and practices for years !!
For many other companies… this is gold ! this is a great challenge ! this is a big step into a new way of working… and for that people is that we are here… to help this people navigate change… learn with each step.. and go beyond this memes and templates to become really agile…
Corporate driven "agile" produces developers that don't care about their product or their code quality.
All that matters is the process. All hail the process.
@@khatdubell You are being sarcastic, right ? I don't think that "caring for your work" is something you can put on corporate or agile.....
@@martincatuara no, im not being sarcastic. Just Google something like "scrum makes bad developers"
@@martincatuara it sounds like you've never had to work at a super corporate place where any deviation from Process is punished.
You're lucky.
An anecdote from my own life.
I've work at a place where someone had several pull requests that had been reviewed and approved just needed simple one line fixes to pass cicd pipeline, which were called out in the review. (Spoiler alert, I did the reviews).
After having multiple mere requests sitting for months not getting merged because of literal one line changes, I took it upon myself to make the changes and get the code merged in.
I got in trouble for that.
Highly corporate environments will wear you down.
You can bet your sweet ass i won't be taking the initiative like that again. Good code is sitting for months? Not my problem. Not my concern. Let it sit. I'll focus on exactly what I'm given to work on and focus on like a good little helper monkey.
That is one example, there are many more.