วีดีโอ

It's amazing to me that we started with the Agile Manifesto and landed on the scam that is SAFe. Oh, how the mighty have fallen... It's a powerful sentiment when the original authors of the manifesto actively advocate against all of these frameworks. Also Agile was not founded on Lean principles which came later.

Everyone whines about management and tools. Then you become a manager and you see it aint easy. That is why these processes are and frameworks are necessary. By the way, showing SAFe as an example is a strawman. SAFe is basically waterfall. Showing SAFe as an example of scrum shows you do not understand scrum at all. However, I automate the hell out of everything. That's how I enable my teams.

So use Kanban then...

So I’ve been thrust into all this because I have an exam on “Software Processes”, which basically boils down to agile. My teacher seems to be in favor of agile, but constantly mentions that there is a dark side to it, and that we should be careful to not fall into it. Having seen a couple videos on people who, like this, are against agile and scrum, what I’m taking from it is: agile, and the agile manifesto are, in principle, goof ideas, it’s a good framework to follow. However, scrum and other such processes have ended up adding bloat and going against the principles of agile, so in the end, when people use these processes to be agile, they are actually failing. I take it that this is what my teacher means by the dark side.

Try ipad mini

Pointing out the downsides of agile frameworks and processes in organisations that have lost their way with it helps to make people think. However, it is even more valuable to jump right to the positive side and focus on improvements. You mentioned some improvements like "avoid or automate the hell out of all time consuming and non productive processes". A cohesive set of this kind of improvements like that would be helpful today. Perhaps we need a new manifesto? With things like "We value automated processes over manual processes" and "We value daily stakeholder engagement over sprint reviews" and "we value non restrictive tools over restrictive ones" or something like that.

- 1) **Daily standup** is intended to be a very short, high quality, face to face synchronous communication period. Can asynchronous communication replace it? Also, there is nothing that says the work of the day cannot start before the standup starts. In fact it's extremely common for global teams to have only a single standup per day and it occurs at different parts of the workday depending on the locale - 2) **Sprint concept is outdated because of CI/CD** and since your work is typically done before the end of the sprint you see redundancy in having a 2 week sprint. There is obviously a practical limit of how often you can demo to stakeholders. Also, the tendency is to exclude stakeholders to make arranging the demo easier. This is a sign of an organization focused on production output over business impact and very common. This is a primary cause of why most software features don't give good ROI to the business. You keep doing this and you end up investing a lot of iteration on features outside of the "vital few". In extreme cases the entire product is compromised and killed off. - 3) **JIRA** came way after Agile and so obviously nothing about Agile claims that particular tooling will result in good practices. Agile is above all a mindset, secondly principles, thirdly best practices that are intended to evolve, and nothing else. - 4) **Time tracking**. Heavy emphasis on timetracking is a symptom of fake agile, most likely driven by non agile contracts. - 5) **Scrummaster**. If your scrummaster is not shielding the team and you are having to do it, then you're actually the scrummaster! You didn't mention this, but a dedicated scrummaster is probably not needed with an experienced team who doesn't need coaching, where little customer interaction is happening and priorities are stable. However, ask yourself also if all your critiques could be applied to any project management methodology that may exist and not just agile. If yes, then it's a symptom of confirmation bias where anything related to project accountability, management and insight is scorned. If I have a bunch of money to spend and one team gives me visibility and the other does not, which one am I going to pick? - 6) **Reporting** How much time do you think agile actually requires for reporting? With CI/CD tools and so on, it should not be that much actually. And in my experience, teams that reject oversight and just produce watermelon reporting eventually get bitten.

You hate Jira? Please use Octane. After that, you will love Jira ;-)

Wonderful video for engineering managers.

I am sorry to hear about your bad experiences with Scum and Agile. I have nearly 15 years of experience in Agile and can vouch for the requirement for Agile to deliver complex projects. Unfortunately it seems the agile has been misinterpreted or misused in the projects you have worked with and I can understand your frustration. It is not to increase the productivity but to deliver the most value to the customer. Both are different. I have seen agile being used as a stick to increase the productivity and efficiency but that is BS. Those are anti patterns.

I understand your complaints about Jira, but could make a suggestion in replacement of Jira?

Hmm I do agree in most cases, and I think you being very close to stakeholders makes you a happy person :D I'm very jealous. I do agree on JIRA topic as well :)... Few comments from my side: 1. Remember that SCRUM (nor any other agile framework I know) does not limit number of releases during the sprint/cycle (I was working with teams that was releasing to production 3-4 times during a 2 week sprint) 2. Daily is unnecessary for a teams when we are speaking about "status update" as this can be red from all the tools you use... I do prefer reuse it to rather allow the devs to discuss architectural plans maybe take a look into items that needs to be refined shortly. etc. (I do prefer to ask a question - think what would you be discussing with your colleagues if you would be having a technical meeting of 1h every week), that shifts the focus of dailies, and I believe a technical meeting for developers alignment is usually happening either way after daily (and it shouldn't) 3. SCRUM Master currently is not a person who is "enforcing" SCRUM guidelines (if that's a SM you see I'm sorry for you) In my opinion he/she should be rather a person who is looking for supporting to ELIMINATE unnecessary meetings if possible, help Business and Dev's to capture as much as possible of requirements, and get closer end users to the team. You are a happy person who is working with stakeholders every day. I'm an SM who was fighting 3 months with management to allow UX/UI designers and BA meet with users to run a session with them. Other example I had, I've joined a "stream" which was holding team members (~20 of them) on one set of meetings where the people in reality were splitted to support and work on 5 products. and it was exactly what you said, an unfruitfull meetings where e.x. some people must've listen about product development that they wasn't even working on. None of them wanted to stay in opposition to the management, so this was happening for 6 month's before I joined to the team. Now the teams are splitted and focusing on products having and saving a lot of time in the meantime, as they have less and more focused events, they actually need (and yes some of the teams are actually havind stand-ups only 2 or 3 times a week, as they do not need it more often) 4. I believe SM's should be multidisciplinary and actually work more with Business/PO's to help them understand why, actually speaking with Developers is important, and how to measure success of a team (not via metrics you presented in JIRA). Personally I'm fighting with all the devs managers who are compering developers in my team based on "Lines of code written" or "story points burned" etc. As a dev, you probably will not tell your manager that's a wrong approach, as SM I don't really care, as not he is deciding on my work. Shortly in my opinion is important to gather feedback and to be able to reflect on delivery, but the metrics above or the metrics from JIRA shouldn't be the ones which are measurement of team's success So just saying that maybe the SM's "who are bullshit talkers" and are afraid of their careers are the ones you actually are meeting so far :). PS. I do agree about bullshit SAFe, LESS, ACCENTURE Model, Deloitte and other abominations of agile, which are focused on hierarchical structure. PPS. Last but not least, would love to see how you work and experience the positives you are mentioning about, maybe there is something I could learn about. :)

The worst of all is the shitty Srum

I don’t think any enterprise level ‘transformation’ should be handled entirely agile or other methodology. I think an adaptive approach to suit the team sizes and cross functional work streams. I’d opt for a waterfall over all delivery view of the programme of work with teams working how they feel best but deliver to quality/time gates.

This is what happens when people focus on form over substance. From what you are saying, the most urgent thing that needs to be run in your set up is a proper retrospective, where you talk about what works and what doesn't work. Also, what I see over and over again is organizations implementing "Agile" or "Scrum" but don't actually have a clue what that means and how to implement them properly. 1st point on the Agile Manifesto says "people and interactions over process and tools". A checkbox-style enforcement of a series of meetings is bad "agile".

Thumbs down 👎because 1. There are team where SCRUM works <- he admits then proceed to rant for 10 minutes about unrelated topics 2. Talking about SCRUM as if it's same as Agile 3. Talking about JIRA as if it's same as SCRUM and Agile 4. Talking about SCRUM master as if they come out of a factory stamped the same way and all they do is run SCRUM 5. What you can do is actually a lot. Learn and teach others that *Scrum* is not Agile is not JIRA is not Scrum Master is not *Scrum* (recurse)

Completely agree with this video. I have observed that it is a symptom of the "professional management" movement. The only thing that will replace it is something even worse. But there is a silver lining, the Western professional management world is crashing. It is going to be a rocky period hopefully that demon can be exorcised.

Spoken like a true developer that wants autonomy. Tracking time is BS??? What a luxury

I've got in trouble with dev mgmt because I provided bug fixes outside the sprint to our sales users... it was against their religion. They wanted me to wait 2 weeks because that was the schedule. At some point they wanted me to not answer users' questions nor have meetings. At some points they got ejected from the company. Worst 3 years... The crazy thing is that while it was called agile it was the most religious structured movement i have seen in my entire career...

So why don't companies hire more in Europe? Still looking for that video

this video is awesome

Yes! US has High Competition within the context of talent pool! Definitely the reason why the salaries are high in US Tech Sector

Thank you I needed this.

10:19 I think you have been exposed to too much fake agile, Agile is like lean a human first philosophy. It is not meant as a organisational micromanaging tool. Exactly as you say, scrum masters should try to limit organisational waste and optimize the time and the product delivery, which means take away bullshit from decelopers and help them be their most productive.

5:36 ❤❤😂😂 #Jira just exellerate whatever screwedup process your organisation has.

3:38 Very informative.. maybe scrum is getting too slow, since things might work so fast now that sprints of hours are becomming the norm. But does it take so much less time to make a new software program than it did earlier..? I dont see anything revolutionizing software out since Windows, excell and words to be hornest..!

3:32 I dont think it is mandatory to have sprints of 2 weeks it could be 1 week or three days, depending on the product. It seems counterproductive to have the stakeholder interferring constantly, or daily unless you have very very short sprints and product development cycles. …

It seem the scrum master should be doing more of the talk with the productowner and shielding the dewelopers.. from coorporate BS ..

2:51 Productowners speaking for half an hour? That does not sound like your environment understood Scrum or Agile..! That is just a regular meeting with a person that needs attencion and likes to talk. …!

👏👏👏👏👏

Out of curiosity, why do developers only care about how these agile ceremonies affect them? Why not look into why it is needed? For example, how is an organization supposed to approve budgets, track progress, and scope without some of these ceremonies? We all know about six-month projects that have dragged on for years; the inconvenience you feel is a small price to pay in the grand scheme of things. I do agree PMs and BAs do not need to follow it by the book, but to act like there's no benefit is truly disingenuous

I honestly gave up on making anything good. I write shit to the letter and if it becomes garbage in garbage out then you've got only whoever wrote the jira issue to blame. I work for the government and any attempts to implement scrum or any form of agile just fails hard here.

Agile cargo culting. Well explained.

On the face of it maybe, but the picture changes when you take into account that people in Europe are not saddled with enormous student debt, have access to healthcare at no or little costs, employees pay into pension funds for their employees and so much more. The salary doesn't need to be as high as the US. With all the benefits you get through the government and companies you are left with the same amount or better left over at the end of the month. Exceptions apply offcourse. The height of your monthly income is a poor comparison metric. You need to take into account the price of living in a country and the quality of living. The first is usually lower in the EU and the second much higher. The US also has a higher tax burden and a US citizens gets far less for that money.

actually scrum kills passion !!

Healthcare in the US is the best in the World if you can afford it.

I wish I saw this video before I became an EM... 😅

I went from finishing 30+ tickets in a 2-week time frame to finishing ~7 after our new idiot director of engineering decided to implement SCRUM against our wishes. The useless meetings, pull request reviews, ad hoc requests, and most of all, making developers work on things with which they're not familiar straight up KILLS productivity. Then he has the gall to mention that we "have to get better about finishing the work in our sprints".

Agree with you. That’s why I like leading tech departments in startups. There I can shape it the proper way so it is as productive as possible. Good video.

It’s important not to conflate agile with scrum or any specific practice, including reporting. Agile didn’t fail - the people who tried to abstract it a way in an easily abused framework failed.

I agree with almost all of this. Stand-Ups turn into status meetings. Scrum and Sprints are essentially small waterfalls.I feel strongly that Scrum Masters are unnecessary bureaucracy and a waste of an FTE. This being said, Kanban is miles better; it's lighter, it's quicker to pivot, it's continuous Agile and more able to respond to issues found in shift-left testing. I agree that Customer demo's are not necessary if you have highly engaged customers. However, many Enterprise stakeholders are busy and just are not interested in spending time with dev teams; Further they don't speak the language of software. This being said, a Product Owner with deep domain knowledge can provide real value by acting and the proxy for customers, helping to prioritize development that aligns business strategy, and speaking a common language. TL;DR - imo, use Kanban.

I love how all these people just say, you aren’t doing scrum right if you say it’s not working for you. When most companies aren’t doing scrum right and I have 0 input into changing how a large organization does things 🙄

A stand-up is literally 15 min to see if anybody has blockers and make sure we're still as aligned as we were yesterday. If you can't make 15 min out of your 8+ hours of work, then there's something wrong with you. And if your stand-ups don't look like that, then you're not doing stand-ups or agile, and criticizing "agile" doesn't make any sense. You can only go as far as talking about the pitfalls of failing to be agile.

This video is spot on but misses the bigger point about the failure of Agile. Nearly 30 years ago I made a comment to one of my PMs that still holds true today... you shouldn't do work because it's easy, you should do it because it's important. This comment came at a time when it was popular in software development to want to show progress, ANY progress, in the thought that releasing new features was how you justified new software purchases by a public shopping for packaged software on a store shelf. Yet the value proposition for most software is (or at least should be) what kind of return that it brings on the investment being made. I'm currently doing contract work at a Fortune 500 company, and my team is trying to bring back Agile after failing to implement it once before. The motivation for this change? It was stated that management needed to know how it could shift resources to get more work done with what they had. Now let me ask this - is the goal to get "more" work done, or "more important" work done? I would contend that if your top single priority task requires 100% of your resources to the exclusion of everything else then that is what you should be working on. There is no idea that "we'll knock off this feature because it's easy". When you start doing this then you quickly go for the quick wins and nothing else gets done. So my point here is that Agile development doesn't represent a lack of ability to organize. Instead, it represents a lack of ability to prioritize. If managers could select and stick with the right priorities then Agile could be useful. We don't want to return to the days of waterfall development where there was NO feedback until the product was done and then it failed in the market. But we also don't need the pressure of a 1,000 different projects all fighting for a limited number of resources. My last company spread resources too thinly because they we unwilling or unable to charge customers an appropriate amount of money to do quality work. As the years went by, it became commonplace for management to make unrealistic promises by assuming that they could just juggle projects using Agile techniques. But at some point something had to give, and it was the bottom line that took a hit as customers became unhappy with the results that we were delivering. So my feeling about Agile is that it's more smoke-and-mirrors than a useful tool. Set the priorities first, then see how much Agile infrastructure you need to support it.

Scrum is designed for three things.: - Effective communication of things that matter - Tighten the feedback loops - Share bad news early to prevent surprises. To make that happen a scary thing has to happen: - Give complete control over HOW the work is done to the people doing it Most teams that could use Scrum well are prevented because bad managers won't give the teams full control of the way of working.

Scrum was created as a wrapper to XP, so that it supposedly could be more palatable to management. The only way that Scrum has anything to do with Agile is if it is selected by a self-organizing development team as their chosen methodology. Otherwise, Scrum has zero to do with Agile.

Fix the leak first!

I think Agile techniques should be valued over a forced framework or process. You should use the techniques that serve you.

Agile crept into marketing as well. I’ve come to realise that, in marketing, when the management want ‘agile’ project management, it’s code for “we want to be able to change the scope, the budget or the requirements at any given moment, for any reason”. And don’t get me started on the “daily standup”, which is an excuse for insecure managers who don’t trust their team to get the work done.

Great video, really helpful!!!