@Eric Looks like there is some misunderstanding on what Agile is all about and I don't see what needs to be on left and probably right as well. But fundamental concept of Agile is all about building whats right and at the right proportion and right time. and Risks/ Issues I heard about the last point is supposed to be unveiled if Agile practices used right. Glad to explore and discuss on more if you are open! Agile started for one single project team initially, but its no more for small teams and no more built in silos. Hope you've also heard about several scaling practices/ guidelines quite useful for Larger organizations! I also believe we should do the same for other methodologies like waterfall as well to understand how we solve ERP related issues/ problems for the current world!
Its both. For the “out of the box” side of the implementation use waterfall, for all of the customizations use agile. From my perspective, ERP implementations are the conceptual modeling of processes, to be successful the business processes need to be documented, made lean, integrated and coherent before even speaking about any sort of automation. No single business is like another, in other words there is no cookie cutter approach, so unless the business agrees to radically change its processes to the vendors way (which almost never happens) then customizations with agile methodologies like Scrum make somewhat certain sense. But even with the fanciest most expensive solution and methodologies in the world if the processes are crooked (what i believe you mention as misalignment) then the chances of success are quite minimal if at all, waterfall or agile alike.
Such an important point and it is a foot in the door, and customers need to know about the future comitment it leads to. The overarching process has to be waterfall as the steps has to be locked in a given sequence to acheive alignment. SureStep was a waterfall methodology and had an agile subset that could be used if needed. Microsoft has for the last three years suggested Conference Room Pilot.
Thank Eric for the video and comments. I thought I was on the wrong train with the project I am engaged in at the moment. Apparently not. The agile approach has lead to the dismantling of the silos, but lead now to even more silos and everybody is sprinting alongside in its own lane. And I see a huge wall across the finishing line.
This is interesting feedback -Thank you for sharing! I hope your team figures it out along the way and clears the wall at the finish line. Let me know if you would ever like a sounding board along the way.
I agree with your opinion (last 2 minutes of this video). I want to add one point, wherever coding is involved to customize ERP feature, some agile practices can be introduced. For example, one of my ERP projects I used Kanban and TDD for customization (where coding required) and 3rd party software integration.
Very interesting but in real life I have never seen such a project starting with just one small module, and not considering the global requirement right from the start. The Agile approach as such, is only used for the "build" phase, it's a good method because the customer (project sponsor or application owner) is regularly involved in the project, which reduces the risk of gaps between user requirement and the final solution.
I cringe when people say we are an agile shop and we will implement our ERP that way. I've been doing ERP implementations for close to 7 years. This is how it goes: Project Structure is waterfall, customization, personalization, and modifications via agile light methodologies. End result = implement a hybrid style. There are tons of caveats to this such as: if the industry is controlled (example government regulation), the project approach will lean more waterfall to ensure all critical requirements are captured, but you can still apply agile in other ways. People are stuck with it has to be this or that, it can be both if you have a smart team that understands what is going on.
I see your point, but I think the agile minset for a business goal of "creating an enterprise system" is not to do one full all the way erp model at a time (e.g. finnance). it would more likely be to make the minimum needs in all required modeles first so that in case of project faliure (to meet the buisness goal) the cost will be at a minimum. agile is about reducing uncertinty, if there is low uncertinty in the rollout a more classical project approch may be better i guess
Agile is based around the work structure originally used for the terracotta warriors. One major difference at the end of the sprinter if it wasn't perfect the person responsible was beheaded. Back then it worked perfectly!
I believe scaled agile methods can deal with most of the problems you have pointed... So its not Agile the problem but the way it is getting done... Problems will always be faced in both sides... But I got your point and it is a great video! Brings a lot of reflection. Thank you!
Eric, I think you are not touching on the key reasons why Agile is good here: I would list things like radical customer focus, incremental delivery of value, regular cycles of reflection and inspection for purposes of improving the approach, and centering on people over processes. How these attributes might benefit an ERP implementation is a different question than "if" they would benefit one. I suspect there is value to be explored here. For example, far too many ERP implementations begin with a master plan that includes every step and its associated timing. When this plan inevitably proves inaccurate, those involved are often inclined to call the project a failure. An Agile approach would not put so much emphasis on the plan, but rather prioritizing the work and defining incremental value delivery points.
We are using a mixed approach of Agile and Waterfall - Our Build activity is being broken down into multiple sprints and after the build we are blending into Waterfall methodology.
We have similar approach for Agile. The Baseline config forms the 1st sprint. The customisations [RICEFS] are done in subsequent sprints. .. it helps the Users gain a view of the customised solution being built. All said... I have seen some really well managed Waterfall projects deliver equally good value to the customer.
This is a great video. I can identify with a lot of the downsides raised here in our own implementation, specifically the point on "let us start with Finance".
Completely agree. Other issues with agile methodology are: - The implementation team keeps so busy configurating and rushing forward that does not have time to stop a watch the entire picture as a hole. - create a bias to solve deep problems with workarounds instead to rebuild and correct the issues in a correct funtional and technical manner. - The seniors consultants with the best and deep knowledge in SW implementations do not have usually a good handling of Agile methodology. - This Agile concept is used frecuently by sw companies and SIs to offer unrealistic implementation times to clients with complex processes.
Great content. I will add, for strategic planning of ERP implementation traditional process would work better, but for roll outs and customizations Agile might work better.
I am watching this video to learn about ERP implementation, this is for an assignment. I am a Supply Chain Student. Thank you, very helpful information. Gracias guapo!
MVP is NOT agile. It is Scrum. Scrum isn't agile. It is an framework which enables an agile approach. Agile is a Mindset and an attitude. Simple example: My grandmother was agile. The family was poor during WWII and therefore shehad to manage the household including keeping the family dressed and to get them something to eat. Foodwas a rarity during the war. By managing and solving this problem, she needed to think and act flexible. Also called agile. Agile also means to be brave, curious, open and creative. Flexibility also means not to blame and/or freak out when mistakes are made or when a plan doesn't work out. It means that one have to understand, that mistakes are a source of information from which one can learn and improve and where a new approach can start. Scrum enables, due to it short iterations, to discover impediments quickly, Saves monex and time. A digital or an agile transformation is, first of all, based on a healtthy company culture in which trust, empathy, esteem and respect are lived.
Interesting , but as member of Agile alliance i say maybe scrum fails in your case , because client not ready for short feedback loops. I like Agile and Scrum , because it allows to keep in check with client and there no big design upfront, sure with ERP its difficult because you have vendor "design" which you need to use and in case of SAP with less modularity i assume it undervalue the client expectations and the most client think well it can't be good . My advise try out Kanban i think it would be more applicable for big ERP implementations.
TOFAŞ-FİAT group in Turkey, where all production can be managed with kanban with good planning. You can even plan the production in all group companies.
We have done this in MARTUR-ÜSTÜNBERK company working in TOFAŞ-FİAT group in Turkey, where all production can be managed with kanban with good planning. You can even plan the production in all group companies.
Eric - Totally Agreed. Agile fails to consider holistic solution of organization / Enterprise. Definitely there are advantages with Agile but this wont fit to the extent of ERP. I have seen in couple of projects where people work in independent or silos mode and ultimately led to lot of issues. Integration and communication with other modules / Streams will be challenging. As mentioned in last 2 minutes Agile works during development phase not on every stage of project.
There is no clear cut between so-called “agile” vs “water fall” when it comes to ERP applications developments (or implementations whichever you prefer to refer to). If you adopt agile, you also take organization's big picture into account from the start of the project, and you design your information applications (modules, programs, functionalities, packages... whatever you prefer to call it) step by step. Designing applications step by step is in fact “water fall” according to its definition. If you adopt water fall, you create your applications from scratch if you are developing a new information system for the industry you don't have pre-made applications. In such case, you are also adopting agile. Every once in awhile a new jargon like “agile vs water fall” appears. I found myself wasting my time trying to imagine the meanings of each of these new jargons and then trying to join the debates lured by scholars, who I believe have pressure of publishing annual paper in order to retain their jobs in academia, and alleged experts.
The closest I ever came to agile in ERP is we developed a major modification to the software and rolled it out. Subsequently, there were several later enhancements to this modification. This allowed us to first get something live fast and as soon as it was in production started making incremental improvements to it. Each of these iterations served as sprints and we were able to essentially build on the past development and test scripts with each one. It also allowed us to see problems that were occurring from a user perspective that we did not anticipate in design and address them in the next iteration. A situation like this, is probably about the only case where I have seen where agile can work in ERP.
Hi Eric. I found the content of your videos pretty useful. I´m very interested to get in contatc with you to some buisiness matters. Thank you for your sharing
Most of us are carried away with Agile being a method, which it is not. It is simply a set of principles that is the foundation for an Agile mindset. Choose Agile mindset and adopt it to your needs and context. Leverage the tools and methods as an where applicable.
Thank you Rupesh, you correctly defined agile where others appear confused. If a vendor uses agile as a "buzz word" to sell a half baked cloud solution, that is not an indication that agile is bad for ERP, but rather that the vendor is hiding something. Agile is NOT a methodology, and neither for that matter is SCRUM, or even SAFe. For clarity and the benefit of others...Agile is a mindset, Scrum and SAFe, are frameworks, and TDD for example is an actual methodology. If your reaction to that statement is ..."that is a distinction without a difference" then you should probably stick to doing really simple out of the box implementation projects, using waterfall. Suggesting that agile is better suited for such is like saying the bigger the project the less adaptable it can be. Try selling that to an enterprise CEO.
Thanks for an excellent video Master Eric. I use my own hybrid model the include the framework and the context definition at the beginning and the agile development with countinusly releases after that similar to what you explained at the end of your video. Therefore I am against pure agile model for ERP implementation that includes a number of ISV products and Integration points.
I like Agile as an alternative to the traditional SDLC. But ERP deployments require formal negotiations and agreements that are rock solid to actually work...and you cannot “wing” that.
Either approach could work for CRM. Agile is more of a problem for ERP or broader enterprise initiatives, but could work for more focuses projects involving CRM.
Agile is definitely a bad idea for ERP implementation as most of the business function must be implemented mostly 95 percentage. Cannot start with minimal viable product. I am bit surprised top guys how they push agile when business wants entire business process and cannot leave out 50 60 Percent.
@erickimberling What is your opinion of SAFe? The assertion made is that it caters for all sizes of *software development* projects although the "case studies" listed by their website are predominantly *software implementation* projects, claiming great results without explaining how or the baseline of the measurement. The framework, which is neither a methodology nor process, is logical and well developed and think it's very cool if lead times of all kinds of projects can be reduced through the application of ideas without a trade-off in quality (correct outcomes with an efficient process that matches the organisational culture). But it essential to understand the detail of exactly how this is actually achieved. What I find disturbing, because it demonstrates a complete lack of understanding, is that companies who do not develop software and are undertaking Digital Transformation (either ERP or an ERP upgrade) through the implementation of software e.g. a global pharma business, are looking for project managers with SAFe and Agile certifications??
I challenge the idea that agile even works for software development. Software development projects are known among the larger project management community as the single most industry with worst record of going over budget over time defect rate least customer satisfaction. And that has only gotten worse with agile.
