Well said ! Agile, properly executed is a good methodology for PRODUCT (software development) not business PROCESS enablement via scalable ERP configuration. If you want to scale business execution fast, don't waste time and money continually iterating core business processes like quote to cash or demand to supply. Back office ERP best practices have already been done- implement them-use them. Once stable end to end don't mess with it. Focus on continually iterating your products to your customers, not the internal processes that should be stable and predictable.
Although in general i would agree, but with around 10+ years in an ISV on the MSFT ERP stack i would argue that even there there are some concerns, using agile by-the-book is not necessarily a good idea. Besides my personal issues with agile and scrum (unclear, less than ideal people management/career paths, often introducing SMs who was have 0 idea about the work the team is doing thus introducing a "noise generator" in the communication chain, not to mention meetings that are sometimes happening to justify the existence of the position, not necessarily helping with a real problem) these are my main problem with agile in ERP and specifically in the MSFT ecosystem: 1- as agile is relying heavily on the feedback loops, based on my experience is very hard to get that feedback loops closed when talking about ERP, meaning its complexity and the effort that is needed from the customer to provide frequent feedback, unless they are specifically interested/invested, most probably during the implementation, while they have a project team dedicated already to these activities, it's easier, but after go-live is very hard to generate enough focus from them, after all they are not making money out of it directly, they primary focus is on their business. 2 - In the MSFT ecosystem with them at the base, ISV's, VARs and sometimes the customers themselves building on top of each other, creating dependencies, following the agile mindset, just like Eric says in the video, without a plan, a design, these parties will find themselves in a perpetual refactor/redesign loop, because of the dependencies below them being moved around -> which generate costs for everyone while not necessarily generating more value. I could give you examples from MSFT over the last couple of years that caused a lot of friction inside the community over this agile approach to deliver technology or functionality in an ERP setting. IF we would refer to as product as the often referred "Spotify way", that's a very different situation, where i would absolutely agree it's a good fit.
You are confusing Agile with specific Agile process called Scrum. Agile is far more than Scrum and it is not always PRODUCT. I suggest more study on Agile rather than being entrenched in Scrum and going around selling it's principles.
In most cases agile is used as an excuse to: 1. Keep changing scope 2. Skipping design and documentation 3. Even skipping writing test plans and scenarios These things are terrible for a product company.
I'm totally agree with you. right now I am seeing the havoc that a poor approach to agile methodology can cause. Just because nobody wants to sit with the user and get the customer´s process blueprints
Excellent video, I agree. You either discover processes while building a solution (very painful) or do the discovery and planning up front. Something that also helps is prototyping, the sooner you can show the user something the better because that is normally where the "light bulbs" go on and the scope creep begins. One thing I have seen in my experience is that change does happen, no matter what.
Nothing said here is constructive or actionable, but sounds awesome in a meeting. If I wanted a consultant to officiate a decision I’be already made, but I am not confident in, I’d hire you in a heartbeat.
10:04 what are you describing here is anti-agile (iterations for the sake of iterations). The proper agile focues on the goals/outcomes (whats), driving factors (whys), and constrains (calendar, budget, tech, people, whatsoever). When this is met, agile beats waterfall hands down
100%! A lot of people don't seem to understand what agile really is. When most people say "agile", they really mean "We'll do ceremonies used in SCRUM". So yeah... anti-agile.
7:26 agile (when done properly) supports that by embedding/weaving tech capability into business units so they can operate seamlessly. And that actually is what digital transforms are about. I.e. its not about building some kind of the "next state" of the org arch/design, but rather about embedding IT into the core of the org. IT becomes the drive train and not a sidecar.
Agile has destroyed user experience. On paper, it should work. User stories are exactly what the user wants and those features are implemented quickly bringing users what they want. In practice though it is different. Programmers are gaming the system. They need to show progress, so they pick the easy things to implement to show they have accomplishments. That is why we so many UI changes, new fonts, new icons, slight tweaks to the UI all called "features" when they are not, they are changes. Changes require training, documentation updates, and user dissatisfaction. By spending time on those easy things the hard things are not done; complex new features, bug fixes, and most importantly, optimizing working features to improve the product. Agile, in my opinion, has only one good feature. It allows you to release software when it is 60% done and start getting paid. And because of this, accelerating the timeframe of when you can start getting money, I don't see this going away anytime soon because the business leaders need the revenue faster. Software used to take way longer and it was during that later phase when the documentation and testing was being done, developers would have time to perfect the product. Keep working on the bug list, tweaking (but not changing) the product to make it run better, and most importantly, ensuring their code is secure. All the things the users want but don't know to ask for up front. I have been heckled in meetings when we build user stories and I put in things like "all features are fully documented" and "no UI changes for 12 months" and "passes all security tests".
I agree, well opened. When it comes to strategic business direction, business architecture capabilities and strategic framework in deployments, Agile is mainly suited for iterative approach roles, when focusing on value delivery.
You put this so well : "If [an org] is going to invest x amount of money in technology" they ask "where's the business value?" and if they 'don't see the business value then' they then don't "invest so much in the technology" . Exactly describes how organisations often try to save money in order to make the ROI math's work, without considering that if you save the money then you won't get the same product.
Eric, This is BRILLIANTLY articulated! I work in US Government where "we" seem to be continuously attracted by "shiny" and without either context or understanding. I have been executing a strategy along the lines you so clearly outline...but I also seem to be alone. Do you have anyone focused on digital transformation in US Federal Government I can connect with. If so, please help connect. I have made some very promising progress but we still need help establishing a solid, and fund-able, strategy, given we're dealing with taxpayer dollars.
I'm working with two(2) military subcontractor manufacturers supporting projects for 2 of the big five of the military complex. Vendors doing business with the government are more Project vs Process Based. There are government Project based ERP solutions better suited than enterprise, commercial discrete ERPs. Process just not in the DNA of these subcon companies as the government and the Big5 have very hard prescriptive rules and requirements to follow. It's a challenge for sure.
Many of my colleagues discussed this very subject 20 years ago (in my "PeopleSoft era"). While a specific workstream like Data Conversion could be seen as a candidate for an Agile approach due to the nature of the activity essentially being a form of rapid prototyping, it doesn't translate across an entire implementation of a mature product that already has a prescribed methodology for implementation.
We move from Agile back to good old waterfall with still some planning called sprint to structure design or build phases. Move multiple ECC systems into one S/4 HANA in Pharma with significant process redesign. The thing we kept was JIRA as tool.
This reasserts that digital transformation is a centralization driver. With that, processes tend to become more standardized, efficient, and harder to change, as was observed by organization research. So it's natural that it goes against the "embrace change" grain. As usual, whether centralization is a success or failure depends on the environment (markets, technology, shareholders), and I can imagine a consultancy becoming focused on organizations in a special kind of environments and generalizing about how things work and how they don't.
I feel that there is an oversimplification of what agile is. Even agile processes have business objectives. Even an experiment should have a hypothesis. There is however a lot of bad agile processes: 1. The MVP with the skateboard to the car will mislead everyone who tries. 2. Don't focus on "Fail fast", focus on "Learn fast" and be clear on what you want to learn. 3. Scrum is not agile. Don't confuse the two.
5:29 here it's confusing "strategic direction" and upfront design/planning planning. The problem with "big enterprises" is the same as with the small ones. They, at best, can barely formulate why they want the change, our what kind of outcomes they are looking for. But they have no clue as how to approach that, what kind of solutions might exist, or hidden interdependencies in their existing processes across departments, branches, brands, etc. And there is no way to meaningfully get these out until you fully dive into that river
2:24 well, agile is focusing on getting the job done, rather than achieving "clear milestones". Speed2value is just an outcome, but not the goal. The true goal is managing uncertainty, where traditional waterfall fails poorly. And digital transformation is just about that, it's always tons of uncertainty
11:43 One important piece here, which is often overlooked. Suppose you're have decided to switch on that new/shiny billing system. Which by itself is not innovative (millions use it already). However, the caveat here is that switch over from the existing system might be pretty much that, as it will require adapt processes, reimplement integrations, migrate data, educated users, and perform zero downtime switch across the entire org. And suddenly such a project turns into a perfect blueprint for waterfall to fail.
I wonder if the people who have commented about Eric not knowing what Agile is have missed the fact that there are plenty of vendors out there trying to sell and poorly deliver Agile ERP implementations to customers. I've seen this happen with vendors who don't have an ERP background and as such don't understand the nature of product and those projects (e.g. people who are used to delivering ERP adjacent products like CRM systems where Agile methodology is the default). Besides that, if they'd watched the full video they would have caught the part where he mentions that an Agile approach is not going to automatically end in failure. There is a time and place for it and that a hybrid (waterfall in the planning phase and Agile delivery) typically yields better results than just waterfall.
6:46 this might be somehow true for the old fashioned organisations. They tend to have more rigidly defined and simplied processes. Even such orgs tend to fail on capturing the formal definitions of the processes they operate, usually there is no a single/central view but even if such exists (say leanix) only IT can use it. However, the main problem here is that many orgs (at least those ive seen) enangae into digital transforms primarily with the goal to make their processes more complex (to empower increasing forkforce capabilties, eg better knowledgemanagement), tunable, and eventually agile. They want the whole enterprise to be agile. Managing BPs on its own level of abstraction (above the code/tech) becomes a really daunting task.
I think you are wrong by giving the fault to Agile. I think your frustration and Agile's goal are the same, better understanding of business processes. You can think of Agile as small steps of waterfall. Idea is let the user to have a feedback on spec asap. Most of the users wish to replace paper/pen with computers but it does not work that way. End result might be same but it is now different technology. If you want to go from A to B, in olden times you use horse, which came with different processes as cars today, today you need petrol stations, car mechanic, roads, trafic lights, etc. you can not use your car like a horse. Agile is a tool and it is an improvement and it is very good tool but to get the results you want, you need good managers.
The points are valid- but i don’t think they are reflective of “Agile”. Waterfall, would have exact same or in most cases the way worse issues. Agile, if done properly would def be way closer and would be a better approach to digital transformation than waterfall- by far… i think he is confusing Agile with just SCRUM, and the mistakes he mentioned can and will pop up in project or program, if the actual business processes are not addressed properly upfront.. this has absolutely nothing to do with agile. The “shiny objects “ in most cases are the promises made by the so called consultants using a bunch of fluff and catchy words.. it’s not Agile, it’s just the poor project initiation and charter- failing to recognize and relate real business value which can possibly be realized within the company’s “environment “.
To me Agile works best when developing something like an App that will be used on a mobile platform where you need to be fast and iterative. In ERP, we are implementing, not developing software, so it really does not have too many places where it fits. As close to Agile working effectively that I have ever seen in the ERP world was when we were developing a modification that where the initial modifications base functionality was designed from a waterfall approach. After that, there were several other iterations that added additional features. Agile enabled us to develop and test faster which each iteration building upon the previous one. Unfortunately, I have seen too many times of late, where the idea becomes all Agile all the time, and it just turns into a disorganized mess.
Agile's popularity in some parts can be attributed to advancement in tech. Adoption of Microservices, advancement in cloud and XaaS, JavaScript frameworks, Web3.0, streaming etc., have allowed piecemeal development, so critical for agile adoption. Without these, say 15 yrs ago, a lot more agile adoptions would fail.
Exactly...for product and software development. ERP today is configuration not customization for process enablement that operates and serves an end to end flow to customer. Once the end to end is LEAN and stable ..dont Iterate it.
The statements here are frequently incorrect and it is not belief because i led with CTO's digital transformation in few financial institutions in New York City. Agile does not destroy, but supplement integrations where development is needed. ERP modules are expensive and do not fit in most of investment and banking places due to competitive edge required by those companies. I know for fact that Goldman Sachs does not use them and I bet it is the same with JP Morgan and another banks. ERP might be used in niche places in those companies. In-house development with Agile is predominant. What is more Agile is not about speed and claim is completely wrong here. Agile is about agility and that means change of requirement as finance is extremely volatile industry with changes coming at rates most vendors of ERP software cannot even imagine. Yes Agile does not fit in some places, but operations software is not the place where it is misfit. On top of that there is a lot of bad Agile (including those who teach it or certify). I learned Agile in bank directly from those who created it and signed Agile Manifesto - not from those who bastardized it and "scaled" to run business as if it required Agile process.
On the contrary, upfront planning can go terribly wrong, whether it's for process transformation or product management. However, the same can't be said for agile methodologies, as you're continually working towards an MVP that demonstrates business value to investors early on. I don't see this as a choice between 'Agile' and 'Waterfall.' A hybrid approach is often the most successful. Even within Agile, we use Kanban systems; it's about choosing the right tool for the job. Traditional Waterfall has its place when the scope, budget, schedule, and quality are well-defined upfront. In those cases, phase-wise program management is ideal. Agile, on the other hand, excels when the processes or the product are still taking shape.
Exactly! As the AGILE Manifesto title clearly states..it's a "Manifesto for AGILE Software Development". ERP is not software development, it's platform configuration not customization or development.
@@JP-ku4rk I think you must be clear on what Agile is, Agile is not ruining Digital Transformation, lack of planning is, seems that you and others think that Agile is lack of planning
It is all about control at the lowest price. Improving is part of the day to day business. What I found out is, that digital transformation, describing and business process development and modeling, can take place with the changes within enterprise architecture, business continuity, performance management and continuous improvement and change management, besides the software architecture, adjusting the ERP system, adjusting the supply chain, risk management, A.I., procurement, data analysis, business intelligence, Human Resources and data science. Besides business analysis. I already have done this either an offshore company and made it besides a high performance organization the cash cow of the group. Do you have the same experience Eric?
Agile is the single worst way to develop software. There is no good way to do agile. Just as there is no good capitalism. There's no 'crony capitalism" there is just capitalism and it's bad. Similarly there's "flavor" of agile that works -- it's just bad. Stop doing it.
When selecting an ERP system, it’s crucial to define your processes upfront and use them to establish clear requirements that you can share with vendors for evaluation. At the very least, they need to show how they’ll support and enhance your value-added processes. Without doing this, you risk choosing an ERP that doesn’t align with your future goals-especially if you’re planning to go agile. In that case, the tail ends up wagging the dog. And trust me, in the world of ERP, you don’t want the dog confused about who’s in charge… unless you’re ready for some unexpected tricks! 🐕🦺
Well said ! Agile, properly executed is a good methodology for PRODUCT (software development) not business PROCESS enablement via scalable ERP configuration. If you want to scale business execution fast, don't waste time and money continually iterating core business processes like quote to cash or demand to supply. Back office ERP best practices have already been done- implement them-use them. Once stable end to end don't mess with it. Focus on continually iterating your products to your customers, not the internal processes that should be stable and predictable.
Although in general i would agree, but with around 10+ years in an ISV on the MSFT ERP stack i would argue that even there there are some concerns, using agile by-the-book is not necessarily a good idea. Besides my personal issues with agile and scrum (unclear, less than ideal people management/career paths, often introducing SMs who was have 0 idea about the work the team is doing thus introducing a "noise generator" in the communication chain, not to mention meetings that are sometimes happening to justify the existence of the position, not necessarily helping with a real problem) these are my main problem with agile in ERP and specifically in the MSFT ecosystem: 1- as agile is relying heavily on the feedback loops, based on my experience is very hard to get that feedback loops closed when talking about ERP, meaning its complexity and the effort that is needed from the customer to provide frequent feedback, unless they are specifically interested/invested, most probably during the implementation, while they have a project team dedicated already to these activities, it's easier, but after go-live is very hard to generate enough focus from them, after all they are not making money out of it directly, they primary focus is on their business. 2 - In the MSFT ecosystem with them at the base, ISV's, VARs and sometimes the customers themselves building on top of each other, creating dependencies, following the agile mindset, just like Eric says in the video, without a plan, a design, these parties will find themselves in a perpetual refactor/redesign loop, because of the dependencies below them being moved around -> which generate costs for everyone while not necessarily generating more value. I could give you examples from MSFT over the last couple of years that caused a lot of friction inside the community over this agile approach to deliver technology or functionality in an ERP setting. IF we would refer to as product as the often referred "Spotify way", that's a very different situation, where i would absolutely agree it's a good fit.
You are confusing Agile with specific Agile process called Scrum. Agile is far more than Scrum and it is not always PRODUCT. I suggest more study on Agile rather than being entrenched in Scrum and going around selling it's principles.
This is an experienced knowledgeable professional person. Brilliantly spoken.
cannot agree more. Have been a firm believer that Agile is destroying the concept of Architecture, Design and Process simplification
In most cases agile is used as an excuse to:
1. Keep changing scope
2. Skipping design and documentation
3. Even skipping writing test plans and scenarios
These things are terrible for a product company.
I'm totally agree with you. right now I am seeing the havoc that a poor approach to agile methodology can cause. Just because nobody wants to sit with the user and get the customer´s process blueprints
Excellent video, I agree. You either discover processes while building a solution (very painful) or do the discovery and planning up front. Something that also helps is prototyping, the sooner you can show the user something the better because that is normally where the "light bulbs" go on and the scope creep begins. One thing I have seen in my experience is that change does happen, no matter what.
Nothing said here is constructive or actionable, but sounds awesome in a meeting. If I wanted a consultant to officiate a decision I’be already made, but I am not confident in, I’d hire you in a heartbeat.
10:04 what are you describing here is anti-agile (iterations for the sake of iterations). The proper agile focues on the goals/outcomes (whats), driving factors (whys), and constrains (calendar, budget, tech, people, whatsoever). When this is met, agile beats waterfall hands down
100%! A lot of people don't seem to understand what agile really is. When most people say "agile", they really mean "We'll do ceremonies used in SCRUM". So yeah... anti-agile.
7:26 agile (when done properly) supports that by embedding/weaving tech capability into business units so they can operate seamlessly. And that actually is what digital transforms are about. I.e. its not about building some kind of the "next state" of the org arch/design, but rather about embedding IT into the core of the org. IT becomes the drive train and not a sidecar.
I love your comments. Gosh you have a good understanding of things. I totally agree.
Agile has destroyed user experience. On paper, it should work. User stories are exactly what the user wants and those features are implemented quickly bringing users what they want. In practice though it is different. Programmers are gaming the system. They need to show progress, so they pick the easy things to implement to show they have accomplishments. That is why we so many UI changes, new fonts, new icons, slight tweaks to the UI all called "features" when they are not, they are changes. Changes require training, documentation updates, and user dissatisfaction. By spending time on those easy things the hard things are not done; complex new features, bug fixes, and most importantly, optimizing working features to improve the product. Agile, in my opinion, has only one good feature. It allows you to release software when it is 60% done and start getting paid. And because of this, accelerating the timeframe of when you can start getting money, I don't see this going away anytime soon because the business leaders need the revenue faster. Software used to take way longer and it was during that later phase when the documentation and testing was being done, developers would have time to perfect the product. Keep working on the bug list, tweaking (but not changing) the product to make it run better, and most importantly, ensuring their code is secure. All the things the users want but don't know to ask for up front. I have been heckled in meetings when we build user stories and I put in things like "all features are fully documented" and "no UI changes for 12 months" and "passes all security tests".
Recent Crowdstrike and Sonos disaster perfect examples
Very well said. Could not agree more. Specially in the case of greenfield projects
Amazing insights and deep understanding to the delivery process that I can't agree with more
I totally agree with you Eric.... now i'll watch the video :)
As a Certified Scrum Master, SPC, and ICP-ACC (agile coach) I’m getting my popcorn ready for this!
This is why companies should switch from Digital Transformation to Industrial Transformation.
Take a look at the work we have dome at LNS Research.
I agree, well opened. When it comes to strategic business direction, business architecture capabilities and strategic framework in deployments, Agile is mainly suited for iterative approach roles, when focusing on value delivery.
You put this so well : "If [an org] is going to invest x amount of money in technology" they ask "where's the business value?" and if they 'don't see the business value then' they then don't "invest so much in the technology" . Exactly describes how organisations often try to save money in order to make the ROI math's work, without considering that if you save the money then you won't get the same product.
Eric, This is BRILLIANTLY articulated! I work in US Government where "we" seem to be continuously attracted by "shiny" and without either context or understanding. I have been executing a strategy along the lines you so clearly outline...but I also seem to be alone. Do you have anyone focused on digital transformation in US Federal Government I can connect with. If so, please help connect. I have made some very promising progress but we still need help establishing a solid, and fund-able, strategy, given we're dealing with taxpayer dollars.
I'm working with two(2) military subcontractor manufacturers supporting projects for 2 of the big five of the military complex. Vendors doing business with the government are more Project vs Process Based. There are government Project based ERP solutions better suited than enterprise, commercial discrete ERPs. Process just not in the DNA of these subcon companies as the government and the Big5 have very hard prescriptive rules and requirements to follow. It's a challenge for sure.
Many of my colleagues discussed this very subject 20 years ago (in my "PeopleSoft era"). While a specific workstream like Data Conversion could be seen as a candidate for an Agile approach due to the nature of the activity essentially being a form of rapid prototyping, it doesn't translate across an entire implementation of a mature product that already has a prescribed methodology for implementation.
We move from Agile back to good old waterfall with still some planning called sprint to structure design or build phases. Move multiple ECC systems into one S/4 HANA in Pharma with significant process redesign. The thing we kept was JIRA as tool.
This reasserts that digital transformation is a centralization driver. With that, processes tend to become more standardized, efficient, and harder to change, as was observed by organization research. So it's natural that it goes against the "embrace change" grain. As usual, whether centralization is a success or failure depends on the environment (markets, technology, shareholders), and I can imagine a consultancy becoming focused on organizations in a special kind of environments and generalizing about how things work and how they don't.
This made a lot sense . Thank you
Greatly articulated Eric. Agreed.
I feel that there is an oversimplification of what agile is. Even agile processes have business objectives.
Even an experiment should have a hypothesis.
There is however a lot of bad agile processes:
1. The MVP with the skateboard to the car will mislead everyone who tries.
2. Don't focus on "Fail fast", focus on "Learn fast" and be clear on what you want to learn.
3. Scrum is not agile. Don't confuse the two.
This guy is selling waterfall. "Agile" is the strawman.
5:29 here it's confusing "strategic direction" and upfront design/planning planning. The problem with "big enterprises" is the same as with the small ones. They, at best, can barely formulate why they want the change, our what kind of outcomes they are looking for. But they have no clue as how to approach that, what kind of solutions might exist, or hidden interdependencies in their existing processes across departments, branches, brands, etc. And there is no way to meaningfully get these out until you fully dive into that river
Thanks very insightful
2:24 well, agile is focusing on getting the job done, rather than achieving "clear milestones". Speed2value is just an outcome, but not the goal. The true goal is managing uncertainty, where traditional waterfall fails poorly. And digital transformation is just about that, it's always tons of uncertainty
Agile is great when making micro-bets used to experiment and see what business outcomes are possible with relatively low risk
11:43 One important piece here, which is often overlooked. Suppose you're have decided to switch on that new/shiny billing system. Which by itself is not innovative (millions use it already). However, the caveat here is that switch over from the existing system might be pretty much that, as it will require adapt processes, reimplement integrations, migrate data, educated users, and perform zero downtime switch across the entire org. And suddenly such a project turns into a perfect blueprint for waterfall to fail.
I wonder if the people who have commented about Eric not knowing what Agile is have missed the fact that there are plenty of vendors out there trying to sell and poorly deliver Agile ERP implementations to customers.
I've seen this happen with vendors who don't have an ERP background and as such don't understand the nature of product and those projects (e.g. people who are used to delivering ERP adjacent products like CRM systems where Agile methodology is the default).
Besides that, if they'd watched the full video they would have caught the part where he mentions that an Agile approach is not going to automatically end in failure. There is a time and place for it and that a hybrid (waterfall in the planning phase and Agile delivery) typically yields better results than just waterfall.
Use agile when you already have a system and want to improve on utilization to ensure better efficiency
6:46 this might be somehow true for the old fashioned organisations. They tend to have more rigidly defined and simplied processes. Even such orgs tend to fail on capturing the formal definitions of the processes they operate, usually there is no a single/central view but even if such exists (say leanix) only IT can use it. However, the main problem here is that many orgs (at least those ive seen) enangae into digital transforms primarily with the goal to make their processes more complex (to empower increasing forkforce capabilties, eg better knowledgemanagement), tunable, and eventually agile. They want the whole enterprise to be agile. Managing BPs on its own level of abstraction (above the code/tech) becomes a really daunting task.
I think you are wrong by giving the fault to Agile. I think your frustration and Agile's goal are the same, better understanding of business processes. You can think of Agile as small steps of waterfall. Idea is let the user to have a feedback on spec asap. Most of the users wish to replace paper/pen with computers but it does not work that way. End result might be same but it is now different technology. If you want to go from A to B, in olden times you use horse, which came with different processes as cars today, today you need petrol stations, car mechanic, roads, trafic lights, etc. you can not use your car like a horse. Agile is a tool and it is an improvement and it is very good tool but to get the results you want, you need good managers.
The points are valid- but i don’t think they are reflective of “Agile”.
Waterfall, would have exact same or in most cases the way worse issues.
Agile, if done properly would def be way closer and would be a better approach to digital transformation than waterfall- by far… i think he is confusing Agile with just SCRUM, and the mistakes he mentioned can and will pop up in project or program, if the actual business processes are not addressed properly upfront.. this has absolutely nothing to do with agile.
The “shiny objects “ in most cases are the promises made by the so called consultants using a bunch of fluff and catchy words.. it’s not Agile, it’s just the poor project initiation and charter- failing to recognize and relate real business value which can possibly be realized within the company’s “environment “.
To me Agile works best when developing something like an App that will be used on a mobile platform where you need to be fast and iterative. In ERP, we are implementing, not developing software, so it really does not have too many places where it fits.
As close to Agile working effectively that I have ever seen in the ERP world was when we were developing a modification that where the initial modifications base functionality was designed from a waterfall approach. After that, there were several other iterations that added additional features. Agile enabled us to develop and test faster which each iteration building upon the previous one.
Unfortunately, I have seen too many times of late, where the idea becomes all Agile all the time, and it just turns into a disorganized mess.
Agile's popularity in some parts can be attributed to advancement in tech. Adoption of Microservices, advancement in cloud and XaaS, JavaScript frameworks, Web3.0, streaming etc., have allowed piecemeal development, so critical for agile adoption. Without these, say 15 yrs ago, a lot more agile adoptions would fail.
Exactly...for product and software development. ERP today is configuration not customization for process enablement that operates and serves an end to end flow to customer. Once the end to end is LEAN and stable ..dont Iterate it.
The statements here are frequently incorrect and it is not belief because i led with CTO's digital transformation in few financial institutions in New York City. Agile does not destroy, but supplement integrations where development is needed. ERP modules are expensive and do not fit in most of investment and banking places due to competitive edge required by those companies. I know for fact that Goldman Sachs does not use them and I bet it is the same with JP Morgan and another banks. ERP might be used in niche places in those companies. In-house development with Agile is predominant. What is more Agile is not about speed and claim is completely wrong here. Agile is about agility and that means change of requirement as finance is extremely volatile industry with changes coming at rates most vendors of ERP software cannot even imagine. Yes Agile does not fit in some places, but operations software is not the place where it is misfit. On top of that there is a lot of bad Agile (including those who teach it or certify). I learned Agile in bank directly from those who created it and signed Agile Manifesto - not from those who bastardized it and "scaled" to run business as if it required Agile process.
I wish more people understood what you just said.
On the contrary, upfront planning can go terribly wrong, whether it's for process transformation or product management. However, the same can't be said for agile methodologies, as you're continually working towards an MVP that demonstrates business value to investors early on. I don't see this as a choice between 'Agile' and 'Waterfall.' A hybrid approach is often the most successful. Even within Agile, we use Kanban systems; it's about choosing the right tool for the job. Traditional Waterfall has its place when the scope, budget, schedule, and quality are well-defined upfront. In those cases, phase-wise program management is ideal. Agile, on the other hand, excels when the processes or the product are still taking shape.
maybe you want to take a look at the Agile Manifesto, since all you said about agile makes no sense.
Exactly! As the AGILE Manifesto title clearly states..it's a
"Manifesto for AGILE Software Development".
ERP is not software development, it's platform configuration not customization or development.
@@JP-ku4rk I think you must be clear on what Agile is, Agile is not ruining Digital Transformation, lack of planning is, seems that you and others think that Agile is lack of planning
Agree
This is the worst ad for a consultancy I have seen in years.
Agile is good for products not for organisational system redesign
It is all about control at the lowest price. Improving is part of the day to day business.
What I found out is, that digital transformation, describing and business process development and modeling, can take place with the changes within enterprise architecture, business continuity, performance management and continuous improvement and change management, besides the software architecture, adjusting the ERP system, adjusting the supply chain, risk management, A.I., procurement, data analysis, business intelligence, Human Resources and data science. Besides business analysis.
I already have done this either an offshore company and made it besides a high performance organization the cash cow of the group. Do you have the same experience Eric?
You wouldn’t design and build a house by writing down a list of user stories would you? 😂
Thank you
Nothing will beat common sense!
😀
PMs are not agile.
Agile is the single worst way to develop software. There is no good way to do agile. Just as there is no good capitalism. There's no 'crony capitalism" there is just capitalism and it's bad. Similarly there's "flavor" of agile that works -- it's just bad. Stop doing it.
When selecting an ERP system, it’s crucial to define your processes upfront and use them to establish clear requirements that you can share with vendors for evaluation. At the very least, they need to show how they’ll support and enhance your value-added processes. Without doing this, you risk choosing an ERP that doesn’t align with your future goals-especially if you’re planning to go agile. In that case, the tail ends up wagging the dog.
And trust me, in the world of ERP, you don’t want the dog confused about who’s in charge… unless you’re ready for some unexpected tricks! 🐕🦺