Call us! 512-349-0334 or (877) INDUSOFT

Thursday Podcast – Agile Adoption with Mario Moreira

This week’s podcast brings us the expertise of Mario Moreira, an expert in Agile adoption who has written several important books on adopting and implementing Agile methodology for software development. You can learn more about him and find his books just after the transcript of this podcast.


Agile Adoption with Mario Moreira


Q: How did you become involved with Agile Methodology?


Well, when I worked in the Open Software Foundation in the early 90s I was introduced to Agile. At the time it wasn’t called Agile, but rather continuous integration or a continuous build and merge tools. At the time I was the build engineer for several of the big projects that we were developing. That required us to do a lot of continuous merge initially. At that time a merge would happen maybe once every two weeks, but we learned that the continuous buildup of changes is actually a problem when you do a big merge like that. If there’s a problem it’s difficult to know whose changes caused it. That led us to continuous build and we moved builds from once a week to once a night, and we eventually go to the point of building on demand. If you look backward, that is actually the predecessor to what’s known in the Agile field as Extreme Programming. That was my first experience with Agile methodology.


I got more into the mainstream field of Agile in the early 2000s. I was able to do my Scrum certification with the co-founder of Scrum, Ken Schwaber. These two areas of engineering and process of Agile led me into the world.


Q. You’ve written several books on Agile methodology. Can you tell us a bit more about them?


The two most recent books are called Adapting Configuration Management for Agile Teams, which utilized my technical expertise, and the most recent one is Being Agile, which helps companies adapt to the mindset of continuous building and continuous feedback. Being Agile is getting a lot of attention because it’s one of the few books that looks at Agile from an environment and a culture perspective rather than just the mechanics. It’s impossible to incrementally build out a project if you’re only going through the motions. You have to really get into the mindset of change and how to incorporate feedback.


Q: Currently you’re working for a company that does consulting for Agile, correct?


Yes, currently I work for Emergn, which is a company that focuses on the latest Agile business and IT management practices. On top of consulting, we are also a product company. We have cutting edge Agile training materials that help companies achieve their Agile goals. One of the things we’ve learned at Emergn is that when you arm local teams in the company with the knowledge, they’re better equipped to adapt to the changes that need to come. So we provide education pathways through our materials depending on the role you have in the company. Our primary framework is called Value Flow Quality. We try to get everyone to embrace Agile by understanding that they need to create value for the customer, they need to improve flow for the company, and they need to improve quality.


Q: Integrators and end users are always creating solution, and currently are using configuration tools like InduSoft Web Studio. However, the waterfall mentality is still in place. What is the industry losing by adhering to the Waterfall method, and why would they want to change?


Waterfall has been the standard for many years. But in research on Waterfall, the biggest finding is that when you collect your requirements at the start of a project and deliver, say, a year later, you can end up very far from what the customer actually needs a year later. Market conditions may have changed or customer needs change, so the gap between what the customer originally wanted and what they eventually need can be very large, and that’s what the waterfall method will lead toward. So instead, we find that customers are looking for more incremental approaches to developing projects. They don’t want to invest a lot of time and resources to developing a product and building functionality that people aren’t going to want.


In waterfall, even in successful projects, 40% of the functionality is never actually used, and 19% is seldom used. So with this method you’re building 64% of functionality that no one wants.


So why change? Any company that wants to be competitive can’t afford to have 2/3 of their product be unnecessary. They should be using those resources to be creating more successful products. By moving these resources to a more incremental model they can significantly increase their chances of being successful in the future.


Q: One challenge system integrators often face is this: How do you quote a project using an Agile approach?


That’s one area where there needs to be a bit of a mindset shift. Because it’s impossible to predict the future, it’s also impossible to determine what will be needed or won’t be needed during the scope of the project. So we need a new rule of thumb. You can set up a project with high-level goals over the course of the project, but use an incremental approach to see how realistic they are from a technical feasibility standpoint and use continuous feedback to make sure that you’re creating things that the customer actually wants. By using that approach you can incorporate management and stakeholders throughout the project so no one is surprised at the end.


Q: Another problem that teams face is that the PLC may be programmed by one group, the HMI or SCADA by another and the end customer might have their own in-house people working on their own tasks. When the pieces are put together there can be some inconsistencies. How do you reconcile that?


This gets into what I call an Agile Release Management Framework.  Even in small projects there are people with different skills in different areas, and you have to keep bringing them together. In this scenario you have to make sure you’re bringing in strong Agile release management. That may be a scrum of scrums with teams working on different pieces. You have to ensure a few things, for example, if any of them are encountering issues from their end, they need to be able to communicate that. You have to make sure that technical challenges are shared and there should be a product scrum of scrums to make sure that requirements that are being affected are known about by all teams so they can make adjustments going forward.


It’s also important to have an integration environment that’s ready from the beginning. That way configuration engineers can begin integrating pieces as early as they’re ready and make sure that the continuous merging is possible as early as possible so we don’t only see the huge inconsistencies at the end.


Q: In that environment, the fixed price project is a stumbling block, and it’s hard to quote a fixed price when requirements may be changing along the way. Are there any recommendations on how to handle something like that?


It can still be fixed price, but you can make sure the customers and stakeholders are much more involved in the demos. So we present the result of an increment, and let them know how this might evolve in the end result. So you can ask if THEY want to change it in the event that it’s something that they aren’t going to want. When you engage them, it becomes a more Agile approach to a fixed price model.  You should operate more at a high business objective level than a detailed requirements level.


Q: How would a traditional change order be handled in an Agile project for an end user or a system integrator?


Agile is capable of having a fixed cost. In an Agile context, you need to evaluate how much time and money it will cost to implement a change. But in Agile, this is usually a very normal part of the continuous development project, because the scope is not usually fixed up front.


So in an Agile development, we will build an increment, get feedback, and then replan. So there’s not a notion of an actual change request, because it’s really just a replan within the Agile framework. We involve the stakeholders and make sure that the replan is really within the goals of the business objective. Changes to the eventual build will happen there in this sprint planning, but the budgets will remain the same. That’s where Agile works very well, in the tremendous amount of planning that comes in increments and throughout the process.


The question becomes “How adaptive do you want to be?” Do you want to be so rigid that the team builds the exact same thing defined a year ago, or do you want to be adaptive? If you do, then incremental planning will take the place of these change orders.


Q: What is the most difficult step in transitioning a team from the Waterfall methodology to the Agile methodology?


There are probably two difficult areas. The first is the mechanics of an environment. If you’re moving to an environment where you need testing right up front, that means a fundamental shift to make testing resources available and testing environments available right from the beginning. Plus there’s more continuous change occurring, so there’s a technical environment shift.


The second is the mindset shift, and grasping the concept of change and deciding to have an adaptive process that adjusts to the needs of the customers and the market. You need to understand why you want continuous change and why it’s necessary.


Q. Mindset is important. So if one company is on a Waterfall approach and has to work with a team using an Agile approach, can the two coexist?


I think people would like it to exist. But the collaboration can be difficult. Teams on a waterfall approach may not be able to share work until the very end, while teams on an Agile approach can begin to share almost from the beginning. So while hypothetically it’s possible, it’s not possible to integrate the Waterfall teams’ work until the end. By doing that you’re not really getting the benefit of Agile methodology. The quality may suffer, or there may be inconsistencies or trouble integrating. However, if all teams are using an incremental approach it’s possible to begin merging this work together much earlier. That’s a better way to handle it.


Q: So to end on advice, what advice would you give to customers who are just getting ready to start an Agile process?


There is a lot of good material out there, but I would recommend starting with my Being Agile book, which really focuses on Agile values and Agile principles.


Let’s talk about how you shouldn’t approach Agile. Many people make the mistake of approaching agile mechanically through the scrum. And scrum is great, but if you’re just coming at it from a mechanics standpoint you won’t really be able to adapt like you might want to.


Also start thinking about why you want to make this change. It should be because you really want to add more value for the customers. You also want to optimize better, faster delivery. You also want to ensure that you’re incorporating feedback loops to build the product you want to build. Just make sure that at every level you’re getting buy-in so that everyone is ready.


If you do decide to go Agile, it’s very good for your career because many companies are going this direction.  It started in IT and software development, but even automotive companies are starting to take a Lean, Agile approach in construction. We are seeing it in healthcare, marketing, and even HR. At the end of the day, the marketplace is changing faster and faster, and every company has to work to keep up with it.



Mario Moreira is an AGILE Coach and Consultant, Executive Coach, Scrum Master, and Engineering leader.  Mario is also an Author and Writer and has worked in the Technology, Software, Product, Architecture, and Methodology fields since 1986.  He has worked actively in the CM field since 1986 and in the Agile field since 1998.He has experience with Agile, CM, Architecture, Project Management, Software Quality Assurance, Requirement Engineering, Methodology, Training, and team building skills and experience.  He has an MA in Mass Communication with emphasis on with an emphasis on communication technologies.  In addition, he holds a Project Management degree from Boston University.


Mario is the author of a new Agile book entitled, “Being Agile – Your Roadmap to Successful Agile Adoption

(via Apress).  It provides a strong focus on the culture change that must occur to gain the business benefits of Agile and provides the RICH (Ready, Implement, Coach, Hone) deployment roadmap that will help you get there with a special focus on getting the team ready for the culture change to the Agile mindset.


Mario is also the author of a book entitled “Adapting Configuration Management for Agile Teams


(via Wiley).It provides an Agile Primer and a CM Primer, infrastructure to support Agile with discussion on Cloud infrastructure, how to adapt CM practices for Agile Teams, evaluating Agile tools, and considerations for standards and frameworks in an Agile setting.


In addition, Mario is also the author of the SCM book entitled “Software Configuration Management Implementation Roadmap” (via Wiley).  It includes step-by-step guidance for implementing SCM at the organization, product, and project levels.


See more here:


Comments are closed.