🎓 Learn how to work as a highly functional software development team using highly sought-after modern software engineering practices with my online courses. Particularly this one 'Better Software Faster' ➡ courses.cd.training/courses/cd-better-sw-faster
@@SufianBabri Well I don't know why, I guess that is a firewall problem at your end, the link is correct. You could try the home page of my training site here: courses.cd.training But if the first doesn't work for you, this may not either
@@ContinuousDelivery It seems to have resolved now. Back when I reported, neither the home page, nor the course URL was opening, not even with Tor Browser.
I've personally worked in two separate orgs that were brutalized by SAFe consultants, resulting in mass layoffs or turnover. My experience was so horrible that I've since made it clear to every new manager or PM I have that the moment the company brings on a SAFe consultant or begins trying to implement anything that looks like a 'release train' is the same moment my next job search begins. SAFe is literally the meme of spending more time moving jira tickets around than writing code or building products except explicitly codified in processes that span the whole IT org with a handful of dev managers and product owners empowered to enforce the processes at all costs. Its no mistake that every one of those people who were given that authority went on to become SAFe consultants themselves.
Sorry to hear you had terrible experiences with SAFe consultants. I've worked with a number of tremendous SAFe consultants and trainers, although I'm more than aware that there are also those whom I would advise to never let anywhere near an organization - some of whom I have also met, and had to fix the mess they caused. I wrote about the problem of bad SPC's back in 2019 - failfastmoveon.blogspot.com/2019/09/why-spc-will-destroy-safe.html
These consultants stroke the egos of the existing mgrs and wedge their way in. Then you are left with a hybrid of some safe agile and some of the worst traits of the leftover mgt practices that makes it hell on the creators.
The waterfall is not dead. Every day it rises from the ashes, but now in the form of agile-waterfall, whenever someone says "we need to improve our estimates". Dave, thank you so much for sharing this. Your book is awesome!
SAFe is for a few of things: (1) Sell certification (2) Keep project managers in jobs (3) Give senior management warm fuzzies that they have "implemented agile" When you look at the SAFe diagram, dev and engineering teams are somewhat diminished with the ART etc taking priority and the customer is an afterthought.
I disagree and think you're missing the whole point of SAFe. An organization that applies agile top to bottom develops common WBS patterns and vocabulary that are easy to understand co. wide The alternate is that team level agile and upper management waterfall practices collide and have to be translated. Managing this junction point takes a lot of energy and resources from the organization.
From a systems perspective, SAFe® is successful as a framework to be sold because it keeps the social system of the middle management in place, as described by the Larman's law. The system would usually try to keep itself alive by reacting to any change in its environment accordingly. SAFe® seems to be the safest way for this system to preserve itself why addressing stakeholders' demand for agility.
One thing that SAFe has been good at is giving me cover to introduce more agile methods to our process. We are definitely not fully there because that is just too much stuff to change quickly but our processes keep getting better over time and our results continue to improve.
Thanks. Very important perspective here. I'm pretty SAFe-skeptical for 90% of the orgs that roll it out but I do like to hear the counterpoints and success stories. Bless you for doing yeoman's work.
One thing to remember about SAFe is that in order to get certified you have to go on a training course given by Scaled Agile Inc. This company must be making money hand over fist by selling training courses to enterprises, which is probably the main reason for inventing SAFe.
3:25 I'm a hardware engineer, whose company decided to adopt SAFe, pushed by the software team. There is absolutely a doubt for me as to whether "true" Agile methods work better than SAFe or Waterfall. It really depends on the task at hand. Hardware isn't software. Hardware has unique challenges, and there are different types of project. Waterfall works pretty well for hardware, especially if you give some loosely planned exploratory time at the start of a project. The number of times I've been told by software engineers to just break down my 12 month, multidisciplinary, hardware deliverable, into irrelevant 2 week "sprint goals" just shows me that most people pushing Agile have no idea about what hardware design needs, nor do they care.
@@Ikbeneengeit you could take a larger hardware project that requires say more upfront planning, and divide it into smaller deliveries that could fit in a sprint. I believe this would create good cadence and keep the project humming along. It requires a good scrum master to elicit and document the sub steps from the team at planning. Consistent delivery is a good thing, as is breaking down the big rocks IMO.
The reason they want predictability is because they want to to be in total control. They want to know exactly what will be produced, by exactly when. Successful companies have long moved past that, they now instead seek out business opportunities, and they then hire a motivated technical team to pursue those opportunities. They give up control of "what" and instead trust and enable the technical teams instead to work out what the best technical thing to pursue is in order to the advance the objectives. Early on in Agile, the true successes came because management and executives who used to hold iron grips on timeline and scope relaxed scope while holding onto timeline. These days truly successful companies also give up control over timeline as well to the technical teams: they do the business research, and then present to the technical teams the question of whether it would be appropriate to put in more technical effort and delay market releases. They also do the business work of checking whether the market is ready for them, whatever state their technical code is: sometimes the same product will be more successful if you delay it for more favorable business conditions.
Fantastic video Dave. So... to me, at least, Agile has lost it's way. Back in the day, early 1980s, we were moving from waterfall to RAD (now Agile). This was made more formal with the advent of DSDM in 1995. I gave my first DSDM course in March of that year. I ran quite a few RAD projects and we did deliver better software faster. At the very least we built something that was acceptable to meet the business need when it was needed by the business. After having no contact with software development for almost twenty years, (well I am retired!) I am dismayed that people are talking of going back to waterfall as a 'new' generalised approach (That said waterfall is still useful for those projects where the requirements are unfuzzy). As for SAFe... the mind boggles! Keep up the good work Dave!
I just had my first experience with SAFe this past year. It was a complete train-wreck. Basically, they took practices from waterfall, gave them agile-sounding names, and pretended they were agile. This is obviously just my anecdotal experience, but I did a bit of research after encountering SAFe. I was baffled that any company worked this way in 2022, and I thought that surely it must just be a poor implementation of the methodology. But the more I looked into it, the more I found people with similar experiences. SAFe is clearly snake-oil.
Similar experience for me, it went so poorly that the company outright bought its competitor and laid off every dev/qa/analyst in the release train. Ironically all of the dev managers and PMs that pushed for SAFe left to become SAFe consultants themselves.
I'm pretty sure this is the modal usage mode of SAFe: "took practices from waterfall, gave them agile-sounding names, and pretended they were agile." That's both based on personal experience and asking around. I like that Dave gives at least some credence to the view that it's a step toward Agile, and I'm sure some practitioners do a great job of using it that way. They're probably the folks who would thrive regardless of methodology. Anyway, don't go running out of a job interview if they say they use SAFe, but absolutely spend your own question time asking *how* they use it.
@@PhilipJReed-db3zc I won't necessarily flee SAFe, but based on this experience I will ask some pointed questions from potential future employers. In particular, I'll be asking what sort of feedback the development team has given on product design, and how that feedback was integrated into the product. I think that will help me to determine if this is an organization I want to work with.
@@PhilipJReed-db3zc unless the situation is literally that the org had no formal sdlc practices prior to trying safe I would have absolutely no reservations about walking out of an interview upon learning they use it. Even then I'm not necessarily convinced that safe is better than nothing, my experience with it has been that bad.
Predictablility is still required by the "money owners" because they have budgets, and they answer to executives about the ROI related to periodic (eg quarter steering) meetings. Honestly, and unfortunately, I have never worked for any company whose executives do not complain about money "spent" on errors, also, that's why many of these companies contract outsourcing consulting companies, since they don't consider development as core business and basically they transfer the risk to the consultant company - demanding "excellence from Mark 0". How to deal with it?
Unfortunately, that's the firefighter's problem: You never get praise for a fire that never happened, but you become a hero for rescuing someone from an inferno. With good agile practice, we spend a bit of money to prevent a lot of risk. With bad development practice, we spend a lot of money and incur the risk so far down the line that everyone will try to report it as at least a partial success, because it would be too expensive to call it a failure. I've personally witnessed $100m+ development projects deliver literally nothing except a document. But with agile ways of working, we will make a lot of small bets and constantly account for them. And a lot of those small "errors" will show up as "wasted expenses" in the books. Whereas those multimillion dollar projects that deliver nothing ... will show up as CapEx somehow. It's an accounting issue. A guy named Daniel Doiron wrote a great book about how to change executive financial mindset.
@@thought-provoker Years ago I was in department meeting while the department head was handing out the "Firefighter Awards." A co-worker/friend leaned over to me and whispered, "Some of those firefighters were the arsonists too."
Yeah, same here. No one wants to predict from the ever growing pile of stories, but wants to know when "Feature X" will be out the door, whether it is something the customer wants or not.
Unfortunately I don't think anyone is ever going to find a solution for bad management :) Lean thinking managers don't behave that way, but seem to be few and far between.
I was a solution architect in a SAFe project at a large company. It was the first time they did something like this and they shoehorned SAFe, Agile, SCRUM and DevOps into this massive project and expected wonders like less headcount since the developers would do Ops-stuff (wrong) and full control and cost predictability like in a waterfall project. And the rest of the organisation was not like this at all... so when we needed changes in the communications infrastructure for a feature, we had to wait for two weeks while that team worked their waterfall process. Barring all the other things that happened, I got turned of SAFe rather profoundly when I started to read about how it was supposed to work and how it didn't. Artefacts there needed to be produced but never went anywhere and a disconnect with the developers not supposed to talk to me and me to them unless it is cleared with a manager. Overall, at least they way it was implemented we had more managers on the projects than people actually doing anything. Four developers, one architect, three Business Analysts, three Program Owners, two business liasons, three project managers and scrom masters and two lead managers. Totally mad. So when I see SAFe these days, I try to steer clear.
Reading that roster of roles nearly triggered a sympathetic panic attack in me. Had to remind myself that I was not going to be one of those four unlucky developers. That is a cruelty I would not wish upon a sworn enemy, much less something I'd want to be involved with myself. I can only imagine the constant scope creep, shifting and conflicting requirements, neverending demands for ETAs and status updates, and absurd deadlines that inevitably lead to mountains of technical debt and resulting nightmare, unsupportable codebase.
I worked for a company recently that is heading towards SAfE, though not fully implementing each practice like release trains. It was something that management loved but lead to poor software: - it gave middle and senior management a feeling of control and planning via story point tracking and increment breaks, but disconnected teams so much from customers that we had no idea if we were delivering value - team composition and ways of working were set by middle management, with a facade of delegation to teams (who had only limited freedom to decide how to implement features) - because of the hierarchy, although we had cross functional teams we had only one ops expert in the whole division (~50 people) and no one was incentivised to take ownership of system maintenance/support - the central planning/control also led to chaos when a critical system went down, but developers weren't given access or support to either help with the outage or build workarounds (my colleague and i were expressly forbidden from working on other ways of testing - so our entire team couldn't test any code for 5 weeks) Uggh, i think i'd rather deal with waterfall 🤣
I think your point about implementing ALL of it is totally valid. I've used - and I still am - parts of the SAFe implementation plan in order to enact change in the organisation. Once we reach a tipping point and start looking to develop a vision and strategy however, we look for what works for us. We use some ideas from the framework - empowering employees, generating short-term wins, consolidating gains and producing more change - but we don't tie ourselves to their solution. Why would we, we're not them. Their framework appeals to C level management and has allowed me to drive change across the organisation, but we went with the ground up discovery of what will work here.
My feelings about why SAFe was introduced in my company was that we have been (very) late on delivering on time what was written in a customer conract in the first place. And we do a lot of extra work that I think is just for the sake of numbers and some fancy figures for the management. We are about 150 developers and close to 100 non-developers in "management" roles. That may tell a lot on what happens when SAFe kicks in.
Since I don't work yet, do you think managers feel more "safe"? They clearly had emotional rollercoasters with late deliveries, do they feel better now?
This is a good point, management likes control because they are reacting from trauma from past projects gone bad. But it's like someone who's overweight eating chocolate to forget about their sadness from being overweight... it's a vicious cycle
@@theodorealenas3171 I think they feel different now. But there still is a strong request on features to be delivered in time. In addition we are not allowed to deliver a "Program Increment" without a new feature. It feels wrong to work this way. I hope we (as developers) can insist to adapt to a higher efficiency.
Projects rarely suffer from something where SAFe has a solution to offer. These agile coaches are usually nice people, but they are often detached from actual software development and any code for over a decade (or are fresh from university) and never implemented code themselves in an agile project. And for some reason they think, that if SCRUM is just organized enough and religiously followed enough, high software quality and high speed is achieved, but SCRUM doesn't care about quality at all. It's often a Cargo Cult. I can't take SAFe serious anyways since i'm a certified SADMF (scaled agile devops maturity framework). If i just hear "release train", i ask: "isn't a release convoy better?" Just today my company pushed SAFe and an agile coach into my new (greenfield) project and the talk about release trains started within 10 minutes not because we need it but because a manager likes it. So once again i have to convince people to not slow us down with waterfall milestones, processes, branching concepts etc. It's completely unnecessary for our backend services, which will be fully tested automatically after each commit, canary released and automatically monitored. So basically we ignore SAFe as much as we can, but will be part of another SAFe success story.
In SAFe training they mostly talked about using agile for everything except code. If they only targeted code they would not sell as many organizations on it.
I don't know anything as big as safe can be called "agile". We called it the Fragile model. The only people that liked it were senior managers and those who wanted a career as SAFe coaches etc...
SAFe does have some advantages for larger enterprises. I work for a company that has about 40 agile teams, about half on the backend, and the rest on device software. Previously the teams would all individually move faster... but wouldn't be organized, so enterprise level features (multiple device teams + multiple backend teams) could take a LONG time to "get to market". SAFe let us get the backend teams to work on the features that were important this quarter (program increment) so the backend development would complete more quickly. Here's an imperfect analogy-- your company sells cars, and your sales team just won a big contract to make one of the models of cars go faster. Pre-SAFe: The engine team runs with this immediately. At the end, they ask the wheel, brake, and suspension teams how they're going. The other teams go... what? We have our own priorities, maybe we can get to that next quarter. After a year, everyone gets their act together, the feature is tested, and then the cycle repeats to deal with the multi-subsystem bugs. Post SAFe: In PI planning, upper management tells us that the "speed" feature is a priority. Prior to the PI, the architects realized that the engine, wheel, brake, and suspension would need updates. During PI planning (ideally beforehand) they estimate their portion, and that capability is part of their backlog for the PI. The feature (including engine, brakes, wheel, and suspension) is tested end to end. There a less bugs found, and the one found are easier, because we're fresh off implementation-- we don't have to review the parts from scratch. So... SAFe means that individual teams don't get to work on as many of their priorities, it means that big features that our customers are demanding are available to customers sooner.
It's amazing how many so called software development improvement practices were created to make non technical management feel comfortable due to their lack of understanding or desire to understand fine grained requirements, while preferring a cloud 50 foot view.
For me, I noticed the website promotes going faster as a primary goal of SAFe. However, going faster is not a primary goal of agile, rather it is a by-product of everything else we do. Fast and agile aren't synonyms. Very few people would describe Usain Bolt as agile yet I'm sure everyone has described him as fast. So for me does the sites misunderstand or misrepresent agile?
I still have mixed feelings about SAFe. On one hand, managers are happy because things are more predictable for them. But on the other, as a developer, I see it as multiple short waterfalls. Under all the processes, plannings and whatnot it is quite difficult to find time and fix our previous mistakes or improve now sub-optimal stuff. But that is just my experience :)
15:30 - the answer with SAFe is that when you ask, "What do we need?" - you should stumble on the bottom right, "SPC." That's the SAFe Practice Consultant, a service I've been offering for seven years, and it really depends on the agile competence of your SPC's, who can - by their advice and understanding - make or break agility in context. Good SPC's will understand agility deeply, and move towards continuous learning guided with experiences from things that work better or worse in other organizations in similar contexts. SAFe wasn't designed to work without someone who understands what agility is. But let's be honest - CD also won't work very well in a corporation where nobody understands what software development is.
Been there done that 😂. It is almost like telling war stories with beers. Traditional hardware focused companey discovers that they in reallity is selling software wants to become agile.
Ah classic, 'SAFe isn't bad, you just don't have the right consultant, why yes I happen to be that consultant'. Take your company ruining snake old and shove it. Parasite.
great line at 6:36 ff (and great explanation before) .. I don't want the flow to be predictable because if it's predictable then it means that I'm not learning anything and I'm not improving
Crowdsource request for nomenclature: how would you describe the list of items within an estimation report, which you could have done instead of planning them?
I feel a bit dumbfounded here. Admittedly, this may be due to my own lack of knowledge in these areas. But firstly, I don't understand the argumentation that organizations should prioritize CI/CD over SAFe. If you dig into the Built-in Quality area of SAFe, the framework agrees. They advocate both TDD, BDD and Continuous Integration. And as for the need for predictability, I see SAFe as a tool for transformation. The big companies (or Big-ish as the one I work for "only" have around 1200 employees) don't have the maturity to let everyone run rampant with their development. Each system is quite often fairly tightly coupled, forcing many changes to be done in synch. That kind of switch is much easier for small cooperations, as you will most likely be able to transition across the board in one fell swoop. Big corporations are not able to do that. Not easily anyway. They need to make the transition in smaller steps. I see SAFe as a tool for that transition, and I hope one day we will be able to ditch it entirely. But that won't happen until the applications developed in majority of the corporation have become much more mature, and it will be possible to actually practice Continuous Integration on each of them independently. Then and only then will we be able to make a leap towards actual agile software development. Or am I missing something here? :)
A very good point. Having mostly worked with legacy applications I agree with the problem you described. In favour of SAFe, it does introduce the concepts of being agile to the enterprises that had never heard it before. The problem lies in their approach to solve the problem with big teams. Instead of moving incrementally towards a more agile approach, it makes us feel good about where we are and encourages us to stay there by introducing a complex set of practices. I think that's where the criticism is mainly focused.
From my own limited experience, orgs are very willing to leave out the TDD, BDD, and CI parts under the "special snowflake" doctrine. Our project isn't like other projects and we just don't have time to do fancypants test automation when we have constant (largely self-imposed) deadlines. OTOH it's really important to have a bunch of backlog refinement meetings and other ceremonies that accomplish little of value, because that's supposedly where the Agile gets baked in. In fairness my experience is data engineering projects, which tend to declare special snowflake exemptions for any aspect of software development that might be hard. Set up a bunch of "Scrum" meetings where everyone's working on other stuff during the meeting? That's simple. TDD, BDD, and CI aren't. Your points are very valid and most orgs with the discipline to roll out TDD and CI will benefit, regardless of whether they consider it SAFe or Agile or just a bunch of good ideas.
Having worked in a SAFe environment in two different organizations for the past three years, I have come to most of the same conclusions. The challenge is the same as with SCRUM though. I've seen teams implement SCRUM "100% perfectly" but being 0% agile. The same I think holds true for SAFe. You can implement it 100% and be 0% agile. I do think however, that SAFe - when implemented with agility in mind - CAN help an organization transition to the level of SW development maturity necessary to truly be continuous. As Dave points out here, the continuous ideas and practices need to be kept in mind when implementing SAFe. Otherwise SAFe is just another disRUPtion (~_^) I think what SAFe really tries to do, is close the gap between the agile SW methodologie and the more classical management and financial roles in large organizations. SAFe tries to involve the kind of thinking prevalent in finance and controlling roles into the larger process. And if we are honest then we must admit that in agile development we cannot answer the what-when-how-much question that finance and management people want answered. OK, in traditional development our answers were mostly illusions as well. Whether a SAFe implementation is successful imho largely depends on the change in company level culture particularly on higher management, finance and controlling levels as well as the understanding, that SW development is a creative process and cannot be "industrialized".
It’s only possible to implement Scrum “100% perfectly” if you accept the slow creep of “adjustments” that have pulled it back toward waterfall. Perfect example: I’m old enough to remember when the “3 questions of standup” were the *starting* questions. Our trainers used to say, “if you’re still using these questions in a month, we’ve failed”. Yet today, everyone assumes that those are the correct questions to ask and ignore the fact that they’re very “status-y”. Someone then repeats, “Standup is not a status meeting!” without recognizing the incredible irony of what they’re saying. As a consultant, it just hurts to watch companies pretend to be Agile. They ask for my opinion and I highlight the gaps. They inevitably demonstrate “why they can’t do that” and ask for something else. I tell them it’s really just waterfall to do something else and they’re going to have to suffer the consequences. They say, “that’s the way it is” and keep on with their failure. 🤷♂️
4:50 Project predictability really just means hitting deadlines to most people. In practice, most software teams need to scale down to hit deadlines, since wants are infinite and time is limited. If you had 2 extra weeks and you got done early, there's always an infinite amount of extra work you could be doing, at least in my experiences.
Hey there, out of the subject, I'm wondering if you could make a video about the implementation of System Engineering with CI/CD, I got the feeling that the two concepts try to work together but they might be some incompatibilities
I saw first hand a department fall apart when this framework was implemented in our process. All solid contributors, myself included left after a few months. The week long meetings every quarter expedited that.
SAFe starts with a picture painted in agility. The framework says all the things that would make a small engineering team agile. There ends the good part, because then it goes after solving the problem of big teams, or multiple teams that needed coordination to release their software. That's where release trains come in the picture, which ironically derails the teams from the path to agility.
I think SAFe emerged as a compromise among all market players. Its like a win-win approach. The development teams is given a bit more agile for a saner work environment. The management is given back a reason to continue bloated. The consultants are given lots of opportunities to sell courses and consultancy. The specialists are given niches and feuds for task-oriented work. The owners are given 'predictability', 'control' and many beautiful reports. So everybody becomes happy. Nobody gets bothered with that real agile inconvenience. Everyone attached to ones believes, money flows, status quo remains preserved. What could be better?
For me personally every company which want to be more agile should put agile manifesto and principles on the wall and make people working there read it every day and have a though "are we really following these principles? What can we do today, next week to make it close to these principles?". No need for consultants, courses, certifications. Just read the manifest and try embrace it in your daily work. But I'm a dreamer
Did you address agile contracts on this channel? I hear people complaining about agile-washing all the time but ultimately what gives people incentives is how they get money and what they pay. Contracts are the way companies manage risk and in most cases people reach for something restrictive, a liability of result rather than a liability of means, and predictable or even up-front funding, when they write contracts, which leads them to hallucinate big plans with big figures and a precise list of features which need to be estimated precisely (if not accurately). You can explain over and over again that development can be done iteratively, the meaning of "iterative" will be unconsciously converted to "sequential" and "development" will exclude "design".
Below someone compares the predictability desired by orgs to the predictability of getting on an airplane knowing it will (usually) arrive (more or less) on time. To me it's more like assigning someone the job of dealing out poker hands until they make a straight flush. So you need "predictability"? A straight flush on one hand is about a 65,000:1 underdog. I can estimate how long it takes to deal 65,000 hands, add 20% for luck and daily standups and backlog refinement meetings (never mind, I can multitask) and company town halls. I'll probably meet the target, but that's a really bloated estimate, and I might still miss it by bad luck. (Real world meaning: the experiments I tried failed at a higher than expected rate, or a dependency failed at the last minute that I had no time allocated to mitigate, etc.) Instead, I should be focusing on efficiency. Can I get trained in how to pitch cards faster? Do the rules let me separate the red cards from the black cards? Can we throw out all the 2s through 6s from the deck? Oh, just the 2s, 3s, and 5s? That will certainly help. But I still can't tell you when the straight flush is coming. Maybe the next hand! (I.e., my next bolt of inspiration will be the good one.) If you trust me, you'll support me in making these improvements because you know I'm efficient at my job. If you don't trust me, you'll hector me for answers that don't exist in the form you're demanding. WE NEED OUR STRAIGHT FLUSH DEALT BY PI 19. CAN YOU GET IT BY PI 19? Maybe we're not tracking you closely enough in Jira. Let's put in five Jira tickets, one for each card we need completed.
I really think management believes in tools. Like a rich person who wants to solve everything with money because he/she lives in denial. Our org don't use safe because of the classical "we are too unique" for these kinds of things. Instead, we have big room plannings that last for 1.5 weeks, where "product owners", business owners, product managers and other celebs talk about which team should commit to which epic. Shoehorn everything where they can see 10/9 story point capacity. Devs can't say no, product owners are puppets and scrum masters are the jesters of this shitshow make them moderate and prepare these abominations w/o actually letting them make this thing work. This looks agile, looks like advancing and stuff... True agility costs money, and they reject everything that is not closely related to feature development in their eyes. Technical debts have a separate backlog, for example, that we all know is called "misc" or "noise" in the management's eye. We need time to maintain and develop our environment, too bad we are not allowed. It is not seldom they want quick fixes and workarounds to ship faster as "the customer is okay with our subpar quality". Few weeks ago everything started burning, and big time customers started complaining seriously. If you guessed that management points at the devs, you are right.
I'm with you. I've found if management doesn't support software maintenance and paying off tech debt, i either need to start doing 'shadow' refactoring (bundle paying off tech debt with new features without telling management) or start looking for a new job...
well said, I often see companies value predictability, and it gets achieved by large overestimations. and if you give people more time they will fill the time. of cause they will work on the thing, and maybe, because there is the excess of time, the time will be used, by adding more indirections in the code so that the project looks bigger and management can say look: we have so much software, the team is very productive,...
From software development perspective I'm very critical of SAFe, however I do understand that Agile completely disregards budgeting and company boards which need to make decision on which departments to invest. So it does found a way to introduce waterfall back into agile, otherwise agile devs people are running with scissors and disregarding that we live in a world with investors, marketing campaigns with deadlines etc.
Yet that isn't how other areas of business are organised is it? Businesses may have aspirations about when they will be profitable, gain market-leading status, grow to a certain head-count or even move to new premises, but unless people are childishly naive, they know that these things can't be perfectly predicted, why is the creation of software different? In every book on project management that I have ever seen, somewhere it says "you can't fix time and scope" and in nearly every org that I have seen what happens? The plan attempts to fix time and scope. This is NOT about marketing campaigns and deadlines, this is about irrational approaches to planning vs rational approaches. I choose the latter. Sure it would be nice and simple if we could fix time and scope, but we can't. Face this reality and pick which one matters, then fix that. CD means we can always deliver to a date, or work to a specific scope and deliver continuously, or wait for a certain scope. Either one works, attempting to fix both is a fantasy.
@@ContinuousDelivery in my case, the company has a new car model launch in China for Q1/2024, for that to happen we must deploy infrastructure there and have it working by that time to support a successful launch strategy with great user experience. I don’t know how else we could have done it expect to structure a plan with a timeline, mapping dependencies with other teams, descoping half a year of already prioritized topics., in short, a big waterfall project block. Had we not done it, there would be no basis escalating to upper management and request more budget to get it done in time. It could still fail and obviously It’s a rough map to get there with margin for change, but again, I’m not aware of other strategies to accomplish it. If there are I will be very eager to shift the company culture in that direction and get away from the waterfall to management crutch
Dont we need any kind of predictability? As a DBA and as a Scrum Master i need sum predictability to when new software will use my DB or changes to existing software to be able to match and assist if sumthing dose not work, or if we have decresed preformance. I have meet alot of developers that call up Operations 30 mins before they plan to do masive releases and expect our help and downtime on things that affects several other systems and then they get mad that we dont jump up and say ofcourse go for it. How can these two worlds meet if we can't have any predictability?
The true roots of the Agile approach laid in the desire to repair the "disconnect" between business and IT in enterprises (See Martin's articles and books about this). The goal of Agile was to involve the business in the everyday effort to deliver value in a project's product. So why not "scale" the approach from a project to the enterprise? As always, there is the practitioner disclaimer - skill levels vary, as well as the true intent of those involved, i.e., human nature; however, I have seen it succeed when an enterprise commits at significant levels. Agile itself was firmly in place at my organization; scaling it to the enterprise was a continuation of the emerging culture. No consultants were required.
While I have little experience in SAFe, I see that in different organizations it is consistently used as a way for management to reintroduce Waterfall. Which might be fine when Waterfall is the right model to use, but usually this is not the case. On the other hand there is some need for SAFe (although without this senseless complexity and bureaucracy): if Agile is TDD, SAFe is dependency manager. That said, the software developers' notion that "whenever it's done, it's done" and we don't need predictability, is also flawed. In my industry there are so many downstream dependencies until the software gets into customers' hands and so many things the customers need to do to roll it out internally, that you need a deadline to plan all this. The software delivery date is when the software is released to customers, not when the software is done in development. Agile itself is all about predictability while at the same time accomodating pivoting. Otherwise there's no point in sprints and storypoints.
Clearly, we watched two different videos. Dave expressly mentioned that agile is NOT! about predictability. I don't know where you get this notion that agile is about predictability.
It seems most companies practice Waterfall.. yet that is universally agreed to be the worse? For those companies not doing Waterfall, do they mostly use SAFe , SCRUM or the Kanban methodology (or framework) to implement their philosophy (AGILE/RUP/V-Model philosophy (SDLC))? I'd like to move away from a rapid-prototype environment to something more formal in order to develop high quality/safe products containing embedded software.. for ANY industry.. Aerospace (like Lockhead's SEAL Level X, Boeing , DDPMAS, DAL A to E etc) , Medical or Nuclear industries.. even Automotive. I imagine there are differences between the industries.. but I'd love to see a trivial project example that shows all the typical steps and outputs. FAA : DO-178X , DO 331 , ARP4754A , ED-12C FDA : 13485 , ISO14971 , IEC 62304 , SaMD and DOE Nuclear : 414.1x, (Automotive : 26262) For example, assuming I document the process on how the code is generated, what constitutes proof that it's safe? Static Analysis? Code Coverage - Statement (Level C), Decision (Level B), MCDC (Level A)? Who defines the unit tests? And what are the typical tools/software needed, and the typical document/artifacts in the various stages of the software life cycle? I saw a good video by CEMILAC Education Program "Airborne Software Development & Certification Process" and it's a bit overwhelming: Requirement Management - (IBM Ration) DOORS, JAMA, Xebrio, rmtoo florath , doorstop-dev / doorstop , reqview Static Structural Source Code Analysis - Parasoft, PolySpace, CodeSonar, horusec , SonarCloud, veracode PREFast, TBrun, LDRA Dynamic Analysis / Modified Condition/Decision Coverage (MC/DC) - VectorCAST, RapiTest Traceability Tools: Reqtify , Polarion , McCabe Configuration Management / Storage and Version Control System - Git, SourceSafe, Mercurial, MS TFS, ClearCase QA / ALM- Helix ALM for Managing Artifacts, Establishing Traceability, Documenting / Enforcing Processes, etc (I)V&V / Unit Test Automation - VectorCAST, LDRA Testbed , Mathworks Simulink DO Qualification Kit Continuous Integration / CD - Continuous Delivery/Deployment - Jenkins, Bamboo, or GitLab CI/CD And what is the general attitude towards open source software (ex. FreeRTOS) and code-generation tools (ex. ST's Cube MX)? Also, how do CPLD and FPGAs fit in to the embedded software picture.. since not exactly software nor hardware, since they are programmable devices written in an programming language like VHDL , (system) verilog , Amaranth HDL ? How would DO-254 apply to HDLs?
I've helped installing SAFe by interpreting it as a scaling of the SCRUM pattern to a team of teams (and team of teams of teams); for a team of teams, a quarter of a year is an iteration. There is a velocity for the team of teams, a retro etc. Reliability for me is as desired for a team of teams as it is for a single team, and a good tool to meet customers target dates, such as start of production in the car industry. From my point of view, it can be made to work very well, while (or because of) embracing core agile values. For me, the main benefit really is, apart from scaling a successful pattern in a fractal way, to split a large organisation into several, mostly independent streams (i.e., release trains), thus reducing complexity and alignment overhead between these parts of the organisation. It also is suited to break down huge endeavors into manageable chunks, using several layers of abstraction, where it's clear who is responsible for which abstraction layer.
I believe there is a witch hunt for SAFe that (I guess) unintentionally leaves out crucial elements that make SAFe "more agile". What made agile into a buzzword and eventually brought down NOKIA is bad implementation by unskilled consultants that don't know how to practice and measure agility. Same with SAFe, but with a different result - they make waterfall company become more agile. SAFe is most complete body of knowledge out there. Using it in other way than a guide is the problem. SAFe is reiterated based from experience from the field (seen it change according to what I experienced in the field), trying to understand its limits and faults and improve. It is definitely not "one glove fits all", same way you pick kanban or agile based on what makes most sense. Statement "being Agile is to embrace change" is just another way to make sure a consultant has a reason to stay with a company and is a crux of many implementation, as it is hard to understand the actually "how it is done" process wise.. as a consultant Ive never seen a full implementation of SAFe. And I never pushed for one, because it is a framework, not a methodology. Things people say it lacks it actually promotes, just adds a practice to help explain what it actually means. All the transformations are a process. Ive never seen an "enlightened" CEO transform a company in a whim. At least not in a large, international corporations. Change is gradual and encompasses many parts of the company with many sponsors and stakeholders. Yes, SAFe in a lot of them just "fixes" waterfall. For a while. but based on short term success, trust from sponsor, will to change and a skilled agile leadersip, with SAFe you can point at a practice, teach it to them and end up with an agile software unit that enables hardware or anything else. (and btw predictability focuses o value, not feature delivery).
This video cuts deep. I working at a company which have adopted SAFe more than 2 years ago and l can confirm it does not works. But. There is a but, it is still better than chaos which was before SAFe. The company is just not ready for pure agile way of working. The dysfunctional Scrum process was equally bad. SAFe can not work, simply because it is a mini waterfall and that did not work either. SAFe is too slow to react quickly enough to changes. So the plan goes out of the window after the first or second sprint (or iteration as SAFe calls it). Creating a full Program Increment plan which means planned work for 5 sprints, or 10 weeks is impossible. To many things can change in 10 weeks, and it has a huge administrative overhead. So by now, we ignore most of the SAFe processes. We make a very vague rough plan for a PI and a somewhat more detailed plan for the first sprint and see how it goes from there. On the other hand SAFe is not the enemy of continues delivery. Actually it has two release "models". One is the old school model, where somebody decides a date and content, based on feedback from the team and this is preferably is aligned with the end of a PI period. It follows the cadence of the release train. But an another concept or promise is the "release any time" so it is there. But it is hard when you can not release half-done features and your customers are slow in adopting new versions. Almost forgot my thoughts on speed. You never can be fast enough. No matter how fast you can deliver a feature, your managers will always demand more. One of the first questions is "how long will it take". Managers love predictability!
Most software development managers could vastly improve their success if they would follow two clear principles: (1) Prioritize bug fixes over new features, and (2) never make a promise about new features.
Helped? Well, the stock market and revenue numbers have a slightly different story. While most of SAFe companies, and companies in general don't like to talk about processes openly, there are some peculiar stories on Linked-in and "X" regarding SAFe.
safe for me killed creativity and flexibility for developers but allowed product/ sales teams to predict andfocus on only key features in a 8 week period. Fell into scrumfall. Needed bottomup solutions , not too down process /rules.
Biggest problem in SaFe is that requires organisation changes and people hate that. Especially managers. I have been part of implementing SaFe 2 times now 😂 Funny the things you mention about takes what works and remove what dose not. That works for Safe aswell The thing I like the most is PI planning because dependecies becomes clear for all teams. And sometimes people discover it during PI. But yes done wrong it is not Agile.
I've never worked in a SAFe environment but I love the idea of PI planning. This seems like an effective way to manage a just in time approach to managing change. The rest of the framework can likely go in the bin though. I've heard from a number of people that SAFe is meant to be done prescriptively where you follow the framework exactly. Not only is that not agile, it's a pretty ineffective way to run any enterprise.
PI Planning is a good aspect of SAFe if kept light weight. Having dev's think a little further than the next sprint brings benefits including more sustainable architectures and earlier notice of impending cross team dependencies. This is good. But there are lots of downsides if other stakeholders see PI planning as the vehicle to get 'Predictability'
@@keithalexander-buckley3708 Although... if you find that your developers aren't able to think beyond the next sprint then perhaps your developers just... you know... suck. And... you know... should be let go. :)
@@FudgeYeahLinusLAN 0:14 It is the knowledgesharing part in PI-plannings that seems to be the most useful part of SAFE. In addition SAFE may visualize dependencies between teams (but not sure about that). You cannot plan for both time and scope at the same time, as SW-development is so complex. Better instead to be better at what you do, e.g. by sharing knowledge .
SAFe is all about protecting useless middle management, when the best thing that could happen to middle management is to get rid of them. One of the biggest blockers to Agile is middle management.
it's not predictability of "outcome". it is the predictability of "inputs" that SAFe is addressing. it is trying to address the pain point of multiple layers and matrixes of the massively large organization not knowing WHAT the product they are building purpose/value/justification is... -no clear scope, no unit of measure of success, no single responsible point for the product. no outcome based definitions of success. SAFe depends on the PO and then has multiple layers stacked on top of the PO that have no idea whats gong on.
I work under SAFe and it's a nightmare. The only good thing is, all the good programmers left before I got hired because it sucks so badly, so I'm the best programmer in the entire project by far.
Yes!! After reading Accelerate, I think practices like continuous delivery are closer to Lean thinking than original agile. And Lean is all about reducing waste. There is so much waste in enterprise software development...
Of course it's safe. If you prevent change, you will never break things. But it will also slow you down. But I guess it can be good for companies that were just plain worse before it.
In general, business is very disturbed when the development team says it needs to learn things in order to implement a requirement. They are of the opinion that the dev team already knows how to implement it ("that's why they pay them" :)) so money ppl need only to know when it is going to be ready. Business doesn't care about iterations, continuous delivery or whatever methodologies we use - they need to know how much it cost them and when it can be delivered. Telling them we don't know how much it cost them or when it is ready is simply not acceptable for business. And I am not sure we can change that world view.
"Iteration, adaption and agility" are not possible when each cycle costs your the better part of $1M. Such as in a highly regulated hardware industry. Nevertheless, we have Agile forced on us.
6:00 - that's the typical misunderstanding of what "predictability" is which many technical folks have, and which is why "Agile" for a long time wasn't being taken seriously in management circles. If you buy an airplane ticket to be in Los Angeles to arrive just on time for the 4th of July festives - do you want to hear, "I can't tell you when the airplane is going to come, but we're working on it, and improving our efficiency so it comes faster?" No. You want your airplane to board at full noon on 3rd of July, not an hour earlier or later. Enterprise level predictability isn't talking about details. There are a lot of major activities, such as marketing campaigns, B2B contracts, potentially even fines or lawsuits, hinging on not meeting a specified timeline. And of course, managers want to know if they need to mitigate something, or whether they can sit back and say, "I trust you folks, you got this, get on with whatever you're doing, you're the experts." If an airline can't give a straight answer to the question, "Will the airplane board on 3rd of July, 12 straight - yes, or no?" - they shouldn't be in business. If your airline would say, "Well, we're not working on predictability, instead we're focusing on boarding passengers in small batches ..." - you'd probably run away screaming and find another airline.
But is the airplane problem an already solved problem or something we need to learn how to solve? To continue on the traveling metaphor, imagine you are the first Spanish sailor that will try to go to India. Do you care about predictability or efficiency? You can have some plan, of course, but efficiency and antifragile to unknown difficulties are more important aspects. If you are the second sailor, now you can be slightly more predictable, but only a bit. if you are the third.... So on and so fourth until we have 100 years of aviation and we get predict to the minute when we gonna arrive. Software people rarely are the first sailors, but hardly we are airplane pilots. We tend to be way more closer to the sailors - after all, copying software is costless and small changes are cheap; we are more important when we need to be more as the sailors. And the Agile Manifesto for **Software Development** (not for Airplane Piloting) aims at these problems: Small teams working interactively to solve a problem
this is apples and oranges, in my opinion. you don't buy a plane ticket to fly on a plane that isn't even conceived of yet. you buy a plane ticket for a plane that has gone through years of r&d, calibration, stress testing, etc. so that you have the privilege to one day fly on them on demand with the confidence that it won't go up in a ball of fire. and for some reason when we try to say "this system will take research and iterative improvement" in the context of software, people balk, when in fact in the very example of an airplane, all that time and effort of an analogous continuous learning LEAN manufacturing process is obscured from you the passenger because no one in their right mind would try to promise you a seat on a nonexistent model of airplane.
You're missing the point: Software Engineering is solving problems nobody has solved before. If it was solved already, you can just download and use it. That's why "build my website" jobs tend to be more predictable than "make this car drive itself". We successfully did thousands of airplane flights so we can plan and repeat the same thing we know how to do. Nobody told the Wright Borthers they got 3 months to finish this people flying for the first time thingy.
SAFe at my company feels like waterfall but without the artifacts from the analysis and design phases. It is the worst of both worlds - the poor foresight of agile and the brutal, slow busywork of waterfall.
SAFe is not the goal, rather an interim step toward Agility, eventually not to use it anymore. Reality is organizational agile latency is very low, hundreds of teams don’t have alignment by default, architectural evolution takes years to modernize, political boundaries prevent collaboration, technical agility takes effort to cultivate, don’t forget the fluctuations in organizations, they all play the role of why SAFe is adapted. I disagree SAFe don’t inspect and adapt, because at each iteration, teams do inspect and adapt through retro and every PI Planning there's problem solving workshops
Scrum is a scam thats done at team level, but SAFe takes it to the next level where the fraud is committed at an Organisation level. Hence the term scaled agile.
I completely disagree with Dave! He should see the SAFe a bit more closely for those use cases when an enterprise is in question, that the whole ladder has to change starting and coordinating from TEAM, PROGRAM, SOLUTION and PORTFOLIO of multiple products. It is the management that allocates the FUND for the whole exercise. When I worked as a developer, Agile/Scrum and other developer-centric things were the only important things. But the developers are/were themselves a toxic community, not delivering anything Management needs or wants to have. All others were sub-standard people. The developer-centric worldview! Today in the cloud world, non-functional requirements decide the software architecture and software developers are key but a small part (1/3) of the whole story... Cost-effectiveness, Scalability, HA and Performance in the cloud are the key drivers, that finally trickle down to design to manage the complexity that we all know like Modularity, Cohesion, Separation of concerns, Abstracting, Design for testability We have today a no-code paradigm, IoT. The developer in him urges him to get rid of any control that management wants. The developer didn't know CI/CD before he and Jez wrote such a great book. Developers have inertia and cognitive limitation in seeing beyond the developmental challenges. When we worked in a team of TEAMs of more than 130 people SAFe was absolutely needed, and I know SAFe pretty well.
SAFe is more like a bizarre combination of plagiarism from Toyota,, Lean manufacturing, some engineering and redundant less commonly used words in their vocabulary ( kind of too much blah lah marketing) and re-inventing the wheel, very expensive, paradoxically slow, and a huge waste. Unfortunately consulting firms take advantage of the marketing to convince clients and “sale SAFe consultant resources” the results > bureaucratic way of working very expensive and a never ending story
"Agile" works fine if you only need 1 team and there are zero dependencies the team cannot solve itself. Beyond that "agile" falls short. And when things get complex that's exactly when we are in dire need for methods, tools and processes to help us build (and maintain) those large complex systems with dozens of teams, that have many dependencies with other systems, teams, departments and (outside) organisations. When things are simple and small, you don't need much support, and "agile" is probably enough to fix the problem. Scaling agile is not so much about agility, it is about all the things you need to build large complex systems. And yes, that will mean you will loose some of that agility. Agile looks a lot like software development in the early days by the way, when there was little specialization and everyone did analyses (talk with user), design, coding, testing and documentation (T-shaped profile :--). The software industry has come full circle?
The idea that predictability is bad because we are going to learn so much so fast that our velocity will increase a lot during the course of the project is just fantasy. That might be true for new grads figuring out how to use source control, or for teams made up of developers who don't have any experience in the tech stack they are using. But not for teams with senior developers and architects.
The problem is not the idea or frameworks or whatever people want to call it, the problem is people learned to do things a wasy and that’s their way.Also all of these blah blah “frameworks” are bizarre creations from people who wants to make money out of ignorants. The idea of Agile was for the developers to have a said in the execution of a project, but people in business kept having the ideas that business has the said on how to do things…hence the forever bizarre way of working …the business way! A bizarre hybrid of agile scrum lean safe and whatever else
SAFE is not agile! Dean, whatever his name should just accept reality and call it another methodology why because tell how planning for the next 5 sprints aligns with the agile manifesto or the 12 principles of agile?Not to mention what an utter waste of time it is to gather everyone in a 2-day long meeting. And moreover, after all that marathon of the planning sessions, it adds no value as soon a teams 2 sprints in cannot adhere to the PI plan.
🎓 Learn how to work as a highly functional software development team using highly sought-after modern software engineering practices with my online courses. Particularly this one 'Better Software Faster' ➡ courses.cd.training/courses/cd-better-sw-faster
Unable to open the link. It only shows "Forbidden" text on the page.
@@SufianBabri Well I don't know why, I guess that is a firewall problem at your end, the link is correct. You could try the home page of my training site here: courses.cd.training
But if the first doesn't work for you, this may not either
@@ContinuousDelivery It seems to have resolved now.
Back when I reported, neither the home page, nor the course URL was opening, not even with Tor Browser.
I've personally worked in two separate orgs that were brutalized by SAFe consultants, resulting in mass layoffs or turnover. My experience was so horrible that I've since made it clear to every new manager or PM I have that the moment the company brings on a SAFe consultant or begins trying to implement anything that looks like a 'release train' is the same moment my next job search begins. SAFe is literally the meme of spending more time moving jira tickets around than writing code or building products except explicitly codified in processes that span the whole IT org with a handful of dev managers and product owners empowered to enforce the processes at all costs. Its no mistake that every one of those people who were given that authority went on to become SAFe consultants themselves.
Sorry to hear you had terrible experiences with SAFe consultants.
I've worked with a number of tremendous SAFe consultants and trainers, although I'm more than aware that there are also those whom I would advise to never let anywhere near an organization - some of whom I have also met, and had to fix the mess they caused.
I wrote about the problem of bad SPC's back in 2019 - failfastmoveon.blogspot.com/2019/09/why-spc-will-destroy-safe.html
The problem are not SAFe consultants but SAFe itself. There are no good SAFe consultants as there is no good SAFe
@@thought-provokerSAFe itself is garbage.
These consultants stroke the egos of the existing mgrs and wedge their way in. Then you are left with a hybrid of some safe agile and some of the worst traits of the leftover mgt practices that makes it hell on the creators.
The waterfall is not dead. Every day it rises from the ashes, but now in the form of agile-waterfall, whenever someone says "we need to improve our estimates".
Dave, thank you so much for sharing this. Your book is awesome!
I wouldn’t touch SAFe with a ten-foot pole. Shitty Agile For Enterprises is an acronym that makes a lot of sense.
SAFe is for a few of things:
(1) Sell certification
(2) Keep project managers in jobs
(3) Give senior management warm fuzzies that they have "implemented agile"
When you look at the SAFe diagram, dev and engineering teams are somewhat diminished with the ART etc taking priority and the customer is an afterthought.
You could say the same thing about XP, Kanban, scrum, etc.
I disagree and think you're missing the whole point of SAFe. An organization that applies agile top to bottom develops common WBS patterns and vocabulary that are easy to understand co. wide The alternate is that team level agile and upper management waterfall practices collide and have to be translated. Managing this junction point takes a lot of energy and resources from the organization.
Agile is an adjective, not a verb or a noun, but yes I agree with you. :D
From a systems perspective, SAFe® is successful as a framework to be sold because it keeps the social system of the middle management in place, as described by the Larman's law. The system would usually try to keep itself alive by reacting to any change in its environment accordingly.
SAFe® seems to be the safest way for this system to preserve itself why addressing stakeholders' demand for agility.
One thing that SAFe has been good at is giving me cover to introduce more agile methods to our process. We are definitely not fully there because that is just too much stuff to change quickly but our processes keep getting better over time and our results continue to improve.
That is the true goal of agile, continuous improvement over time.
Very good point! SAFe (when implemented correctly and with agility in mind) should do just that.
Thanks. Very important perspective here. I'm pretty SAFe-skeptical for 90% of the orgs that roll it out but I do like to hear the counterpoints and success stories. Bless you for doing yeoman's work.
One thing to remember about SAFe is that in order to get certified you have to go on a training course given by Scaled Agile Inc. This company must be making money hand over fist by selling training courses to enterprises, which is probably the main reason for inventing SAFe.
It's a pyramid scheme for sure.
3:25 I'm a hardware engineer, whose company decided to adopt SAFe, pushed by the software team. There is absolutely a doubt for me as to whether "true" Agile methods work better than SAFe or Waterfall. It really depends on the task at hand. Hardware isn't software. Hardware has unique challenges, and there are different types of project. Waterfall works pretty well for hardware, especially if you give some loosely planned exploratory time at the start of a project. The number of times I've been told by software engineers to just break down my 12 month, multidisciplinary, hardware deliverable, into irrelevant 2 week "sprint goals" just shows me that most people pushing Agile have no idea about what hardware design needs, nor do they care.
Once you are leaving the field trivial CRUD apps and web development, the two-week sprint cycle becomes also completely irrelevant.
@@Ikbeneengeit you could take a larger hardware project that requires say more upfront planning, and divide it into smaller deliveries that could fit in a sprint. I believe this would create good cadence and keep the project humming along. It requires a good scrum master to elicit and document the sub steps from the team at planning. Consistent delivery is a good thing, as is breaking down the big rocks IMO.
The reason they want predictability is because they want to to be in total control. They want to know exactly what will be produced, by exactly when.
Successful companies have long moved past that, they now instead seek out business opportunities, and they then hire a motivated technical team to pursue those opportunities. They give up control of "what" and instead trust and enable the technical teams instead to work out what the best technical thing to pursue is in order to the advance the objectives.
Early on in Agile, the true successes came because management and executives who used to hold iron grips on timeline and scope relaxed scope while holding onto timeline. These days truly successful companies also give up control over timeline as well to the technical teams: they do the business research, and then present to the technical teams the question of whether it would be appropriate to put in more technical effort and delay market releases. They also do the business work of checking whether the market is ready for them, whatever state their technical code is: sometimes the same product will be more successful if you delay it for more favorable business conditions.
Fantastic video Dave. So... to me, at least, Agile has lost it's way. Back in the day, early 1980s, we were moving from waterfall to RAD (now Agile). This was made more formal with the advent of DSDM in 1995. I gave my first DSDM course in March of that year. I ran quite a few RAD projects and we did deliver better software faster. At the very least we built something that was acceptable to meet the business need when it was needed by the business. After having no contact with software development for almost twenty years, (well I am retired!) I am dismayed that people are talking of going back to waterfall as a 'new' generalised approach (That said waterfall is still useful for those projects where the requirements are unfuzzy). As for SAFe... the mind boggles! Keep up the good work Dave!
I just had my first experience with SAFe this past year. It was a complete train-wreck. Basically, they took practices from waterfall, gave them agile-sounding names, and pretended they were agile.
This is obviously just my anecdotal experience, but I did a bit of research after encountering SAFe. I was baffled that any company worked this way in 2022, and I thought that surely it must just be a poor implementation of the methodology. But the more I looked into it, the more I found people with similar experiences. SAFe is clearly snake-oil.
Similar experience for me, it went so poorly that the company outright bought its competitor and laid off every dev/qa/analyst in the release train. Ironically all of the dev managers and PMs that pushed for SAFe left to become SAFe consultants themselves.
I'm pretty sure this is the modal usage mode of SAFe: "took practices from waterfall, gave them agile-sounding names, and pretended they were agile." That's both based on personal experience and asking around. I like that Dave gives at least some credence to the view that it's a step toward Agile, and I'm sure some practitioners do a great job of using it that way. They're probably the folks who would thrive regardless of methodology.
Anyway, don't go running out of a job interview if they say they use SAFe, but absolutely spend your own question time asking *how* they use it.
@@PhilipJReed-db3zc I won't necessarily flee SAFe, but based on this experience I will ask some pointed questions from potential future employers. In particular, I'll be asking what sort of feedback the development team has given on product design, and how that feedback was integrated into the product. I think that will help me to determine if this is an organization I want to work with.
@@PhilipJReed-db3zc unless the situation is literally that the org had no formal sdlc practices prior to trying safe I would have absolutely no reservations about walking out of an interview upon learning they use it. Even then I'm not necessarily convinced that safe is better than nothing, my experience with it has been that bad.
Don't you mean it was a complete release-train wreck?
Predictablility is still required by the "money owners" because they have budgets, and they answer to executives about the ROI related to periodic (eg quarter steering) meetings. Honestly, and unfortunately, I have never worked for any company whose executives do not complain about money "spent" on errors, also, that's why many of these companies contract outsourcing consulting companies, since they don't consider development as core business and basically they transfer the risk to the consultant company - demanding "excellence from Mark 0". How to deal with it?
Unfortunately, that's the firefighter's problem: You never get praise for a fire that never happened, but you become a hero for rescuing someone from an inferno.
With good agile practice, we spend a bit of money to prevent a lot of risk. With bad development practice, we spend a lot of money and incur the risk so far down the line that everyone will try to report it as at least a partial success, because it would be too expensive to call it a failure. I've personally witnessed $100m+ development projects deliver literally nothing except a document.
But with agile ways of working, we will make a lot of small bets and constantly account for them. And a lot of those small "errors" will show up as "wasted expenses" in the books. Whereas those multimillion dollar projects that deliver nothing ... will show up as CapEx somehow.
It's an accounting issue. A guy named Daniel Doiron wrote a great book about how to change executive financial mindset.
@@thought-provoker Years ago I was in department meeting while the department head was handing out the "Firefighter Awards." A co-worker/friend leaned over to me and whispered, "Some of those firefighters were the arsonists too."
Yeah, same here. No one wants to predict from the ever growing pile of stories, but wants to know when "Feature X" will be out the door, whether it is something the customer wants or not.
The best way to deal with it is to completely destroy this status quo
Unfortunately I don't think anyone is ever going to find a solution for bad management :) Lean thinking managers don't behave that way, but seem to be few and far between.
I was a solution architect in a SAFe project at a large company. It was the first time they did something like this and they shoehorned SAFe, Agile, SCRUM and DevOps into this massive project and expected wonders like less headcount since the developers would do Ops-stuff (wrong) and full control and cost predictability like in a waterfall project. And the rest of the organisation was not like this at all... so when we needed changes in the communications infrastructure for a feature, we had to wait for two weeks while that team worked their waterfall process.
Barring all the other things that happened, I got turned of SAFe rather profoundly when I started to read about how it was supposed to work and how it didn't. Artefacts there needed to be produced but never went anywhere and a disconnect with the developers not supposed to talk to me and me to them unless it is cleared with a manager. Overall, at least they way it was implemented we had more managers on the projects than people actually doing anything. Four developers, one architect, three Business Analysts, three Program Owners, two business liasons, three project managers and scrom masters and two lead managers. Totally mad. So when I see SAFe these days, I try to steer clear.
Reading that roster of roles nearly triggered a sympathetic panic attack in me. Had to remind myself that I was not going to be one of those four unlucky developers. That is a cruelty I would not wish upon a sworn enemy, much less something I'd want to be involved with myself. I can only imagine the constant scope creep, shifting and conflicting requirements, neverending demands for ETAs and status updates, and absurd deadlines that inevitably lead to mountains of technical debt and resulting nightmare, unsupportable codebase.
I worked for a company recently that is heading towards SAfE, though not fully implementing each practice like release trains. It was something that management loved but lead to poor software:
- it gave middle and senior management a feeling of control and planning via story point tracking and increment breaks, but disconnected teams so much from customers that we had no idea if we were delivering value
- team composition and ways of working were set by middle management, with a facade of delegation to teams (who had only limited freedom to decide how to implement features)
- because of the hierarchy, although we had cross functional teams we had only one ops expert in the whole division (~50 people) and no one was incentivised to take ownership of system maintenance/support
- the central planning/control also led to chaos when a critical system went down, but developers weren't given access or support to either help with the outage or build workarounds (my colleague and i were expressly forbidden from working on other ways of testing - so our entire team couldn't test any code for 5 weeks)
Uggh, i think i'd rather deal with waterfall 🤣
I’m with you. I’d rather deal with waterfall than SAFe.
I think your point about implementing ALL of it is totally valid. I've used - and I still am - parts of the SAFe implementation plan in order to enact change in the organisation. Once we reach a tipping point and start looking to develop a vision and strategy however, we look for what works for us. We use some ideas from the framework - empowering employees, generating short-term wins, consolidating gains and producing more change - but we don't tie ourselves to their solution. Why would we, we're not them. Their framework appeals to C level management and has allowed me to drive change across the organisation, but we went with the ground up discovery of what will work here.
My feelings about why SAFe was introduced in my company was that we have been (very) late on delivering on time what was written in a customer conract in the first place. And we do a lot of extra work that I think is just for the sake of numbers and some fancy figures for the management. We are about 150 developers and close to 100 non-developers in "management" roles. That may tell a lot on what happens when SAFe kicks in.
Since I don't work yet, do you think managers feel more "safe"? They clearly had emotional rollercoasters with late deliveries, do they feel better now?
This is a good point, management likes control because they are reacting from trauma from past projects gone bad. But it's like someone who's overweight eating chocolate to forget about their sadness from being overweight... it's a vicious cycle
@@theodorealenas3171 I think they feel different now. But there still is a strong request on features to be delivered in time. In addition we are not allowed to deliver a "Program Increment" without a new feature. It feels wrong to work this way. I hope we (as developers) can insist to adapt to a higher efficiency.
Ah, the full agility of producing a product that is described in a legal contract...
Projects rarely suffer from something where SAFe has a solution to offer. These agile coaches are usually nice people, but they are often detached from actual software development and any code for over a decade (or are fresh from university) and never implemented code themselves in an agile project. And for some reason they think, that if SCRUM is just organized enough and religiously followed enough, high software quality and high speed is achieved, but SCRUM doesn't care about quality at all. It's often a Cargo Cult.
I can't take SAFe serious anyways since i'm a certified SADMF (scaled agile devops maturity framework). If i just hear "release train", i ask: "isn't a release convoy better?"
Just today my company pushed SAFe and an agile coach into my new (greenfield) project and the talk about release trains started within 10 minutes not because we need it but because a manager likes it. So once again i have to convince people to not slow us down with waterfall milestones, processes, branching concepts etc. It's completely unnecessary for our backend services, which will be fully tested automatically after each commit, canary released and automatically monitored. So basically we ignore SAFe as much as we can, but will be part of another SAFe success story.
Is SADMF a real thing? It does work as a joke... Three letters - two letters
In SAFe training they mostly talked about using agile for everything except code. If they only targeted code they would not sell as many organizations on it.
I don't know anything as big as safe can be called "agile". We called it the Fragile model. The only people that liked it were senior managers and those who wanted a career as SAFe coaches etc...
SAFe does have some advantages for larger enterprises. I work for a company that has about 40 agile teams, about half on the backend, and the rest on device software. Previously the teams would all individually move faster... but wouldn't be organized, so enterprise level features (multiple device teams + multiple backend teams) could take a LONG time to "get to market".
SAFe let us get the backend teams to work on the features that were important this quarter (program increment) so the backend development would complete more quickly.
Here's an imperfect analogy-- your company sells cars, and your sales team just won a big contract to make one of the models of cars go faster.
Pre-SAFe: The engine team runs with this immediately. At the end, they ask the wheel, brake, and suspension teams how they're going. The other teams go... what? We have our own priorities, maybe we can get to that next quarter. After a year, everyone gets their act together, the feature is tested, and then the cycle repeats to deal with the multi-subsystem bugs.
Post SAFe: In PI planning, upper management tells us that the "speed" feature is a priority. Prior to the PI, the architects realized that the engine, wheel, brake, and suspension would need updates. During PI planning (ideally beforehand) they estimate their portion, and that capability is part of their backlog for the PI. The feature (including engine, brakes, wheel, and suspension) is tested end to end. There a less bugs found, and the one found are easier, because we're fresh off implementation-- we don't have to review the parts from scratch.
So... SAFe means that individual teams don't get to work on as many of their priorities, it means that big features that our customers are demanding are available to customers sooner.
It's amazing how many so called software development improvement practices were created to make non technical management feel comfortable due to their lack of understanding or desire to understand fine grained requirements, while preferring a cloud 50 foot view.
For me, I noticed the website promotes going faster as a primary goal of SAFe. However, going faster is not a primary goal of agile, rather it is a by-product of everything else we do. Fast and agile aren't synonyms. Very few people would describe Usain Bolt as agile yet I'm sure everyone has described him as fast. So for me does the sites misunderstand or misrepresent agile?
I still have mixed feelings about SAFe. On one hand, managers are happy because things are more predictable for them. But on the other, as a developer, I see it as multiple short waterfalls. Under all the processes, plannings and whatnot it is quite difficult to find time and fix our previous mistakes or improve now sub-optimal stuff.
But that is just my experience :)
15:30 - the answer with SAFe is that when you ask, "What do we need?" - you should stumble on the bottom right, "SPC." That's the SAFe Practice Consultant, a service I've been offering for seven years, and it really depends on the agile competence of your SPC's, who can - by their advice and understanding - make or break agility in context. Good SPC's will understand agility deeply, and move towards continuous learning guided with experiences from things that work better or worse in other organizations in similar contexts.
SAFe wasn't designed to work without someone who understands what agility is.
But let's be honest - CD also won't work very well in a corporation where nobody understands what software development is.
Been there done that 😂.
It is almost like telling war stories with beers.
Traditional hardware focused companey discovers that they in reallity is selling software wants to become agile.
Ah classic, 'SAFe isn't bad, you just don't have the right consultant, why yes I happen to be that consultant'. Take your company ruining snake old and shove it. Parasite.
great line at 6:36 ff (and great explanation before)
..
I don't want the flow to be predictable
because if it's predictable then it means
that I'm not learning anything and I'm not improving
Crowdsource request for nomenclature: how would you describe the list of items within an estimation report, which you could have done instead of planning them?
Could you speak more about these fitness function ?
I feel a bit dumbfounded here. Admittedly, this may be due to my own lack of knowledge in these areas. But firstly, I don't understand the argumentation that organizations should prioritize CI/CD over SAFe. If you dig into the Built-in Quality area of SAFe, the framework agrees. They advocate both TDD, BDD and Continuous Integration. And as for the need for predictability, I see SAFe as a tool for transformation. The big companies (or Big-ish as the one I work for "only" have around 1200 employees) don't have the maturity to let everyone run rampant with their development. Each system is quite often fairly tightly coupled, forcing many changes to be done in synch. That kind of switch is much easier for small cooperations, as you will most likely be able to transition across the board in one fell swoop. Big corporations are not able to do that. Not easily anyway. They need to make the transition in smaller steps. I see SAFe as a tool for that transition, and I hope one day we will be able to ditch it entirely. But that won't happen until the applications developed in majority of the corporation have become much more mature, and it will be possible to actually practice Continuous Integration on each of them independently. Then and only then will we be able to make a leap towards actual agile software development.
Or am I missing something here? :)
A very good point. Having mostly worked with legacy applications I agree with the problem you described. In favour of SAFe, it does introduce the concepts of being agile to the enterprises that had never heard it before. The problem lies in their approach to solve the problem with big teams. Instead of moving incrementally towards a more agile approach, it makes us feel good about where we are and encourages us to stay there by introducing a complex set of practices. I think that's where the criticism is mainly focused.
From my own limited experience, orgs are very willing to leave out the TDD, BDD, and CI parts under the "special snowflake" doctrine. Our project isn't like other projects and we just don't have time to do fancypants test automation when we have constant (largely self-imposed) deadlines. OTOH it's really important to have a bunch of backlog refinement meetings and other ceremonies that accomplish little of value, because that's supposedly where the Agile gets baked in.
In fairness my experience is data engineering projects, which tend to declare special snowflake exemptions for any aspect of software development that might be hard. Set up a bunch of "Scrum" meetings where everyone's working on other stuff during the meeting? That's simple. TDD, BDD, and CI aren't.
Your points are very valid and most orgs with the discipline to roll out TDD and CI will benefit, regardless of whether they consider it SAFe or Agile or just a bunch of good ideas.
Having worked in a SAFe environment in two different organizations for the past three years, I have come to most of the same conclusions. The challenge is the same as with SCRUM though. I've seen teams implement SCRUM "100% perfectly" but being 0% agile. The same I think holds true for SAFe. You can implement it 100% and be 0% agile.
I do think however, that SAFe - when implemented with agility in mind - CAN help an organization transition to the level of SW development maturity necessary to truly be continuous. As Dave points out here, the continuous ideas and practices need to be kept in mind when implementing SAFe. Otherwise SAFe is just another disRUPtion (~_^)
I think what SAFe really tries to do, is close the gap between the agile SW methodologie and the more classical management and financial roles in large organizations. SAFe tries to involve the kind of thinking prevalent in finance and controlling roles into the larger process. And if we are honest then we must admit that in agile development we cannot answer the what-when-how-much question that finance and management people want answered. OK, in traditional development our answers were mostly illusions as well.
Whether a SAFe implementation is successful imho largely depends on the change in company level culture particularly on higher management, finance and controlling levels as well as the understanding, that SW development is a creative process and cannot be "industrialized".
It’s only possible to implement Scrum “100% perfectly” if you accept the slow creep of “adjustments” that have pulled it back toward waterfall. Perfect example: I’m old enough to remember when the “3 questions of standup” were the *starting* questions. Our trainers used to say, “if you’re still using these questions in a month, we’ve failed”. Yet today, everyone assumes that those are the correct questions to ask and ignore the fact that they’re very “status-y”. Someone then repeats, “Standup is not a status meeting!” without recognizing the incredible irony of what they’re saying.
As a consultant, it just hurts to watch companies pretend to be Agile. They ask for my opinion and I highlight the gaps. They inevitably demonstrate “why they can’t do that” and ask for something else. I tell them it’s really just waterfall to do something else and they’re going to have to suffer the consequences. They say, “that’s the way it is” and keep on with their failure. 🤷♂️
I don’t see how you could ever implement SAFe in an agile manner.
4:50 Project predictability really just means hitting deadlines to most people. In practice, most software teams need to scale down to hit deadlines, since wants are infinite and time is limited. If you had 2 extra weeks and you got done early, there's always an infinite amount of extra work you could be doing, at least in my experiences.
I can only think of one single word as a response to this video: amen!
Hey there, out of the subject, I'm wondering if you could make a video about the implementation of System Engineering with CI/CD, I got the feeling that the two concepts try to work together but they might be some incompatibilities
I saw first hand a department fall apart when this framework was implemented in our process. All solid contributors, myself included left after a few months. The week long meetings every quarter expedited that.
Please explain how agile is a verb. Isn't it an adjective?
Yes, I mis-spoke. 🫢
@@ContinuousDelivery all good. Btw I'm inspired by your talks. Thank you thank you thank you.
SAFe starts with a picture painted in agility. The framework says all the things that would make a small engineering team agile.
There ends the good part, because then it goes after solving the problem of big teams, or multiple teams that needed coordination to release their software. That's where release trains come in the picture, which ironically derails the teams from the path to agility.
I agree, but *agile is an adjective* not a verb. Other than an activity it displays an attitude.
As a developer I absolutely hate SAFe. And I'm falling out of love with Agile too
SaFE is just quarterly waterfall.
I think SAFe emerged as a compromise among all market players. Its like a win-win approach.
The development teams is given a bit more agile for a saner work environment. The management is given back a reason to continue bloated. The consultants are given lots of opportunities to sell courses and consultancy. The specialists are given niches and feuds for task-oriented work. The owners are given 'predictability', 'control' and many beautiful reports. So everybody becomes happy. Nobody gets bothered with that real agile inconvenience.
Everyone attached to ones believes, money flows, status quo remains preserved. What could be better?
For me personally every company which want to be more agile should put agile manifesto and principles on the wall and make people working there read it every day and have a though "are we really following these principles? What can we do today, next week to make it close to these principles?". No need for consultants, courses, certifications. Just read the manifest and try embrace it in your daily work. But I'm a dreamer
Did you address agile contracts on this channel? I hear people complaining about agile-washing all the time but ultimately what gives people incentives is how they get money and what they pay. Contracts are the way companies manage risk and in most cases people reach for something restrictive, a liability of result rather than a liability of means, and predictable or even up-front funding, when they write contracts, which leads them to hallucinate big plans with big figures and a precise list of features which need to be estimated precisely (if not accurately). You can explain over and over again that development can be done iteratively, the meaning of "iterative" will be unconsciously converted to "sequential" and "development" will exclude "design".
Below someone compares the predictability desired by orgs to the predictability of getting on an airplane knowing it will (usually) arrive (more or less) on time.
To me it's more like assigning someone the job of dealing out poker hands until they make a straight flush. So you need "predictability"? A straight flush on one hand is about a 65,000:1 underdog. I can estimate how long it takes to deal 65,000 hands, add 20% for luck and daily standups and backlog refinement meetings (never mind, I can multitask) and company town halls. I'll probably meet the target, but that's a really bloated estimate, and I might still miss it by bad luck. (Real world meaning: the experiments I tried failed at a higher than expected rate, or a dependency failed at the last minute that I had no time allocated to mitigate, etc.)
Instead, I should be focusing on efficiency. Can I get trained in how to pitch cards faster? Do the rules let me separate the red cards from the black cards? Can we throw out all the 2s through 6s from the deck? Oh, just the 2s, 3s, and 5s? That will certainly help. But I still can't tell you when the straight flush is coming. Maybe the next hand! (I.e., my next bolt of inspiration will be the good one.)
If you trust me, you'll support me in making these improvements because you know I'm efficient at my job. If you don't trust me, you'll hector me for answers that don't exist in the form you're demanding. WE NEED OUR STRAIGHT FLUSH DEALT BY PI 19. CAN YOU GET IT BY PI 19? Maybe we're not tracking you closely enough in Jira. Let's put in five Jira tickets, one for each card we need completed.
I really think management believes in tools. Like a rich person who wants to solve everything with money because he/she lives in denial.
Our org don't use safe because of the classical "we are too unique" for these kinds of things. Instead, we have big room plannings that last for 1.5 weeks, where "product owners", business owners, product managers and other celebs talk about which team should commit to which epic. Shoehorn everything where they can see 10/9 story point capacity. Devs can't say no, product owners are puppets and scrum masters are the jesters of this shitshow make them moderate and prepare these abominations w/o actually letting them make this thing work.
This looks agile, looks like advancing and stuff...
True agility costs money, and they reject everything that is not closely related to feature development in their eyes. Technical debts have a separate backlog, for example, that we all know is called "misc" or "noise" in the management's eye. We need time to maintain and develop our environment, too bad we are not allowed. It is not seldom they want quick fixes and workarounds to ship faster as "the customer is okay with our subpar quality". Few weeks ago everything started burning, and big time customers started complaining seriously. If you guessed that management points at the devs, you are right.
I'm with you. I've found if management doesn't support software maintenance and paying off tech debt, i either need to start doing 'shadow' refactoring (bundle paying off tech debt with new features without telling management) or start looking for a new job...
well said, I often see companies value predictability, and it gets achieved by large overestimations. and if you give people more time they will fill the time. of cause they will work on the thing, and maybe, because there is the excess of time, the time will be used, by adding more indirections in the code so that the project looks bigger and management can say look: we have so much software, the team is very productive,...
From software development perspective I'm very critical of SAFe, however I do understand that Agile completely disregards budgeting and company boards which need to make decision on which departments to invest. So it does found a way to introduce waterfall back into agile, otherwise agile devs people are running with scissors and disregarding that we live in a world with investors, marketing campaigns with deadlines etc.
Yet that isn't how other areas of business are organised is it? Businesses may have aspirations about when they will be profitable, gain market-leading status, grow to a certain head-count or even move to new premises, but unless people are childishly naive, they know that these things can't be perfectly predicted, why is the creation of software different? In every book on project management that I have ever seen, somewhere it says "you can't fix time and scope" and in nearly every org that I have seen what happens? The plan attempts to fix time and scope. This is NOT about marketing campaigns and deadlines, this is about irrational approaches to planning vs rational approaches. I choose the latter. Sure it would be nice and simple if we could fix time and scope, but we can't. Face this reality and pick which one matters, then fix that. CD means we can always deliver to a date, or work to a specific scope and deliver continuously, or wait for a certain scope. Either one works, attempting to fix both is a fantasy.
@@ContinuousDelivery in my case, the company has a new car model launch in China for Q1/2024, for that to happen we must deploy infrastructure there and have it working by that time to support a successful launch strategy with great user experience. I don’t know how else we could have done it expect to structure a plan with a timeline, mapping dependencies with other teams, descoping half a year of already prioritized topics., in short, a big waterfall project block. Had we not done it, there would be no basis escalating to upper management and request more budget to get it done in time. It could still fail and obviously It’s a rough map to get there with margin for change, but again, I’m not aware of other strategies to accomplish it. If there are I will be very eager to shift the company culture in that direction and get away from the waterfall to management crutch
Dont we need any kind of predictability? As a DBA and as a Scrum Master i need sum predictability to when new software will use my DB or changes to existing software to be able to match and assist if sumthing dose not work, or if we have decresed preformance.
I have meet alot of developers that call up Operations 30 mins before they plan to do masive releases and expect our help and downtime on things that affects several other systems and then they get mad that we dont jump up and say ofcourse go for it. How can these two worlds meet if we can't have any predictability?
The true roots of the Agile approach laid in the desire to repair the "disconnect" between business and IT in enterprises (See Martin's articles and books about this). The goal of Agile was to involve the business in the everyday effort to deliver value in a project's product. So why not "scale" the approach from a project to the enterprise? As always, there is the practitioner disclaimer - skill levels vary, as well as the true intent of those involved, i.e., human nature; however, I have seen it succeed when an enterprise commits at significant levels. Agile itself was firmly in place at my organization; scaling it to the enterprise was a continuation of the emerging culture. No consultants were required.
6:50 Adjective*
very good point, i like minute 6: if the process is predictable, I don't learn and improve.
While I have little experience in SAFe, I see that in different organizations it is consistently used as a way for management to reintroduce Waterfall. Which might be fine when Waterfall is the right model to use, but usually this is not the case. On the other hand there is some need for SAFe (although without this senseless complexity and bureaucracy): if Agile is TDD, SAFe is dependency manager. That said, the software developers' notion that "whenever it's done, it's done" and we don't need predictability, is also flawed. In my industry there are so many downstream dependencies until the software gets into customers' hands and so many things the customers need to do to roll it out internally, that you need a deadline to plan all this. The software delivery date is when the software is released to customers, not when the software is done in development. Agile itself is all about predictability while at the same time accomodating pivoting. Otherwise there's no point in sprints and storypoints.
Clearly, we watched two different videos. Dave expressly mentioned that agile is NOT! about predictability. I don't know where you get this notion that agile is about predictability.
@@Don_Giovannifeom around 18 years of practicing SCRUM
It seems most companies practice Waterfall.. yet that is universally agreed to be the worse? For those companies not doing Waterfall, do they mostly use SAFe , SCRUM or the Kanban methodology (or framework) to implement their philosophy (AGILE/RUP/V-Model philosophy (SDLC))?
I'd like to move away from a rapid-prototype environment to something more formal in order to develop high quality/safe products containing embedded software.. for ANY industry.. Aerospace (like Lockhead's SEAL Level X, Boeing , DDPMAS, DAL A to E etc) , Medical or Nuclear industries.. even Automotive.
I imagine there are differences between the industries.. but I'd love to see a trivial project example that shows all the typical steps and outputs.
FAA : DO-178X , DO 331 , ARP4754A , ED-12C
FDA : 13485 , ISO14971 , IEC 62304 , SaMD and
DOE Nuclear : 414.1x,
(Automotive : 26262)
For example, assuming I document the process on how the code is generated, what constitutes proof that it's safe?
Static Analysis?
Code Coverage - Statement (Level C), Decision (Level B), MCDC (Level A)?
Who defines the unit tests? And what are the typical tools/software needed, and the typical document/artifacts in the various stages of the software life cycle?
I saw a good video by CEMILAC Education Program "Airborne Software Development & Certification Process" and it's a bit overwhelming:
Requirement Management - (IBM Ration) DOORS, JAMA, Xebrio, rmtoo florath , doorstop-dev / doorstop , reqview
Static Structural Source Code Analysis - Parasoft, PolySpace, CodeSonar, horusec , SonarCloud, veracode PREFast, TBrun, LDRA
Dynamic Analysis / Modified Condition/Decision Coverage (MC/DC) - VectorCAST, RapiTest
Traceability Tools: Reqtify , Polarion , McCabe
Configuration Management / Storage and Version Control System - Git, SourceSafe, Mercurial, MS TFS, ClearCase
QA / ALM- Helix ALM for Managing Artifacts, Establishing Traceability, Documenting / Enforcing Processes, etc
(I)V&V / Unit Test Automation - VectorCAST, LDRA Testbed , Mathworks Simulink DO Qualification Kit
Continuous Integration / CD - Continuous Delivery/Deployment - Jenkins, Bamboo, or GitLab CI/CD
And what is the general attitude towards open source software (ex. FreeRTOS) and code-generation tools (ex. ST's Cube MX)?
Also, how do CPLD and FPGAs fit in to the embedded software picture.. since not exactly software nor hardware, since they are programmable devices written in an programming language like VHDL , (system) verilog , Amaranth HDL ? How would DO-254 apply to HDLs?
Scaled agile is great for empire builders. It is also great for prolonging, rather than completing, work.
I've helped installing SAFe by interpreting it as a scaling of the SCRUM pattern to a team of teams (and team of teams of teams); for a team of teams, a quarter of a year is an iteration. There is a velocity for the team of teams, a retro etc.
Reliability for me is as desired for a team of teams as it is for a single team, and a good tool to meet customers target dates, such as start of production in the car industry.
From my point of view, it can be made to work very well, while (or because of) embracing core agile values.
For me, the main benefit really is, apart from scaling a successful pattern in a fractal way, to split a large organisation into several, mostly independent streams (i.e., release trains), thus reducing complexity and alignment overhead between these parts of the organisation.
It also is suited to break down huge endeavors into manageable chunks, using several layers of abstraction, where it's clear who is responsible for which abstraction layer.
Never heard of SAFe... sounds like another word for scrumterfall
Agile is an adjective, not a verb. Agility is the noun. Agilely is an adverb. There isn't a verb form that I can find.
I believe there is a witch hunt for SAFe that (I guess) unintentionally leaves out crucial elements that make SAFe "more agile". What made agile into a buzzword and eventually brought down NOKIA is bad implementation by unskilled consultants that don't know how to practice and measure agility. Same with SAFe, but with a different result - they make waterfall company become more agile.
SAFe is most complete body of knowledge out there. Using it in other way than a guide is the problem. SAFe is reiterated based from experience from the field (seen it change according to what I experienced in the field), trying to understand its limits and faults and improve. It is definitely not "one glove fits all", same way you pick kanban or agile based on what makes most sense.
Statement "being Agile is to embrace change" is just another way to make sure a consultant has a reason to stay with a company and is a crux of many implementation, as it is hard to understand the actually "how it is done" process wise..
as a consultant Ive never seen a full implementation of SAFe. And I never pushed for one, because it is a framework, not a methodology. Things people say it lacks it actually promotes, just adds a practice to help explain what it actually means.
All the transformations are a process. Ive never seen an "enlightened" CEO transform a company in a whim. At least not in a large, international corporations. Change is gradual and encompasses many parts of the company with many sponsors and stakeholders. Yes, SAFe in a lot of them just "fixes" waterfall. For a while. but based on short term success, trust from sponsor, will to change and a skilled agile leadersip, with SAFe you can point at a practice, teach it to them and end up with an agile software unit that enables hardware or anything else.
(and btw predictability focuses o value, not feature delivery).
This video cuts deep. I working at a company which have adopted SAFe more than 2 years ago and l can confirm it does not works. But. There is a but, it is still better than chaos which was before SAFe. The company is just not ready for pure agile way of working. The dysfunctional Scrum process was equally bad.
SAFe can not work, simply because it is a mini waterfall and that did not work either. SAFe is too slow to react quickly enough to changes. So the plan goes out of the window after the first or second sprint (or iteration as SAFe calls it). Creating a full Program Increment plan which means planned work for 5 sprints, or 10 weeks is impossible. To many things can change in 10 weeks, and it has a huge administrative overhead. So by now, we ignore most of the SAFe processes. We make a very vague rough plan for a PI and a somewhat more detailed plan for the first sprint and see how it goes from there.
On the other hand SAFe is not the enemy of continues delivery. Actually it has two release "models". One is the old school model, where somebody decides a date and content, based on feedback from the team and this is preferably is aligned with the end of a PI period. It follows the cadence of the release train. But an another concept or promise is the "release any time" so it is there. But it is hard when you can not release half-done features and your customers are slow in adopting new versions.
Almost forgot my thoughts on speed. You never can be fast enough. No matter how fast you can deliver a feature, your managers will always demand more. One of the first questions is "how long will it take". Managers love predictability!
Most software development managers could vastly improve their success if they would follow two clear principles: (1) Prioritize bug fixes over new features, and (2) never make a promise about new features.
Helped?
Well, the stock market and revenue numbers have a slightly different story. While most of SAFe companies, and companies in general don't like to talk about processes openly, there are some peculiar stories on Linked-in and "X" regarding SAFe.
safe for me killed creativity and flexibility for developers but allowed product/ sales teams to predict andfocus on only key features in a 8 week period. Fell into scrumfall. Needed bottomup solutions , not too down process /rules.
Biggest problem in SaFe is that requires organisation changes and people hate that.
Especially managers.
I have been part of implementing SaFe 2 times now 😂
Funny the things you mention about takes what works and remove what dose not. That works for Safe aswell
The thing I like the most is PI planning because dependecies becomes clear for all teams. And sometimes people discover it during PI.
But yes done wrong it is not Agile.
I've never worked in a SAFe environment but I love the idea of PI planning. This seems like an effective way to manage a just in time approach to managing change. The rest of the framework can likely go in the bin though. I've heard from a number of people that SAFe is meant to be done prescriptively where you follow the framework exactly. Not only is that not agile, it's a pretty ineffective way to run any enterprise.
PI Planning is a good aspect of SAFe if kept light weight. Having dev's think a little further than the next sprint brings benefits including more sustainable architectures and earlier notice of impending cross team dependencies. This is good. But there are lots of downsides if other stakeholders see PI planning as the vehicle to get 'Predictability'
@@keithalexander-buckley3708 Although... if you find that your developers aren't able to think beyond the next sprint then perhaps your developers just... you know... suck. And... you know... should be let go. :)
@@FudgeYeahLinusLAN 0:14 It is the knowledgesharing part in PI-plannings that seems to be the most useful part of SAFE. In addition SAFE may visualize dependencies between teams (but not sure about that). You cannot plan for both time and scope at the same time, as SW-development is so complex. Better instead to be better at what you do, e.g. by sharing knowledge .
If it was for me I would keep Pi planning and scrum of scrum. Then just follow normal scrum activities.
Ironic how Southwest Airlines shows in their Customer Stories after their IT related incidents in December 2022
Is it safe?
SAFe is all about protecting useless middle management, when the best thing that could happen to middle management is to get rid of them.
One of the biggest blockers to Agile is middle management.
Do we really need non technical managers? just a domain expert or somebody that speaks with the client shouldnt be enough?
it's not predictability of "outcome". it is the predictability of "inputs" that SAFe is addressing. it is trying to address the pain point of multiple layers and matrixes of the massively large organization not knowing WHAT the product they are building purpose/value/justification is... -no clear scope, no unit of measure of success, no single responsible point for the product. no outcome based definitions of success. SAFe depends on the PO and then has multiple layers stacked on top of the PO that have no idea whats gong on.
If agile didn't work, you didn't use enough. (the process isn't the goal!)
I work under SAFe and it's a nightmare. The only good thing is, all the good programmers left before I got hired because it sucks so badly, so I'm the best programmer in the entire project by far.
Our team has been doing XP until our company regress to SAFe, ridiculous
SAFE is the excuse for real change.
Very good as usual. But agile is an adjective, not a verb. 🙄
Optimize for productivity
Prioritize for quality
Predictability = Estimation = Pure Waste
Yes!! After reading Accelerate, I think practices like continuous delivery are closer to Lean thinking than original agile. And Lean is all about reducing waste.
There is so much waste in enterprise software development...
Safe is a monstrosity
It's better than CMMI level negative 4! (sabotage)"- bad things can be better than horrible things.
Of course it's safe. If you prevent change, you will never break things. But it will also slow you down.
But I guess it can be good for companies that were just plain worse before it.
In general, business is very disturbed when the development team says it needs to learn things in order to implement a requirement. They are of the opinion that the dev team already knows how to implement it ("that's why they pay them" :)) so money ppl need only to know when it is going to be ready. Business doesn't care about iterations, continuous delivery or whatever methodologies we use - they need to know how much it cost them and when it can be delivered. Telling them we don't know how much it cost them or when it is ready is simply not acceptable for business. And I am not sure we can change that world view.
"Iteration, adaption and agility" are not possible when each cycle costs your the better part of $1M. Such as in a highly regulated hardware industry. Nevertheless, we have Agile forced on us.
Can you talk about the alternativ LeSS next! 😊
6:00 - that's the typical misunderstanding of what "predictability" is which many technical folks have, and which is why "Agile" for a long time wasn't being taken seriously in management circles.
If you buy an airplane ticket to be in Los Angeles to arrive just on time for the 4th of July festives - do you want to hear, "I can't tell you when the airplane is going to come, but we're working on it, and improving our efficiency so it comes faster?"
No. You want your airplane to board at full noon on 3rd of July, not an hour earlier or later.
Enterprise level predictability isn't talking about details. There are a lot of major activities, such as marketing campaigns, B2B contracts, potentially even fines or lawsuits, hinging on not meeting a specified timeline. And of course, managers want to know if they need to mitigate something, or whether they can sit back and say, "I trust you folks, you got this, get on with whatever you're doing, you're the experts."
If an airline can't give a straight answer to the question, "Will the airplane board on 3rd of July, 12 straight - yes, or no?" - they shouldn't be in business. If your airline would say, "Well, we're not working on predictability, instead we're focusing on boarding passengers in small batches ..." - you'd probably run away screaming and find another airline.
But is the airplane problem an already solved problem or something we need to learn how to solve?
To continue on the traveling metaphor, imagine you are the first Spanish sailor that will try to go to India. Do you care about predictability or efficiency? You can have some plan, of course, but efficiency and antifragile to unknown difficulties are more important aspects. If you are the second sailor, now you can be slightly more predictable, but only a bit. if you are the third.... So on and so fourth until we have 100 years of aviation and we get predict to the minute when we gonna arrive.
Software people rarely are the first sailors, but hardly we are airplane pilots. We tend to be way more closer to the sailors - after all, copying software is costless and small changes are cheap; we are more important when we need to be more as the sailors.
And the Agile Manifesto for **Software Development** (not for Airplane Piloting) aims at these problems: Small teams working interactively to solve a problem
But if that is the goal, why are you trying to adopt "Agile"? What "Agile" practices do you think would benefit in your example?
this is apples and oranges, in my opinion. you don't buy a plane ticket to fly on a plane that isn't even conceived of yet. you buy a plane ticket for a plane that has gone through years of r&d, calibration, stress testing, etc. so that you have the privilege to one day fly on them on demand with the confidence that it won't go up in a ball of fire. and for some reason when we try to say "this system will take research and iterative improvement" in the context of software, people balk, when in fact in the very example of an airplane, all that time and effort of an analogous continuous learning LEAN manufacturing process is obscured from you the passenger because no one in their right mind would try to promise you a seat on a nonexistent model of airplane.
And that a failing of management, not agile. Sadly, very few business activities genuinely support agile.
You're missing the point: Software Engineering is solving problems nobody has solved before. If it was solved already, you can just download and use it. That's why "build my website" jobs tend to be more predictable than "make this car drive itself". We successfully did thousands of airplane flights so we can plan and repeat the same thing we know how to do. Nobody told the Wright Borthers they got 3 months to finish this people flying for the first time thingy.
SAFe at my company feels like waterfall but without the artifacts from the analysis and design phases. It is the worst of both worlds - the poor foresight of agile and the brutal, slow busywork of waterfall.
Face it, as long as it makes the higher management feel safe, it will get adopted.
💯
But verbs are doing words
Waterfall never existed.
Um, predictable should be dynamic and based on monitoring performance and productivity… but I agree, RUP was nonsense, just like SAFe
If that framework is destined to not succeed, does that make it SAFe to fail? ;)
Safe is just development process bloatware.
Einstein quote source: The Hazelton Institute
SAFe is not the goal, rather an interim step toward Agility, eventually not to use it anymore. Reality is organizational agile latency is very low, hundreds of teams don’t have alignment by default, architectural evolution takes years to modernize, political boundaries prevent collaboration, technical agility takes effort to cultivate, don’t forget the fluctuations in organizations, they all play the role of why SAFe is adapted. I disagree SAFe don’t inspect and adapt, because at each iteration, teams do inspect and adapt through retro and every PI Planning there's problem solving workshops
Agile got killed by another cargo cult philosophy. There is always a bigger fish. Very funny.
SAFe is full of nuggets of wisdom, but it is a massive, overly complex and wasteful approach if followed exactly.
Scrum is a scam thats done at team level, but SAFe takes it to the next level where the fraud is committed at an Organisation level. Hence the term scaled agile.
I prefer calling it frAgile.
I completely disagree with Dave!
He should see the SAFe a bit more closely for those use cases when an enterprise is in question, that the whole ladder has to change starting and coordinating from TEAM, PROGRAM, SOLUTION and PORTFOLIO of multiple products. It is the management that allocates the FUND for the whole exercise.
When I worked as a developer, Agile/Scrum and other developer-centric things were the only important things. But the developers are/were themselves a toxic community, not delivering anything Management needs or wants to have. All others were sub-standard people. The developer-centric worldview!
Today in the cloud world, non-functional requirements decide the software architecture and software developers are key but a small part (1/3) of the whole story... Cost-effectiveness, Scalability, HA and Performance in the cloud are the key drivers, that finally trickle down to design to manage the complexity that we all know like
Modularity,
Cohesion,
Separation of concerns,
Abstracting,
Design for testability
We have today a no-code paradigm, IoT.
The developer in him urges him to get rid of any control that management wants. The developer didn't know CI/CD before he and Jez wrote such a great book. Developers have inertia and cognitive limitation in seeing beyond the developmental challenges.
When we worked in a team of TEAMs of more than 130 people SAFe was absolutely needed, and I know SAFe pretty well.
SAFe is more like a bizarre combination of plagiarism from Toyota,, Lean manufacturing, some engineering and redundant less commonly used words in their vocabulary ( kind of too much blah lah marketing) and re-inventing the wheel, very expensive, paradoxically slow, and a huge waste. Unfortunately consulting firms take advantage of the marketing to convince clients and “sale SAFe consultant resources” the results > bureaucratic way of working very expensive and a never ending story
"Agile" works fine if you only need 1 team and there are zero dependencies the team cannot solve itself. Beyond that "agile" falls short. And when things get complex that's exactly when we are in dire need for methods, tools and processes to help us build (and maintain) those large complex systems with dozens of teams, that have many dependencies with other systems, teams, departments and (outside) organisations. When things are simple and small, you don't need much support, and "agile" is probably enough to fix the problem. Scaling agile is not so much about agility, it is about all the things you need to build large complex systems. And yes, that will mean you will loose some of that agility.
Agile looks a lot like software development in the early days by the way, when there was little specialization and everyone did analyses (talk with user), design, coding, testing and documentation (T-shaped profile :--). The software industry has come full circle?
The idea that predictability is bad because we are going to learn so much so fast that our velocity will increase a lot during the course of the project is just fantasy. That might be true for new grads figuring out how to use source control, or for teams made up of developers who don't have any experience in the tech stack they are using. But not for teams with senior developers and architects.
The problem is not the idea or frameworks or whatever people want to call it, the problem is people learned to do things a wasy and that’s their way.Also all of these blah blah “frameworks” are bizarre creations from people who wants to make money out of ignorants. The idea of Agile was for the developers to have a said in the execution of a project, but people in business kept having the ideas that business has the said on how to do things…hence the forever bizarre way of working …the business way! A bizarre hybrid of agile scrum lean safe and whatever else
SAFE is not agile! Dean, whatever his name should just accept reality and call it another methodology why because tell how planning for the next 5 sprints aligns with the agile manifesto or the 12 principles of agile?Not to mention what an utter waste of time it is to gather everyone in a 2-day long meeting. And moreover, after all that marathon of the planning sessions, it adds no value as soon a teams 2 sprints in cannot adhere to the PI plan.
SAFe is garbage. I hate it so much.