Agile Uncertified | Philosophy Over Rituals
HTML-код
- Опубликовано: 26 янв 2021
- Is Agile software development a failed approach or is it an important advance? Discussions of agile methodology and agile philosophy often get bogged down in discussions of practices: “Is Scrum better than Kanban”, is “SAFe or Less the way to scale-up”, “Is agile certification a good route to success or a money-making scheme for the trainers?”.
In this episode, Dave Farley attempts to demystify agile thinking. What is the idea at the heart of agile thinking that made it definitively win the “waterfall vs agile” contest? Why is the idea of “post-agile” a misunderstanding of the step forward that the move to agile software engineering means for software development?
-------------------------------------------------------------------------------------
🎓 CD TRAINING COURSES 🎓
If you want to learn Continuous Delivery and DevOps skills, check out Dave Farley's courses ➡️ bit.ly/DFTraining
📚 BOOKS:
📖 Dave’s NEW BOOK "Modern Software Engineering" is now available on
Amazon ➡️ amzn.to/3DwdwT3
In this book, Dave brings together his ideas and proven techniques to describe a durable, coherent and foundational approach to effective software development, for programmers, managers and technical leads, at all levels of experience.
📖 "Continuous Delivery Pipelines" by Dave Farley
paperback ➡️ amzn.to/3gIULlA
ebook version ➡️ leanpub.com/cd-pipelines
📖 The original "Continuous Delivery" book by Dave Farley and Jez Humble
➡️ amzn.to/2WxRYmx
📖 "The Beginning of Infinity: Explanations That Transform the World", David Deutsch
➡️ amzn.to/2MrOEqA
📧 JOIN CD MAIL LIST 📧
Keep up to date with the latest discussions, free "How To..." guides, events and online courses.
➡️ bit.ly/MailListCD
-------------------------------------------------------------------------------------
Dave Farley's Blog ➡️ bit.ly/DaveFWebBlog
Dave Farley on Twitter ➡️ bit.ly/DaveFTwitter
Dave Farley on LinkedIn ➡️ bit.ly/DaveF-LI 
Наука
Sadly, in my experience of agile dev, the focus is on getting that task to ‘done’ as quickly as possible, even if that means building up a technical debt that is never addressed. Huge amounts of man hours in ceremonies, less time for productive work.
That's a matter of culture, not process. Agile or no agile, if there's no culture that promotes quality and no understanding of technical debt, the results will be the same.
One more thing: technical debt isn't what most people think it is. Technical debt doesn't mean shitty code. That's just bad quality. Technical debt is knowingly, intentionally making compromises in architecture or code structure for short term advantages - like a simpler implementation that performs worse for the sake of shipping a feature earlier, or some code duplication for the same reason - there's almost never a reason for introducing technical debt other than shipping faster. Making such a compromise doesn't mean accepting shitty implementations. Shitty code in a properly designed part of the application is not technical debt, it's just shitty code.
@@a0flj0 Completely agree - you articulated what I meant so much better than I did
This is exactly my experience as well. The whole idea seems to be to close as many jira issues as possible in a sprint for the graph to look good at the end.
@@Reinfallt That happens when the scrum master runs scrum, instead of the team running scrum, and the scrum master just assisting.
Technical debt is unavoidable. Today’s cutting edge code is tomorrow’s technical debt. A truly mature organization recognizes that managing technical debt is an ongoing part in tandem with new feature prioritization.
Sadly, I've been in so many agile projects that go south. Very few Agile projects actually implement agile correctly. People focus on scrum, user-points, grooming meetings. In short, there is so much focus on the process that everyone forgets that they are trying to build an actual product.
I've been on a few where Agile was utilized correctly, but they are almost like a unicorn. In so many projects, Agile literally gets in the way as opposed to helping.
And don't get me started on "fail early, and pivot" because most companies want to do this without building in the time for the course correction. They assume all of these design changes (even when they throw their "wish list" in there) come for free in both time and resources. It's borderline insanity.
My employer is implementing Agile, and wants everyone to learn and adopt Agile, even groups that don't develop or produce software.
As I've been doing training, some of the things you pointed out have been standing out to me as ironically obvious issues. The whole thing preaches "individuals and interactions over processes and tools". Yet, it has a structure and process. It may be loose, but it's still there. And then it goes on to suggest that by throwing software out the door continually, you would be able to create and maintain a steady pace, as if designing, building, debugging, and completing all features takes exactly the same amount of time. I'm no developer, but I understand that some things take longer than others. I also understand pushing out software iterations just to push something out the door is bad practice.
The thing that makes me most skeptical... Agile isn't new, but companies hear about it, or hire someone where it was being done, and it suddenly becomes this new magical solution. I'm not saying it's complete snake oil, but there's plenty snake oil in the commercial market. Someone hears this "new" great thing and suddenly, it's going to solve all the problems. And it couldn't possibly bring in it's own set of new problems. The emperor's new clothes. Even worse about Agile is it has a cult-like component, "being Agile". Co-opt some positive ideas that have little to do with process, and make it part of the gimmick.
@@jonjonr6 "It suddenly becomes this new magical solution" is - in my experience - the real problem. As the video says, these are tools, not solutions. Tools are meant to make it easier to reach your goal, they are not the goal itself.
I hear this excuse for agile quite often, yet waterfall is regularly attacked by using examples of poorly implemented waterfall.
@@jonjonr6 Unfortunately agile may be intended to be loose, but things like scrum are very rigid. Just try suggesting that your team doesn't need one of the mandated meetings. Companies also assume that team performance must improve due to the magical powers of agile. When a team that was already efficient and delivering a quality product doesn't get any better management assumes it is because they're not doing agile right and starts interfering. At that point team performance plummets.
There is also a whole lot of other nonsense that goes along with things like scrum. Like assuming that a team of people who keep their personal life outside of work can't possibly be working as a cohesive unit. The result is once again management interference to make them do group therapy style getting to know each other. And performance plummets.
@@ian1352 I've been on far less waterfall projects that go south than Agile projects. Yes, you can f- anything up with enough talent. Waterfall succeeds (usually) because it based on phase line reviews to move forward ... and without a focus on ceremony.
I’m a Scaled agile coach and this makes me want to question a lot of things I learnt. Thank you.
Thank you
That's humble of you. Well done :-)
Specifically what points were brought up that made you think that? Please name four or five?
@@monkyspnk777 one that left a mark was the whole “value stream mapping “, not treating software like an assembly line thing.
Shouldn't you be questioning what you've learnt... always?
Modern SDLC:
1) “Analysis”
2) Implementation
3) Denial
4) Anger
5) Depression
6) Bargaining
7) User acceptance - if failed go to 2
🤣
You forgot blame for those at the sharp end and praise for higher management who contributed virtually nothing to project success. Oh and legal proceedings against third parties
no analysis all the time, so real responsibility for analysis goes to the leader of implementation, that means that leaders are so important
Ah... The old "Cascading hydric acid" approach we all know so well!
@Super Mario development in prod too I am afraid ie no separate development environment
Putting aside specific methodologies, agile for me is about two important tenets (a) Fast feedback loops at all levels, allowing you to identify problems early and self-correct. (b) Assuming that the initial plan is wrong and the initial direction will change, and providing tools and techniques to help manage and communicate this. The main flaw with waterfall wasn't the up-front planning or design, it was the assumption that those were correct and largely immutable that caused problems.
My company (very large) is proving to me every day that it doesn't matter what methodology you use if you have management who is clueless, it still goes wrong. Agile just makes it take longer, since we spend so much time in meetings. We're more worried about burn down charts, and not meeting that line on the graph, than doing good work. Thanks Agile/Scrum! Did you know every single software development problem can be solved inside of 2 weeks? I didn't. I guess my 30+ years of experience taught me nothing! And now, I have at least 4 bosses right over me, and all of their bosses as well...all wanting to meet to talk about the progress made/not made on their pet project, which is taking longer than it should (according to them), because the person who wrote the LBC has no idea how things work, and what other things will be affected by the new widget request. Design? No way! That's waterfall crap! We'll ITERATE until we get it right! Except, of course, when you're dealing with financial systems that move real money, not webpages that show pictures and comments, that doesn't work so well.
Same here. Meetings everywhere. What I hate too are the Scrum Masters and Project Managers who has near zero technical capabilities and insists on interjecting their theories where the developers are discussing the solution. Total waste of time. The stand up is a little annoying at first but it does bring some value in getting everyone aware of what's happening. The Sprint planning with everyone including the newbie proposing a number to complex project? Biggest joke to me.
Exactly! I feel your pain!
Thank You. I think this is one of the most important life lessons. Make simple plans and adapt.
Experiment, fail and learn. Eliminate hypothesis.
ImproviseAdaptOvercome.png
Test hypothesis or eliminate hypothesis?
Agree, but I was doing this before it was labeled as agile
In agency type work where you must send the client a bill for your time and you must bill enough time to justify your role, "experimenting, failing, and (possibly) learning" will be the summary reason given for your firing.
GG
Been programming for 30 years or so. It took me 20 years to not fall in love with my code, to review these periodically without bias, to not get offended when judged, etc. The hardest lesson for me on the path agile programming was my own ego.
Proper waterfall never worked like. Waterfall itself was incremental. Timelines were dynamic, designs were updated, and software tested as pieces became available.
Waterfall never existed in the manner the agile priests tout.
As an accidental Product Manager in a very small organization, this was an enormously helpful breakdown of a) what Agile truly means, and b) the kind of thinking that keeps you agile; avoiding the trap of waterfall thinking when agile processes will work much better to get to solutions. Thank you!
In the 90s, we just started to code based on meager requirements and we refined them on our way. And sure, some code needed to be scrapped and rewritten for a change in vision. But we always managed to deliver. Our software house was seen by the big sluggish competitors in the medical business as "cowboys".
We were AGILE before it was a thing. Because our board members were all vets and doctors and when they can't design requirements to the fullest extend, as the intended customers, than who can? Our customers loved our user group days. Because they got to see where we are, we had concrete questions for them and they for us, as well as good constructive feedback.
Unlike our big snooty English competitor, who just coded and released -- much to the dismay of their clients. They were 10 times as big as we were and went under. If they spend more time in listening to their customers and worked incrementively they'd probably heard that their product was heading in the wrong direction with each annual update.
Fellow cowboy here. I laughed the first time I read about Agile programming, since I had never worked any other way. That's was the advantage of being the programming department for a small company. They did not care, or know, how you got the job done. As long as it worked and they could not figure out a way to break it, they were happy.😁
@@johnshaw6702 That’s cool to hear John! Yeah I guess small companies, just innately worked that way. We were also a tiny softwarehouse compared to the others.
Another advantage of starting to work for a small company, is that you literally have to do everything to an extend. So you also managed the network, and talked to customers and heck even fixed things. I think that juniors should start at small companies, they’ll learn more than at FANG.
@@spleenware for sure Scott! Agile has become synonymous with “crap code and ready to scrap code”. CI/CD is the cause of this. Because delivering patches and functionality is easy. In the 90s when I made an update to the Animal Group Health analyses suite, it cost us 5K in floppies not counting the man hours producing the copies. So you’d Damn well made sure the code worked and was stable and you didn’t want to scrap it in a Next release because it took (far) longer to write.
@@CallousCoder Agree. I'm astounded at how much lazy coding is done. Rummaging around in stackoverflow for something that 'looks right', bunging it in, add any and all lib dependencies in, and hope for the best. The result is bloatware. Actually, I consider the entire Web ecology as bloatware.
@@spleenware I recently said: “if car manufacturers would make cars like software engineers make code, you’d end up with a new car every 12 months. And initially it would do 200km/h but after a year it hardly manage to do 80. And the windshield wipers would stop during a rain storm. Because it has a bug. And you’d be at the gas station inflating your tires every week, but it’s okay it’s an MVP! “You have rubber tires!”.
It’s terrible where we’ve gone to.
As a Chemical Engineer who became a Software Developer, I found this video particularly interesting and appealing
Agile has the potential of being transformative, but it takes more than implementing a few rituals. The first "agile" dev shop I worked for interpreted agile to mean they had to do standups every day and did not need to document any requirements. That was it. That was what agile meant to them.
Sounds, sadly, quite familiar. Also, claims of doing Agile, but still micro-managing the teams WHILE pushing responsibilities to the team that are not the team's.
I work there now! Agile has been disastrous for us. Being agile is good - but the endless rituals and ceremonies of Agile(tm) is corporate death; all creativity is killed. Innovation? Forget it. Only the Product Owner could "legally" do it, and he's got all the creativity you would expect of a middle manager.
This!!
Happens WAY too often. I can't even tell you how many times I've heard "we don't document because we use Agile."
Coming out of college when agile was hitting the scene i liked the idea. It sounded much like the work i had done in class...iterating through to a solution learning more of the whole as i go.
Then i got to see it up close and all i saw was what you described. An excuse to have no structure at all and add more meetings in the calendar. For a long time i was against agile because of the corrupted definition and usage.
@@_Mentat Agile is not a methodology, it is a set of values and principles for developing software. If you are following some project management workflow, then you are not using agile.
The best methodology that has worked for me has been a hybrid approach of Agile and Waterfall. We include project planning and architecture stories early in what we call a super sprint planning session. This step may involve detailed requirement gathering however areas that are less understood take a more agile approach at this point. They are set aside for a later super sprint. We then follow natural sprints that will eventually build towards the goals/epics defined in the super sprint effort.
An inherent flaw in Agile is its inability to look above the trees. A major flaw with waterfall is its inability remain on the blue print that was so costly to develop at the onset. Departure from the blue print most often creates a better solution. The more experiences and repetitive the problem is however leads to a more waterfall influenced process in agile. You are going to do less steering and change when its something you have done before.
One of the largest misconceptions in agile is that it speeds up software development. So many managers assume this. It actually slows things down quite a bit. It does however tend to give a solution that the product owners/market desire more. And in that sense, it does save time in producing a product that is optimized. Hacking a solution is always faster but risks rewrites and several versions before getting the solution optimized.
Thanks for speaking the truth! Agile aficionados love to use the straw man of waterfall. That obviously never worked. Software development has always been iterative. That does not mean you shouldn’t attempt detailed architectural planning up front, even if you recognize the need to inspect and adapt. This is especially true when designing both hardware and software.
In both Agile and Waterfall, I've seen the same mistakes made. It's like an engineering company assigned to build a bridge, who plans it all out and embarks on the epic task, without making a model bridge first. I know we call this the MVP, but it's too often just an acronym.
I was looking for content like this for a while. Thanks for all this knowledge! Your channel is full of very good lessons!
There are two things that torpedo true agile in almost all companies. First, true agile means accepting some chaos, some lack of control, and that is antithema to the type of people that tend to start companies. Second, it requires a level of trust in the people on the ground to pull in the direction needed, and trust is not a popular concept in management circles. So instead of a flexible dynamic iterative process, agile becomes a rigid system for enabling micromanagement.
It depends. Too often it's brought in because management has heard the sales pitch of "*this* company brought in agile and saw development times drop 50%, and *this* company brought it in and saw defects fall by 60%" and they think it means if their company does it, dev times will drop by 50%, and defects will drop by 60%. When it fails to deliver those results, they assume it's because the devs aren't doing their jobs properly.
Agreed, agile isn't a pattern, it's the fluidity that allows you to change methods as the situation calls for. When agile fails, the team is stuck in a pattern and fails to adapt. People have a natural resistance against change as it takes energy and effort, and there's some fear involved of the unknown. It takes discipline to constantly detect if you're stuck and have to be awake and alert to see the best path open up in front of you. It takes some courage to step onto that path too.
I've been binging your videos for the last week. Newbie developer here. So thankful to have stumbled across your channel!! So much value and knowledge. So excited to purchase your courses (waiting until I grasp the basics so that I can use your course to better develop my first large project)
Excellent video, full of wisdom! You know that something is wrong when you've been to organisations where the daily standups are made of 15 people... including the company's accountant
I did work in a - still functional - team of 17, at some point. Then we split it up. But we never called in the accountant :-)
Yeah... in agile you'd split a team of 15 into 5 teams, cut stand-up time to 10 min, then have 5 plannings, 5 retros, 5 second plannings, 5 refinements and hire a few agile coaches as a cherry on the top, lol.
@@Krushard 3 people per team is too little. Optimal is 5 people in a team. Some people researched this. Below 5 people are are too thinly spread. Above 5 the communication overhead becomes increasingly costly.
Refinement is improperly called refinement - a more adequate term is grooming. That involves more than just making stories look better. IME, however, far too few people and teams recognize the criticality of backlog grooming. I've seen entire projects fail because backlog grooming was not done properly. If done badly, it can even impact overall system architecture, and when that gets messed up, everything gets messed up.
The more focused a team, the less time is spent in refinement, retro and other scrum ceremonies. An agile coach should never be a long term participant to the scrum processes. If he isn't able to bring the team up to speed within a few months, he should be fired - he's worthless, scrum has to be done by pigs, not chicken, and an agile coach is a chicken to the extreme.
The elephant in the room, with agile methods, IME, isn't scrum or agile ceremony itself. It's usually management that's external to the team. In order for agile processes to work, you need buy-in from management. If your product owner is just a proxy to the actual people with knowledge of the domain, or even an worse, an indirect one (for example he either communicates by email or in meetings directed by managers who are completely disconnected from the domain with the business stakeholders), if your scrum master is invested with the authority of a project manager by management, if architecture is prescribed by architects not part of the agile teams, if management insists on ceremony without having a clue about how to verify the substance, if organizational boundaries make proper continuous integration impossible, if similar organizational boundaries prevent teams from communicating directly and efficiently, agile methods are bound to fail regardless of what agile coaches you bring in, or how much money you invest in training your technical people for agile processes.
@@a0flj0 Ah, I see you're a bit out of the loop. You're walking on the edge bro, "grooming" was deprecated in favor of "refinement" because of american obsession with pedophiles.
@@Krushard The pigs and chicken parable was also removed from scrum, and I still use it.
All great in theory. The perils are when your management want COB deliverables, all the while you being agile. *You* change. *You* adapt. But don’t change the slide deck you presented to management. Because that would hint at a runaway train.
Then you JIRA the hell out of your discoveries. And don’t miss a sprint deadline. Because that would point towards a runaway train.
And have everyone stand around explaining what they didn’t accomplish yesterday, that they hope to accomplish today. A group shaming process. A process that helps the manager determine if they will meet their next PID review. And to determine if she should command a “swarm” operation, because we all know 9 women can have a baby in one month.
If all principles of Agile are applied, then you have a chance. If you apply three or four principles of Agile, I’ll call agile, but continue with waterfall, that’s a recipe for being part of another failed development group. Excluding the manager, of course.
I’ve been a developer and software architect for 30 years. I don’t believe anyone anywhere has given a better talk about the real need of a better approach and methodology for making great software.
I've been combing the internet for weeks and this is the best summary of Agile I have come across (maybe even better than the Agile Manifesto). Someone can memorize the Agile Manifesto and still not really understand the most important core idea of agile, which is embracing inevitable unpredictability and change.
Thanks 😀
Pretty much the same with ISO9001, if you implement it badly, it's worse than not doing it all
The most ironic part of agile development- taking an agile development process and rigidly applying it.
spot on - to add: agile is often (in my experience) cherry picked - I am always still amazed at why 'conveyor belt' delivery is even used as an approach in the digital world... agile fits the 'unknown' much better
Never heard a so clever analysis of what agile is and what could be. Thanks!
Please make more video.
I have never felt so much at ease watching a video related to Software Industry.
As a former chemical engineer (now software developer) I think I can relate to the process control parallelisms that you lay out. Controlling (in the sense of putting sensors and programming controllers) a transformation process that is well understood is profoundly different from controlling one that's mostly unknown. In particular, you need to generate more information and design more, easily reachable customization points that can make your system __converge__ towards a stable point. Waterfall applied to an unknown system is likely divergent: fundamental control theory says that, given a sets of inputs (i.e. scope/time/resources) and outputs (i.e. a released product), you'll have success in controlling the inputs (i.e. making a detailed long-term plan) if and only if you know perfectly the relationship between inputs and outputs (i.e. you understand the system perfectly); if you don't, you must approach the problem the other way around, by controlling the outputs (i.e. get data from a completed piece of work) and use feedback to modulate the inputs (i.e. review and adapt).
I think that one of the interesting things about "information" and its control is that the answers are so generic. That is why I think that the stuff that I quote in this video, from the Chemical Engineers, is so interesting. This is just as applicable to information processes, like the development of software, as it is about the creation and management of chemical processes. Really interesting stuff!
You make me want to learn more and be better every day. Thank you.
Thank you, what a nice thing to say 🙂
Brilliant. I have never heard these ideas spelled out so clearly.
Found your channel and am very pleased. Thank you for sharing your knowledge.
Great video. As a 45 year practitioner of software development, I fully endorse this.
This is by far one of the best videos I've seen on the topic. I could not emphasize more how important it is to think agile! Inspect and adapt! All the tools around it are of lesser importance. It's the way of thinking that matters.
How many times I've seen a Dev(including myself) just make an assumption that some part of their project will work how they've assumed, just to later discover that that part does not work like it was assumed. The consequences of over planning and over assuming are mid to large size rewrites, costly stuff.
More experienced, agile, inspect & adapt kind-of Devs know in advance which part of the project they don't know or plainly - do not understand, you plan for that. You focus on that part first, learn & adapt so that you don't fall into a trap of finding something that doesn't fit with the rest.
Over planning = assumptions = mistakes = rewrites/re-shaping = money lost
Nice video! The main issues are that,unless its a fairly new bootstrapped startup,basically it comes down to a bunch of Agile tools/practices slapped on/integrated with the Waterfall processes and crunches. You just replace PM with a PO to report to stakeholders,hire a nice Scrum Master to do standups every now and then,preferably daily,set deadlines for sprints and that's it.
As a cherry on top don't forget to use some Atlassian tools like Jira/Confluence/Trello,as long as the product is being delivered on time,no one in the stakeholder or VP section of the company actually cares about Agile philosophy,the product needs to be delivered in the set deadlines.Currently there is no empiric approach that is like the goal of Agile,more of "let's use Agile because it is trending" with Waterfall model under the hood approach.
Every single company I've worked for knows what features they want by what date(plus whatever features come up in the interim). Every single one of them also claimed to be agile.
It's very sad isn't it. I have literally witnessed that bussiness/management person asks for estimation and then just takes the estimation given and sets it in stone as a hard deadline.
Agile fails because at the start, software is small enough to easily change, but later on becomes large and stiff, allowing only the most superficial/inconsequential features to change, or those that were designed to be changeable (e.g. themes/skins/config settings). As a project evolves, managers receive increasing pushback on change requests and feature additions.
exactly. "This car needs to be an airplane now, our customers want airplanes. Why is company B's airplane so much better than ours?! Because we are launching a ford escort off of a ramp and throwing some wings on it." At some point if the software isn't doing exactly what you need it to do, you don't need change requests, you need to take it out back and put it out of it's misery.
Agile is really chasing your tail for as long as you can until they that pay realize they are getting nothing and cut the strings.
Large inflexible engineering is usually created by large inflexible organizations. On the other hand, there are those who with 10x less resources beat out all competitors - SpaceX, Cray in the above video, Google search and so on because they are agile. If you are an inflexible organization you are going to injure yourself trying to do flexible things ( see the Boeing 737 Max Fiasco) - but conversely don't cry when you become the next Kodak, Blockbuster, Yahoo or IBM because somebody else was flexible.
Agile works fine. What you are talking about is poor operations management and poor organizational design: Problems further up the hierarchy.
You get these same problems in factories that try to do lean or in engineering teams that try to use statistical quality control or accounting departments that try to implement advanced activity based costing systems.
Agile can only fix problems within the relevant scope. It can't magically make a poorly run organization well run.
Plenty of large legacy code bases have talented developers and manage to do large scale refactorings and design changes. But those are well run organizations to begin with. And so Agile works for them because it is in an environment where it can.
If you are in a broken inflexible organization, no development process will work. It's odd to blame agile for this.
@@MaxHaydenChiz To be clear, I don't have a problem with an agile philosophy or mindset, but there's just something about Agile that makes most companies screw it up and use it to brazenly justify management nuttiness.
Thank you, you are describing the essence and the important differences of agile software development. Unfortunately, the misuse you described is something I've seen much too often in my career. One fundamental issue with agile concepts in established companies is that managers (e.g. project managers) are mostly only eager to have the inspect part without the adapt because the way they have been trained (economic, not scientific) adaption and change always produce loss. I think for agile to really take off in corporate scenarios some managers need to have a change of mind and need to be able to let go of the controlling and focus on providing good boundaries for developers to work in.
So many people need to watch and understand this video!
At the moment, I am fortunate enough to word independently. Being "agile" helps immensely by structuring workload and flow but also at a psychological level. Reaching small goals every day makes work way more fulfilling.
I also witnessed how "agile" many companies are. A former coworker was so frustrated he told the bossman to just shut up and wait a week. He rebuild the entire project (3 months of work, 7 people) on another framework, documented everything, and quit. He said working on that team was as "agile" as Han Solo in Jabba's Palace :D
Agile development came bottom-up from the ranks. It was a hard sell back in 2003, when I started to work on an Agile team. We just kept learning. I gave talks about the benefits of sprint reviews, automated testing, etc..
One important principle that you didn't explicitly mention in comparing waterfall to agile: batch size. Small units of work are key to agile. With waterfall you had a gigantic batch of analysis, another for design, another for 'implementation', and yet another for testing. Agile works at chipping away the batch size, so that all phases complete in a short time period and the product grows incrementally with each delivered feature having been through all the phases.
Alistair Cockburn quoted Peter Naur as saying that programming is theory building. That is to say, what programmers do is to learn and create a theory of a system.
I'm retired now and don't have to worry about whatever 'post-agile' might mean. Seems to me that agile is at bottom a set of principles that don't need to change much, but always need application to specific environments and problems in a continuous kaizen.
There's nothing inherently agile in 'reviews, automated testing' and other practices.
This channel uses no of the modern video editing techniques, sound effects, animations... All looking for users’ engagement.
Yet it provides invaluable content.
Funny how the new standard flashy, high energy and click baity videos have started to loose their advantage due to oversaturation.
There is not always a single way of doing things right, but a plurality.
That's why the 2x playback speed exists
Very true!
It felt weird at the beginning. Made me question the value of it. But when I kept watching, it seemed very valuable. Now I'm subscribed and watched several videos.
I don't understand why this channel doesn't have more subscribers. Maybe it's because of the toned down style. Maybe it's because it's not that old.
That alphabet thing was also a good example of making reusable components to be used across different projects
Yes, I loved that example when I first saw it.
@@ContinuousDelivery indeed, it’s kinda difficult for me personally to keep future projects in mind while I’m developing but reusable components definitely reduce development time
@@tallawahh I think that one of the 'tricks' is to work so that your designs are nicely structured, so that they kind of "leave doors open to allow change" without overthinking all the ways that you code may be used in future. Funnily enough I am writing about exactly this right now for my next book. Fundamentally I think that this is about thinking in terms of managing complexity. We use modularity, cohesion, separation-of-concerns and abstraction to decouple our systems. We can 'encourage' all of those properties in our designs by the 'Testability' of our code, because it is hard to write tests for code that isn't modular, cohesive etc etc. I hope that my next book will give some useful advice on this topic (my hope is that it will be useful, it will definitely include the advice) :)
@@ContinuousDelivery it sounds like a good read, looking forward to it. And keep up the good work 👌🏽 small but really impactful channel; so easy to stay engaged with ur content
@@tallawahh reusable components is not merit of Agile, this concept exists much before computing existed in other engineering. In software is the software Architecture that brings this concept to the field, certainly much before Agile/Scrum even existed
I worked on a team that was all ritual vs philosophy. Insistence of using the "poker" number unassociated with hours. I always used hours in my own head because that is how I think. My estimates were always listened to more carefully than others. I usually was a low number or a question mark. What did that mean? It meant that I either knew how to make the software or I didn't. If I didn't then making a long term guess was never a thing for me.
LOL....the beginning of infinity? I know the answer. I wonder if he did. The beginning of infinity is now and here. Why because there is an infinite past and an infinite future. When you go from past to future you have changed states and defined the end. Same with forward and backward or up and down.
When I first heard of Agile, I was stoked! I thought, finally an adaptive approach that will lead to better software and quicker delivery. An SDLC that makes sense!
Unfortunately, after more than a decade and through the efforts of several teams using a variety of tools, I have yet to see the Agile approach work successfully. Every time it seems to devolve into an elaborate task management system. Daily standups become little more than morning role calls reminiscent of grade school attendance. Each day, people go round the horn and developers report what they did yesterday, what they will be working on today and if there any blockers. In short order, developers begin to focus only on working toward what they can report the next day rather than creating solutions to problems. Details are minute and understanding the big picture goes out the window.
Agile requires all players to participate. Sadly, I've yet to see that happen. Usually after a short time, the only ones left adhering to the process are the developers themselves. All other parties are interested only in the progress the developers make and people quickly lose interest in anything else the Agile approach has to offer. Meetings are canceled left and right, deliverables are king and tasks are meant to be completed daily regardless of their importance. Business folks stop participating too. It adds too much overhead to their day and just like in the the waterfall approach, requirements are slow to come. The difference is now we agree to move forward without actually knowing what is needed.
Every time I read a paper about Agile or watch a video like this, I get reinvigorated by the idea. It sounds like an awesome solution to a variety of SDLC issues. Sadly, I've yet to experience an implementation of this approach that holds up to the promise it offers.
For me the standup nonsense has always been a minor waste of time (or major in the case those "standups" that goes on and on so I have to sit down in order for my hypermobile knees not to fail), where I say what I did yesterday (which is almost always something else than what I said I was going to do) and then think of something I might do next; which quite often is "continue working on whatever I was working on yesterday". Fortunately I've always been one of the productive developers, so my limited respect for The Rituals has always been tolerated, since I do actually make things work.
@@SteinGauslaaStrindhaug Where the daily standups help in my experience is getting engagement from the less experienced or proficient members, and especially for reporting issues or blockers. I don't mind spending 5-15 minutes a day for just those benefits. It's also prime time (after everyone's had their turn) to bring up sudden requirements changes or similar. The "what people have done, and are going to do" part isn't that helpful, except in those cases where there is something sudden or unusual about a task (e.g. the build server is broken, who is going to work on getting it working again, so that not everyone will waste their time).
@@defeqel6537 yes it would probably be useful if the standup was the only time we could communicate, but we're on Slack all the time anyway, and in the before times we were in the same room as well so communication is not exactly complicated. And usually if there is something important we've already said it in the chat or we wait until the standup ritual is over to do the actual talking in Slack afterwards, as it's awkward to do any real discussion with everyone listening and waiting for the ritual to be done.
@@SteinGauslaaStrindhaug Yeah, I guess it depends on the culture. Personally, I don't really put things in Slack / Teams, nor read it very often, and just make backlog items with the relevant information and inform the team the next day about it. I don't like to interrupt or be interrupted while focusing.
I guess, the example of build server being broken would be an exception to that, as that should be fixed as soon as someone notices, so should be communicated ASAP, but other things can usually wait until the next morning (e.g. new alignment meetings with other teams, requirement changes, reporting a new bug, etc.)
Truer words have never been spoken.
Learning and discovery. Brilliant. But management always want predictability!!
Yes, but when they do, they are being irrational. It doesn't always help to tell them that quite so directly though 🤣
Is the pandemics of the measurability
In other words they need to learn how to work with probability as we left the realm of deterministic processes.
@@ContinuousDelivery ...and not just management, customers. They want to pay no more than $X and get the product they want (even if it's not what they asked for) in Y amount of time. Irrational, sure, but they're the ones paying the bills. I suspect this is in many cases an intractable problem.
Management are economists, and so are customers. We are engineers. They are the dumb teens who think that they know better, we are the adults who _actually_ know better. We should be smart enough to explain the problems we face when building them what they're asking for.
I've worked in too many companies where the Dev teams wanted to implement Agile methodologies, but were too afraid to push back against the established processes. So they implemented a Frankenstein hybrid model where they renamed the Project Manager to SCRUM Master, forced everyone to stand up in the daily meeting, and declare themselves agile but mostly carry on as before.
Yes, from my personal experience, I think that this is the commonest form.
Hi, Dave… I’ve watched a handful of your videos now, and don’t agree with everything you say, and even believe you’re wrong about some thing… but I mean that as the highest praise: you reliably make substantive assertions and ask questions that promote review, analysis, and discourse. I.e., scientific debate over quasi-religious dogma. I’m learning from you but also, more importantly, because of you. Very important in the internet era, and refreshing… thanks!
That's the most convincing and plausible explanation of Agile I've read so far.
Unfortunately many companies mistakenly think that agile means no planning. I hate having to explain to managers that a project still requires a design document and that they cannot just throw new features in without articulating them on paper or pdf in a change request.
Brilliant talk. Absolutely brilliant. Bravo and thank you!
Really inspiring lesson. Thank you for this!
This is probably better than a CSPO certification, subscribed sir. My regards to your content, articulation and experience
Our organization is starting to convert to Agile and Scrum. We were told this yesterday. HELP!!!!!
When to use Waterfall
- Requirements are well known with little uncertainty
- The work is repetitive
- Working with well-known tools
- The project is short
When to use Agile
- Uncertainty around requirements is high
- Product has high end user interactions
- Requirements need to be prioritized
- Time to market is key
Some excellent points made here. "Agile" is definitely a term that is misused and abused in many businesses claiming to be agile without really understanding what that means.
Thanks
It's amazing how easy it is to change all the words but still do basically the same thing as what you were doing before. The philosophy is the knowledge you need to make it work :) Also interesting that Lean and Agile as far I'm concerned are basically the same thing. Small production runs, being to quick to deliver to market, and leadership values are all identical. The 14 Lean Management principles are my reference for the philosophy we want to follow when building strategically for business agility.
Part of the problem is that the founding members of the Agile movement reading/inspiration list cover only the Toyota production system. So they use the ideas like Kanban and so on and apply the Toyota LEAN approach to software engineering. The truth is that already back in 2006, a book call The Toyota Product Development System describe a methodology better suited to software engineering. Software engineering is a creative activity and requires a creative engineering apporach.
04:29 the good iconic guitars!
Since I was a little kid, in the 1960s, my dad always told me that if I wanted to do something that I should just start doing it and learn along the way. He said "If you wait until you know how, you'll never do anything."
Well done Dave. My new favorite channel!
Thanks for watching!
A very nice video, and I especially liked the last few sentences on evolving agile, although I sincerely hope we are able to combine the engineering approaches to improving agile with management requirements, as the latter tends to be the reason most of us are stuck with faux-Agile processes.
I hope so too!
Spot on Dave, food for thought. The worst thing i hear daily is that people state state they are doing Agile without really understanding it. They run a meeting at the start of a 2 week sprint, have daily standups and deliver a demo at the end of it. This is not Agile. the sooner non devs accept this, we the sooner we can demonstrate more agility.
Many a meeting I have attended in which a feature has been deferred until later because of an unknown. Make an educated assumption, if its wrong amend just that assumption.
That should tell the educated that this is not Agile and is Waterfall with Agile-esque ceremonies.
Some of the best projects I have worked on were ones where there was just me as the developer and a subject matter expert, that's it. Other projects I have worked on have had me as the developer, a DBA, a project manager, a stakeholder, etc. Endless meetings after meetings, people trying to look busy creating documentation, specs, etc. and then having meetings to discuss them and each revision based on the last meeting. 50% or more of your time is blown in meetings. My other favorite thing is when your boss wants something done faster, so he offers a non developer for you to use and expects that will allow you to complete the project in half the time.
Once more, i'm deeply impressed , Mr. Farley
I couldn't agree more. He correctly points out that dev skills and even mastery are a small piece of the pie. The actual cycle, management of it, and processes/procedures to move through the effort should be front and center.
@@TheJacklwilliams I really like the Memorys of the good ol' C64 Days, when programming was still nice and easy😉
@@antongromek4180 Now that, feels like a hundred years ago. The only thing it was missing was the web. I still remember poking in basic from the magazine article, saving it to cassette and runnin it. LOL… Having access to sooo much learning, that’s always been my favorite thing about the internet, even before the entire WWW debacle began…
Another masterpiece from my fav YT channel. Thanks Dave for sharing such a brilliant content.
My pleasure! Thanks.
Another fantastic video. Thank you!
Thank you
After almost 25 years in software development, I've seen Agile fail (or enable mediocrity) multiple times. I don't believe this is because Agile is fundamentally flawed, but because it allows humans to procrastinate. Rarely have I been at a company that actually iterates back over its code. Rarely have they actively solicited and acted on input. Typically, the parts of the code that are not fun to write, like robust exception handling or parameter validation are pushed off as not part of the MVP but "something we will work on later". Later rarely comes.
Another issue I've seen is developers use the excuse that they can't anticipate every issue to avoid doing any engineering at all. I've repeatedly inherited code that is not scalable, performant, self healing, supportable, etc. Engineering is about taking what we have learned in the past and not making the same mistakes again. Yet I watch Agile developers paint themselves into the same corners that we did in the 90s, because they are trying to find the simplest (not the best) solutions.
Every development methodology requires oversight, but some need more than others. Agile requires a strict adherence to philosophy ... MVP is functionally limited but fully implemented, feedback is actively solicited and analyzed, code is iterated over and improved and expanded .... but in my experience that rarely happens. For all its flaws, I've seen waterfall force developers to create robust, performant code.
> Rarely have I been at a company that actually iterates back over its code.
I have never seen this happening except when the code fails and needs to be refactored.
Management does not care about iterating back. They don't understand that. What they see in that process is that the previous iteration failed because everything that was supposed to be done, was not.
If the features are implemented, management will never want to go back because that means that: a) either the implementation is not complete and the devs lied; or b) devs wasting time trying to be perfect and improving beyond what is required.
In these companies, Agile fails because management wants their Scrum not Agile, and this is the problem.
Management wants tasks to be done and never go back. They don't want library updates. They don't want framework updates. They want code to be written once and sold many times until no one wants to buy it.
what brilliant story telling about the why in agile. Nice & succinct + well presented. thank you
Thank you
I really liked this video. I don't like waterfall at all but I have also seen agile taken to such extremes by people that it creates problems also and I agree that a bit more design can be really good. From my own experience working with scientific simulations at least taking the time up front to figure out what math you need to implement, what the assumptions are, how you will discretize and solve it at a very high level make sense to do upfront. Trying to do that stuff as you go along is a disaster.
I have seen systems fail because they just started coding and later realized the equations they wanted to use where not really compatible with the kind of solution method they had chosen, and a LOT of work was wasted, and it would have only taken a few days to solve that part in advance.
I'm always happy to see software dev. experts and vloggers take a critical look at the strengths and weaknesses of agile (and faux agile). But my main issue is that no one talks about the decades of research on design-processes already done within human-centered ixD and UX in general. In their current state, it's a well known fact that most agile teams don't mix well with dedicated designers (I believe NNGroup have articles/videos on the issue). But if we could invent workflows in which they did, we could leverage the flexible value- and solution focused methods of ixD, Design Thinking etc. in software development. Essentially, interaction design seeks to do the same as agile dev., but it does so through paper, post-its, mockups, anthropology and end-user data - and thus works much more efficiently through its iterations compared to agile, which is build with an entire functioning, QA'ed and deployed product in mind. And that makes it harder to pivot.
Agile should seek to maximize the amount of knowledge gained per hour coded. And since coding, deploying and collecting (lackluster) feedback, isn't always the most efficient way to gain knowledge about a domain, we should probably code less, and integrate better anthropological processes alongside the coding. I don't care if you expand your profile or bring in specialists, but good code is (by itself) useless to our clients. Software has to be matched with and shaped by end-user needs and values.
It’s interesting how agile resonates with modern ideas of management and even philosophy. I’ve recently read ‘team of teams’ book which was written by army general and ‘Antifragile’ by Nassim Taleb and they are essentially about agile principles. 20 years ago agile was viewed by majority as some weird almost insane methodology and now it’s backed up by science. I’m impressed by this and it’s great to have people like Dave who shares what agile is really about
I assume you mean the majority working for big companies. I worked for and with small companies 20+ years ago and most used what I would call an agile approach, at least when they were working with me. Then again, maybe they just adapted based on how I worked when interacting with them.
7:24 - I find a certain unexpected perfection in observing that you misspelled “imperfectly.”
Enlightning! Thank you!
As a programmer from the beginning of time, we had no development process. Proposed systems were oversold with regard to both time and cost (mostly by vendors). This put a lot of pressure on developers, but it was a lot of fun working thru the nights because it was the newest thing. Wondering how a budget is developed for agile systems?
excellent; at 6:45 - "waterfall was such a bad fit for software that it only succeeded when people circunvented the process!" - I think this fits well with the tendency I see in IT to incentivize "hero behavior"
Software development is a complex social process with people who depend on each other. You cannot predict the exact outcome from the start since things change along the way. That is why agile works so well in producing a good outcome.
Computer science education. The instructors say "Agile is best", show the students what it is, then go on to use a waterfall approach to teach coding.
Yes, sadly true.
thanks for the video, love the style
Wow! What I great video! Third time I view it, strongly resonate to me
Glad you enjoyed it!
I love that, especially the conclusion!
Great video! Also, citing David Deutsch?! Niiice!
One of the many compelling arguments against Agile is their use of juvenile names for the various processes used in Agile. Scrum is a compelling example. Anyone who is familiar with the game of rugby knows the essential elements of the scrum that starts play. A rugby scrum is a brutal and violent physical combat between the two teams. Serious injuries are common. I've worked in technical fields for almost half a century and most of that work has been on teams and in groups for most of that work. Working with these smart, capable coworkers is universally an experience in respectful cooperation. Very much the opposite of a rugby scrum.
Thus, I tend to discount Agile because a fundamental component of Agile is called a scrum.
Words have meaning and turns out that an Agile scrum has almost no similarity with a rugby scrum. Which begs the question about why the founders of Agile choose the noun scrum for this brief, daily coordination meeting. I conclude that they must have an immature view about life in general and work and software development specifically.
"Scrum" is not a fundamental part of agile, it is the name of one common version. Extreme Programming uses the term "Iteration" for a short fixed time-scale piece of work (what Scrum calls a "Scrum").
I agree with you, I don't like the terminology of Scrum much either, and I sometimes joke that the only reason that Scrum is so prevalent is that it is the easiest agile discispline to cheat at.
Agile has ceremonies, rituals, artefacts and banishes people who point out its flaws -- it's a cult.
@@_Mentat Yes Agile certainly does. And, you have to be part of the In Crowd to know all these inane stuff.
Like sprints that are immediately followed by more sprints then more sprints, as if it's possible to sprint a marathon! Terrible nomenclature. And let's not get into the pigs and chickens guff that some Agile practices espouse. So much of the religion that has built up around Agile doesn't even make sense.
Agile itself does, sure. But the practices and implementations and religions and ceremonies and rituals... not so much.
Hi Dave, great video, thanks for posting, I really value your thoughts and perspective on software development. I've never read anything about post agile so i'll have to dig into what the current state of thinking is. I had one question about a comment you made in the video, why do you think what comes next should be more prescriptive than the current state of agile? Is it so we can avoid the ambiguity and arguments in how agile techniques are implemented, or is there a larger philisophical reason you think we need more definition? Keep up the good work.
Thanks!
The reason that I think that what follows probably needs to be more proscriptive, maybe more specific is a better word, is because while I think that the ideas of agile are correct, and that it was a huge step-forward for the industry, the problem is, as is true of all popular ideas, is that they get watered-down as they spread.
The "post-agile" people say that agile was a failure, when what they really mean is that if you apply agile rituals and treat it like some kind of religion with magic words like Scrum and Sprint, then it doesn't work.
One of the problems with agile, in terms of adoption, is that it leaves a lot down to individuals and teams. This is for very good reasons, high-performing teams ARE autonomous! But they are also very disciplined, autonomy alone isn't enough.
So I think that what comes next could improve on agile, not by changing anything at the level of the "agile manifesto" but by being more precise about the guide-rails that steer teams towards what really works. For example, I'd put the metrics "Stability & Throughput" front and centre. "Do all the stuff that it says in the agile manifesto, but measure your progress with Stability & Throughput".
"Stability" measures the quality of our work, "Throughput" measures the efficiency with which we can create work of that quality. These are almost impossible to cheat. So it is not good enough to stand up during meetings and to call two weeks worth of work a "Sprint" to declare success. You are successful when you can improve the quality of your work and work with more efficiency.
Chapeau, a fantastic talk!
Totally agree. E.g. you can learn how in math a complex system has evolved that is still maintainable and expandable. And even if some might disagree, this is system is still teachable to the next generation. Also it is notable that the mathematical discipline shows how a general system can evolve and origin from a special case.
Colin Chapman of Lotus once said 'Simplify, and add lightness'. I think this philosophy can help with software too, when you take away everything that doesn't add to the end product, you end up with a much more reliable, maintainable, and modifyable end product.
Yes, good design is when you can't take anything else away. Elon Musk says "the best part is the one you don't need" ruclips.net/video/v8f6q4ruvds/видео.html
I hope Dave doesn't mind me plugging one of Dan Norths presentations "Why agile doesn't scale and what you can do about it".
It is primarily about how "agilists" and business talk past each other and how developers need to stop focusing on technical things and "standups, burndowns, burnups, userstories, storypoints and ..." and taking a more holistic view and understanding of the business.
Organizations tend to end up in a vicious cycle where they restructure the organization and hire a new CEO/CIO/CTO every three years and start over, while all the senior developers, PMs, etc just gives up, sighs and leaves for "something better" and all the lessons learned are forgotten. Agile (and CD) affects the entire organization, from the sales people to CEO/CTO/CIO to developers, HR and training. Without this understanding, no process or methodology will make much of a difference in the end.
ruclips.net/video/F4b_MckXea0/видео.html
ruclips.net/video/1MedZStiAPg/видео.html (better audio)
No problem, plus Dan is an old friend 👍
Agile is a wonderful solution to a specific set of problems - the ones it was actually crafted to solve.
The problem with Agile is that it's become kind of a religion with its advocates trying to cram it into every possible situation even when it just can't work.
Worse, they tend to promote a very specific, unironically rigid interpretation of Agile and so miss the basics that are right in the name of the approach: being agile.
I tried to discuss with the Agilestias in a factual manner, but failed every time. It took me a very long time to realise that their basic principles was not in accord with mine. I have always thought that also SW should be developed with basic engineering principles as guidance, as this has been proven for hundreds of years. But I came to realise that the Agilestias I worked with saw themselves as craftsmen. I tried to convince hem that that was an old ineffective paradigm to use, and no other technical discipline used it since hundreds of years. But they continued to claim it isn't possible to develop software like cars, buildings, roads etc. In desperation I said that "Agile is a total capitulation to complexity." They just called me old fashioned and continued with "what everybody else was doing" in almost an extatic religious manner.
I eventually resigned and have not regretted it.
I led one of the largest scale agile development efforts for one of the world's largest companies for several years. With a few changes after I took over, we had 12 successful deployments in a row with no failures. (We had 14 SCRUM teams spread across three countries.) This was on THEE most critical software for the company. This was a company wide record (one in a row was the previous record) and received a president's award. So, yes, agile can be done at scale for large scale critical software, but it takes a dynamic model that has 100% company buy in. When it works, it's a rocket sled ride on rails. Previously, it was nothing but a crash and burn, and is frequently the result when companies try to "go agile" but don't understand what commitments are required. Second, there are things that need waterfall development, such as back end services and support functionality which have to be delivered as complete packages. Once that is in place, agile can add functionality to that base. Trying to do both using agile is usually a big mistake.
Thank you for sharing.
Love this one in particular, the gap you refer to at the end is absolutely an issue, we see it all the time where people in the 'old way' of working don't know how their roles / skills adapt to agile practices and behaviors e.g. traditional BAs, Project Managers, Test Managers etc and business stakeholders acting as task masters who fling 'pointless requirements documents acting as blame accountability enforcers'. I recently enjoyed Jon Smart's book which was an interesting read, any other more contemporary resources you'd recommend on this? I am completely opposed to scaled agile frameworks as I think they let people from the old ways continue to act as they did before, they don't think about the roles and the behavior changes and revert to their former behaviors.
Jon's book is the most recent that I am aware of on this kind of topic. I think Lean Enterprise is a great source for this kind of thinking too.
Would love to watch a video about dos and don’ts of requirements engineering for complex systems on this channel. In the industry, I see gigantic efforts/money (wasted?) on analyzing and managing what someone would like in or think about the system. But it often costs much more than the software itself. Even more critical, sometimes the requirements phase takes too long, so that the system/software is never build.
I think that the biggest mistake that most people make is write requirements as though it was "programming by remote control" telling the programmer how to write the code, instead of describing the problem that needs to be solved. I generally reocmmend that requirements should be written only from the perspective of a user of the system and only focussed on what the system should do, not how it does it.
I will do more on this, but I gave some videos that talk about it already, here is one: ruclips.net/video/JDD5EEJgpHU/видео.html
The most proficient teams use a hybrid approach. They use iterative development to allow for right size scopes of work and include some elements of waterfall to inject process into the release cycle.
I am afraid that there is no evidence to back that assertion. In my experience they definitively don't do both.
This is one of best video on agile around, and as mentioned many videos on this topic are simply one big misconception around the concept. Focusing too much on the top or style being one of the most common one.
However, there's one part of the videos I whole heartly disagree. That's "alphabet is a big step forwar from pictographe." The reasons can go on, but let's make it simple. Alphabet is simple just an idea that grown. In comparison, pictographe, or even objectform is not common use or grow more than Alphabet. And how these high dimension form of language can grow into infinity is simple not being explore. We might just be living in a time where these are form of language don't have the best distribution means avaliable, not to say such situation can't change.
Imagine 400 years ago, someone said, "Oh~ math is just good at counting, It can't be use to decribe the universe～“ Again the lack of advancement of an idea doesn't mean the idea don't have the potential.
So what's this mean to Agile? Current Agile concept is only focusing on one goal. and faulty idea is only faulty because of its relationship to that goal. And this is also where Agile start to fall apart, especially when it is apply to a large co, where a huge number of Agility is happening, and there no way to linking them.
Unfortunately fixed budgets stand on the way of proper agile development, especially in government projects where a certain output of functionality is expected within defined budget and without which payment is withheld.
Because - surprise, surprise ! - NOT EVERY PROJECT REQUIRES Agile.
In the 1960s my approach was to knead code rather than writing it. I remember one day I was about to write a program out on paper and realized that I could just start typing in code and expanded it as I understood what I was doing.
As to the alphabet -- the story is far more nuanced because pictographs never really worked well but we like rebuses and used for their sounds and cultural references.
Do some reading on Disciplined Agile, from the "makers" of PMP. I believe it attempts to take on the "what's next" for agile.
Very well articulated.
Outstanding.
Great video - thanks!
I was recently asked, along with a colleague, to hold an "agile fundamentals" type lecture. We explained traditional style projects and what agile was a response to. After that we told them about a lot of names, frameworks etc that they would probably meet out in their work life (scrum in particular did we show the main structure off), but stressed that those were not agile.
Sure, they are used to facilitate agile practices, but it is the practices, the way of viewing and handling things that is actually the agile part.
It is about how you as an individual think about and handle learning, discovery, transparency, why and value etc. Agile is more a way of being than a toolset.
With that said, I like Scrum for instance. Why? It is very helpful when everyone speaks the same language and it helps facilitate the core fundamentals of the agile mindset. Everyone being "agile" and running around doing their own thing would probably negate a lot of the actual benefits we strive to reap the benefits of when we say we want to be agile.
Besides the empirical aspects of agile I also think it brings with it psychological benefits for many individuals and teams. Something that I don't think we should underestimate. The growth I have seen in people when they feel they have more control over their situation and the added ownership that comes from developing your solutions to problems instead of just being told what to do is massive.
Yes, I am happy with Scrum too. It doesn't say enough about engineering or software, it is a PM discipline not a SW dev discipline, so I prefer Extreme Programming, I think it has more profound things to say about the engineering of systems. For me Continuous Delivery is a second-generation XP process.
@@ContinuousDelivery Indeed, probably why Scrum actually works in many non development scenarios :)
But Scrum can be used as the overarching guiding "process", then you can use XP, TDD, Mob programing etc, during the actual development work.
I think the important aspect with any process is to understand not only how we do it, but why we do it.
@@DanielLiljeberg Yes, agreed! My real reservation with Scrum, is that it is too east to cheat, not that it is wrong. XP is more difficult to cheat, because it is a bit more proscriptive in terms of working practices. No CI == No XP!
@@ContinuousDelivery my biggest problem with Scrum is exactly that people who do not understand Agile abuse it, e.g. having the management fix both a timeline and goals, but then still push more work on the team in the name of being Agile. Basically forcing upon the team the worst parts of Waterfall and Agile, while limiting the benefits. I haven't actually tried Kanban, but I feel like it better reflects management needs while forcing them to prioritize requirements.
One side effect of Agile, is actually too many chiefs. The scrum master, is one more boss, that wants to expand his authority, yet, is not the client, not the architect, not the project manager, etc.
For agile to work, it needs a highly cohesive and experienced team. The problem with most projects these days, are that there are too many inexperienced members from the high attrition and fast hiring culture.