Mixing Agile and other Life Cycles in Large Scale Complex Environments

Building large-scale software and cyber-physical systems are one of the most complex and challenging endeavors in the industry today. Lean enterprises focus on delivering the right solutions to customers with the highest quality in the shortest sustainable lead time, with the Scaled Agile Framework (SAFe) being adopted extensively throughout the industry.

In most enterprises, however, there exists a transition period whereas some programs will continue to apply the waterfall model and other lifecycle modes, while other programs are moving quickly to agile delivery via Agile Release Trains.

These programs are not independent and some degree of organizational and code level dependencies exist, which can lead to conflicting methods and expectations and jeopardize common delivery objectives.

For this webinar, join Peter Pedross, CEO and Founder of PEDCO-Applied SAFe, as he discusses:

• What mechanisms can be used to help maximize the value delivery despite the unique challenges of mixed agile/waterfall environments
• Ways to increase the collaboration between the two delivery mechanisms
• Various solution scenarios
• Patterns in the area of organizational, architectural and technical solutions, including mockups and designing interfaces, frequent integration, design patterns, etc.

Video Replay

Presentation Transcript

Peter Pedross: A warm welcome from Switzerland. My name is Peter Pedross and I’m CEO and founder of PEDCO. In today’s webinar we discuss mixing agile and other lifecycles in large scale complex environments. I would like to express my thanks to our partner, Cprime, for hosting this session today. It is an important topic for myself as I hear more and more discussions at conferences and see studies about hybrid approaches, where concepts are interwoven and sometimes principles are even turned upside down. However, it must be recognized that it’s often difficult for organizations to go all in with agile for various reasons, such as dependencies on external partners, organizations that are using waterfall, internal culture that requires time to shift to agile or even solutions which have a lifetime or several decades, as we see, for example, in the automotive industry. There are a number of good ways to handle such complex environments and I would like to talk to you today about context and possible solutions.

Before I begin, I would like to introduce myself. I started at the age of 15 to program code for money, have worked in almost all possible positions in the last 35 years from Cobol Assembler, to small program or to tester to project lead software architect, quality manager. I studied also software engineering, finance and management psychology at the University of Zurich. Before I founded PEDCO, I was working at the leading Swiss financial institute where I was responsible worldwide for the entire set of life cycles, processes, methods and tools used for 9,500 developers. We also had to comply with regulations from the Swiss regulations from the Fed, London and Singapore. And we also had to reach CMMI Maturity Level 3 worldwide.
I have published several articles and given several lectures. My first one was about distributed small talk at the IBM conference in San Francisco in 95. And the last one was about scaled agility in regulated environments at the Agile in Automotive in Stuttgart some weeks ago. This is where Mercedes and Porsche come from. Of course, I’m also certified for the Scaled Agile Framework and Disciplined Agile Delivery as well as to European Foundation for Quality Assurance and CMMI. I’m also president of the board for computer science at the Swiss Association of Quality and also a member of the board of directors there. Scaled lean agility s being adopted extensively throughout the industry. Building large scale software and cyber-physical systems is one of the most complex and challenging endeavors in the industry today and for that, I will lay out the context of such an environment and aspect of requirements in SAFe. In this webinar we will discuss some of the different organizational architectural and engineering aspects in order to bring interoperability between agile and waterfall and other lifecycles and why we should bother about such things.
Let’s talk about the project development cycles, and this is something that really triggered me, a few weeks ago. There is a new 10-year study that came out in Switzerland in May. I’m talking about trends and benchmarks in developing software and they also ask about Agile, and one thing that really struck me was that there are some interesting discussions and it is understandable that we see, for waterfall, that 30 and 38 point four percent of the teams within waterfall are starting to apply somehow Scrum and agile methodologies, you also see Kanban, etc. But that they are applying that in waterfall, I think this is a very good sign. On the contrary, in agile, they ask also what kind of method are you using you would expect that you will see Scrum or Kanban or XP, but we still see waterfall usage at almost 24%, which is a number that has increased compared to the last two years.

And this is something that I’ve heard as well at a conference here in Switzerland five weeks ago, where one manager said: “We are going to combine the two lifecycles, waterfall and agile, the good things of waterfall and agile. We’re going to develop agile and keep the fixed time, fixed budget, and fixed requirements from the waterfall. So we will do a combination of both. And this is something that makes me uncomfortable. And it appears there is some confusion happening, so I would like to put that into context.
Why should we bother with different life cycles? We have increasing competitive pressures, high innovation levels and high efficiency, low time to market, and you see that on the right side from all those companies which we have named here, most of them didn’t exist 10 years ago and some of them did exist, but they just have changed their business model dramatically. For example, Apple came out with their iPhone in 2007 and that’s only 11 years ago and that’s currently the main income of their business. Now we have industry 4.0, we have lean startup, agile, and most of the companies are starting agile transformations, even the large automotive suppliers, automotive companies, defense and so forth. And what we see there is they are still working with waterfall: the major number of projects still adopt waterfall.

We model very commonly in the automotive industry the Rational Unified Process, Product Development lifecycle, SDLC, Scrum, Disciplined Agile Delivery, Agility at Scale, SAFe. And when we talk now about cyberphysical systems, which have increased complexity and dependencies, you have to work with teams, probably with suppliers which might work traditionally, so you already are in a situation where you have to deal with such complexity. If you look at agile and just agile, that was built for teams up to 10 people, so that is too small to build complex systems. You need sometimes hundreds, thousands, several thousand people to develop a complex system. Making this even worse, we have regulatory and organizational environments which are becoming ever more demanding and that puts companies at risk of going all in agile. This is a very high risk. They are really considering what they’re going to do with agile. A recent study by Scott Ambler from Disciplined Agile Delivery and he asked if the teams are facing compliance from regulators or organizational issues as well. Results show that 68% of the teams are already facing compliance or organizational regulatory requirements as well. And we see a lot of companies, for eg. one automotive company., they have an average expected lifetime of a product of 24 years, so the future engineers maintaining a solution release today or probably just in the kindergarten, or even better, you’re dealing with a component which was built 20 years ago. If you consider all those issues, it is imperative to have a well-defined strategy and the governance to steer it.
A study by VersionOne on scaled agility has shown that the most extensively adopted framework in the industry is the Scaled Agile Framework. In most large enterprises, however, there is a transition period where many existing programs will continue to apply to waterfall while other programs are moving quickly to an agile delivery and such agile programs are mostly not independent: some level of organizational and solution level dependencies exist. And this can lead to conflicting methods and expectations and can even put common delivery objectives in serious jeopardy.. But we are not talking about only one lifecycle.

There are several lifecycles which we could mix, where we could have hybrid methods, so it shows that about 50 percent of all projects or either SAFe or Scrum of Scrums, And if you take into consideration that some sort of Scrum of Scrums is is included on the program level of SAFe, it is fair to say that almost 50 percent are using that framework. We see that internally creative method then got reduced compared to last year where it was 13 percent, and Disciplined Agile Delivery and Large Scale Scrum were picking up. I think that it’s fair to say that more formal methods are picking up.
So most of you probably are already aware of the Scaled Agile Framework, the number one framework for scaled agility and the assumptive, one pass, stage gated waterfall methods of the past have not scaled to the new challenges, and a new more responsive development method is needed to take on challenges as we presented before. Agile is a major step in that direction. But Agile does not scale to the needs of the larger enterprises and the systems they creat. That is where SAFe comes into play and we see here the so-called full configuration of SAFe. It applies the power of agile, but takes it to the next level by leveraging the more extensive knowledge pools of systems thinking and lean product development. SAFe builds on principles and core values as shown on the right. At the team level we start with a representation of an agile team. We see that agile teams from this level are working in a Program to align their work. They plan together in PI Planning and they align with the various work, Kanban Board up to the Program, large solution and Portfolio level. At the Program level, we have an Agile Release Train and this is a train analogy because it has a cadence, cadence-based delivery, and that is what we think is important for the Program, and that is the core value of Program execution. Then these aligh up to the strategic themes to Kanban of Epic Capabilities, Program Level to the Features, down to the Stories of the Team. And if you want to have cadence, a continuous delivery pipeline, then we need to have no technical debt. And technical debt can be avoided in that we have each system increment with a certain quality delivered, and that it why built-in quality is one of the core values of SAFe.

I would like to show some specific examples based on the SAFe framework, but most things also apply for other lifecycles. A lot of concepts which I will show are in these diagrams and the examples come from our experience with our product, Applied SAFe, that allows to implement SAFe, fast and precisely, as it includes the comprehensive process model with roles, activities, templates, guidelines, metrics, tailoring, milestones and phases and as you can independently instantiate on each level, you can customize with a built in tailoring and run multiple concurrent variations. Of course you can extend, adopt and integrate with your own processes. It includes also the complete content of SAFe and each version is elaborated in sync with the future versions of SAFe and it gets officially approved by Scaled Agile. It includes compliance mechanisms and capabilities for regulated environments as well as in complete implementation of relentless improvement.

So most large scale complex environments deal with varying levels of criticality. They have safety critical to security critical and such areas are mostly regulated and it is necessary to comply with formal standards, regulations, directives and guidance. There’s a plethora of regulations and standards which apply across different regulated domains, but luckily most of these regulations, ask for the same common things. They usually want to see that you have somehow a quality defined, that you have a managed process and an established Quality Management System. They also want to see that you have the execution and continuous compliance somehow on the control, that you have safety and security in place, and if you talk about the FDA, they talk about design controls, how you can make sure that your design is really fitting the purpose of a solution. Most people forget that most or all regulated environments, they ask somehow to manage the process and solution variation, and each endeavor or project, needs to reduce waste, and do exactly what is needed. It’s not ok that you start with the biggest process and just say that all your projects will fall under that. You need to call on the traceability, that is process compliance, but also how you deal with the compliance. A lot of regulated environments also ask you; that is the most striking one that a lot of people forget this, that most of all I would say all the regulated environments, they asked you somehow to manage the process and the solution variations so each end for each project needs to reduce waste and to exactly what is needed. It’s not okay that you start with the biggest possible process in your company and just say all the projects will follow that you need to call that on the traceability, so you need to ensure process compliance, but also how you deal with the compliance. A lot of regulated environments as well product requirements, which are coming from regulatory, and that they want you to base verification and validation on principles and practice and you must know how this is done and defined.

Now let’s move to the topic of solution development in SAFe from the perspective of mixing lifecycles. In our experience, the optimal scenario for continuous value delivery is an enterprise wide deployment of the Scaled Agile Framework, and the use of a common cadence that synchronizes all programs and teams is a key mechanism that enables this to occur well. However, it must be recognized that it’s often difficult for organizations to go all in with agile for various reasons such as dependencies or external partners, organizations using waterfall, internal culture that requires time to shift to agile. As for tho proposed by by safe teams can run with Scrum or Kanban as an agile method. Additionally, it is possible to coexist as team and other programs can choose the lifecycle depending on their needs and their agile readiness. This solution has the advantage to let some teams smoothly adopt agile, well audit teams choose to other lifecycle goes to work with such as, for example, the lean model, the Disciplined Agile Delivery, or waterfall.

This is something that we did at a major Swiss financial company; we had waterfall, iterative, agile, and maintenance lifecycles, all together defined. There are companies with huge process assets and existing quality management systems. There are even companies with, which we have seen, with more than 6,500 standard operating procedures in place and several thousand people working on different solutions, so it is common that the large companies, have a lot of practices, standard operating procedures and it’s also common that different lifecycle models are currently executed in the same company. And for that, we need an agile quality management system that needs strategies, concepts how such an integration and extension can be done. There’s also one practice described in SAFe, which is called technical strategies for agile and waterfall interoperability at scale. Now I would like to go into some of key aspects and first would like to talk is about the organizational aspect of doing SAFe, and we see here quality management systems and organizations.

They must demonstrate that their system meets its intended purpose and has no unintended consequences that might cause harm. They must also develop the objective evidence required to prove that the system conforms to regulatory standards. Then organizations that build high assurance systems, they define their approved practices, policies and procedures in the quality management system. Unfortunately, the quality management systems of many organizations are still heavily influenced by traditional phase-gated waterfall methods and this seriously inhibits or can even prevent the adoption of newer methods. As an example, would be that, as we have seen in the rational unified process, the use of use cases was almost a given and is totally interwoven with the process. So this picture here from SAFe states that also the quality management systems need to be agile as well, and in our case needs to take different lifecycles into consideration.

So, you can expect that the quality management system itself will undergo many more changes than in the past. Fortunately most lifecycle models describe more the organizational aspect of work, so they say how to plan, how to improve, how to build, how to document, but not as much about how something is done with regard to the engineering practice. So you need to show how to synchronize milestones and different cadences of delivery and a lot of companies have even milestones with numbers and just imagine, I’ve seen that with a company in Germany, what does milestone number 7 mean? If you’re new to a company, that’s just not possible to know. So you need some design patterns, like interface to use. You need also to be able to answer what happens with the existing documentation. I you have an application that exists in 20 years and you will find a lot of content there, so what kind of documentation is expected in regards to the solution which you want to build, change or maintain. And regardless of the chosen lifecycle model and the sequence of activities, it is important to ensure that inputs and outputs maintain a consistent state. For example, in the FDA terms, this is called the design control. In our view, regulatory perspectives align well on the value, on the importance of design inputs as the basis for the design of systems, and both align on the value and the importance of the design output that defines the result of the design process in a way that allows the design to be validated. Finally both align on the value of verification and validation, showing that requirements and ultimately the users’ expectations have been satisfied. So what can be different within different lifecycles? What will be the same at the end, the documentation might be produced differently using agile principles and practices, but the finished product might not look any different than it did before agile was introduced. So there is a solution centric approach. So what are the accepted practices to use? We need to start decoupling of release elements.

With that, I would like to show that you also have processes instances and here this is a description, a part of a metamodel and we see that we have process instances which reflect the process description of specific lifecycles, and they even can have different methodologies, so, in some you have milestones in cycles, you probably don’t, and these are all bound to the process. Its elements which we are using, and the process elements of activities of the process, they are organizationally depending on the practice of engineering will depend on the how you build or use something. We see an example, which is a very popular model used, for example, in the automotive industry, called the V model. It has a lot of practices defined on how things get designed, implemented and tested. Most already existing in practices can still be used, but you have to differentiate between the engineering practices and organizational patterns. An example for engineering could be how to define test data, cases that help to validate something and for organizational requirements it could be, for example, how to evolve for the new release and documentation. If you talk about documentation, we see here a symbolic view of a solution centric approach as a skeleton to build up a solution. Each comes with a natural evolution, as an analogy in architecture.

We see here that we have a skeleton, this could probably be a use case model, and each time we come with a system increment, we fill up those blanks here and then we have some kind of a use case or alternating flows which grow into the use case model. We talked about this solution centric approach in detail in our previous webinar about agile requirements engineering. In SAFe and in agile, a complete upfront documentation of requirements is neither practical nor enforceable. So, here’s a possible solution that works regardless of the used lifecycles. It starts with a useful patchwork documentation, and this is based on a skeleton which can be completed step by step following the natural evolution of the solution with each increment. For example, we started with vision and some features that we fill up as well. If you want to do that, somehow, you need the guidelines to build up such an evolutionary and incremental documentation. As an example, one company in Holland, they agreed on such a solution centric approach and what they’re doing is they never fill out the acceptance criteria. They can trace it to the right point in the skeleton documentation. For that, the skeleton must hold all attributes to scale up, to support the needed flexibility and support but most not contain all content in advance. And we have seen that an agile approach is best to comply with.

You see here an element of SAFe called the solution intent. We could consider it as a container for such a skeleton as we have shown before. When building systems that have an unacceptable high cost of failure, one significant barrier to agile adoption is the need for more rigorous definition and validation of system behavior. While many practitioners resonate with the agile manifesto value statement of working software over comprehensive documentation, those can become conflicting priorities for enterprise that really need both. So engineering of complex and highly reliable solutions requires and creates large amounts of technical information. Much of this information that reflects the intended behavior of the solution, features, capabilities, stories, nonfunctional requirements, design, architecture models, for example, electrical, mechanical interface, customer specifications and traceability, which build up the solution and simply, it contains what the current system has now and what changes are intended for a future state. Now, if we remember that we need to have a quality management system which clearly defines what is needed, then you need to redefine very clearly what that looks like. It’s not okay to have several teams, projects or however you call your endeavors, to talk about the same things in different meanings or terms. We see here an example in Applied SAFe where we show the work products and its relations. We see here that the solution is made up of the current solution and the future solution and the future solution is imposed by the solution intent which sets the person, for instance, solution vision. And each time that we develop something from the future solution to the current solution, this is done with a solution increment which is under control with the solution increment definition of done. You see also that the solution consists of several systems and we have here the composite pattern that systems can exist. and can contain other systems as well. We really think that a model like this helps a lot to cut down on these flushing time and how something is meant, and support it with the ALM tools. Because if you have such clear work products and commonalities, we really can implement it with a tool. Now, I would like to talk about architectural aspects and applying different releases. Release frequencies raise nother question: is release monolithic, all or nothing process, and if so, the strategy would be limited. Fortunately that is usually not the case. In fact, even simple solutions will have multiple abilities elements each operating with different release strategy.

Think of the example of an app for a flight booking system. The app can have an agile lifecycle on the top. It is possible to build the system on a streamlet or on a mainframe and this is maintained in a waterfall lifecycle. We don’t recommend this but it is possible. In SAFe, such separate flows of values are called streamlets. They represent a full end to end flow of value, and each streamlet can and should be managed to deliver value according to its own needs and pace, and identifying those streamlets is critical to enable release on demand and as they allow different elements of the solution to be released independently, in a separate cadence. A lot of implementations are also working with feature toggles, but feature toggles are like switches which enable the deployment of features into production without making them visible to the end user. They help avoid the need for multiple code branches and allow developers to deploy new features to production, but only activate them when the enterprise is ready to consume them. And after a feature has been released and deemed stable, the toggles are removed to avoid any technical debt.

As stated in the example from the slide before, that’s how it can be done as defined in the QMS, and you can steer that with, here is an example of the release definition of done, and in agile this is like a contract,, but in waterfall, it might be written within the process description itself, so that means you wouldn’t change the release process in the waterfall life cycle, but you would make it in the release definition of done lifecycle. And in the agile lifecycle, you define the definition of done and then you can have the same behavior, but it’s not the same way.

So, now I would like to talk some about some engineering aspects, and the ability to release on demand is a critical aspect of SAFe, which raises three questions that allow programs to embrace SAFe principles, assume variability and preserve options. The question of when should we release, what elements of the system should be released and which end user should receive the release, and having all three options accelerate and provides flexibility in delivering value, and third, release on demand closes the loop on evaluating the benefits hypothesis,
Releasing provides data needed to decide whether further exploration of an idea is warranted. In the example of the flight booking system, that you that you need new functionality or perhaps a different approach on the mobile device it wasn’t the entered the wrong direction and from that you can have several release strategies that may apply. You can release on PI cadence, release less frequently, release more frequently, or release on demand, but for organizations building complex solutions with systems of systems, as we’ve seen before, fixed or less frequent release is probably always simplistic. Big systems often contain different types of components and subsystems and each of which may leverage its release model. In that case, the most general model is released whenever you want and whenever it makes sense to you, with appropriate governance and business model, of course.

Release on demand requires the quality management system to develop capabilities. You need to be able to decouple the release from the development cadence, decouple the release elements from the solution, and architect the solution to support the incremental releases. The following slide will describe such capabilities. To integrate frequently, we work with mock ups and design to interfaces. Those mock ups allow to test interface assumptions before the system is really available and nothing helps as much as a physical integration. When, as we see in this example, the waterfall team will only deliver working software in the end and then interface becomes the most real thing possible. Mock ups are good when they bridge both to system integration and personal communication gaps between the teams. Mock ups simulate interfaces and should be discussed first during architecture and design workshops. The best case scenario, of course, is when the waterfall teams themselves create mock ups for Agile teams. If this is not possible, the agile teams could do it by themselves, but they need to be carefully reviewed by waterfall counterparts, otherwise they will only test a set of invalid assumptions. So you start design to interface when you’re using mock ups and it is highly recommended to couple the mock up development with the native means of capturing the interface that a program language provides; for example, like interface in Java, etc. So all this will allow developers to simply replace each mock up with real implementations as soon as they are available and if inconsistencies are found, capture them immediately, Frequently integration test the code and the assumptions that went into it, and we show here on the picture, by frequent, we mean far more frequent than once near the end of the project. So, mock up specs for implementation of the logic associated with the mock up interface, So, integration can be full or partial, but in either case, what’s important is that teams integrate and teams fix integration errors.
While realistically this is nothing like automatic, continuous integration as proposed by SAFe, but at this level, it still has immense value, even though it’s on demand, manual and not automated. Good system architects use design patterns in their systems. Patterns are important because of the inherent complexity associated with software development and our inability to predict for the long term. And this is true for requirements, as well as for system design. Certain system behaviors will change for sure over the time of implementation. And patterns, they provide design approaches that are more immune to change and lend themselves better to a refactoring. These engineers will recognize such patterns as they have been named in the book Design Patents, written by Eric Garner and associates. Design patterns such as bridge, adopter, decorator and chain of responsibility are also helpful. They foster a separation of concerns.

Factories foster the use of mockups testability, and the early integration as instantiation of the entities can be separated from their use. Facade patterns foster early validation of integration with legacy systems and so forth. So, consider patterns not so much as building blocks for your system, but rather as ways to isolate variability which will likely be higher if it is dependent on late breaking developments from the waterfall teams. I now would like to summarize are lessons learned from several customers and what we have seen is that mixing of Agile and different lifecycles as possible. For that you need to architecture processes for multiple lifecycles. You need to separate between organizational aspects and solution aspect and because the solution aspect, they tend to be equal for all life cycles. Use design patterns to build independently deployable systems and use architectural features such as feature toggles and switches and so on.

It is key to separate the what shall be done from how something is done. I’ll be done. It’s usually modeled in as an activity in a process model to how something is done. Its usually modeled as a practice or a standard operating procedure and this is not the same, so don’t interweave such activities and practices to hard code how something is done. Build and rely on her aesthetics to model the process for associates and ensure that the practices can be changed or selected by easily by the users themselves, so let them decide if they need a facade pattern. The quality management itself needs to be easily accessible and easy to use it. It needs also to allow fast process changes and piloting appropriate levels. We have seen that more than three months on releasing new processes is not good.
We can’t have a system which only improves its processes once a year visit, just too slow for the uses, so you need to promote transparency for each and they’re more process instanciations and need to be specialized in order to reduce waste. So if you have 10 programs learn, he usually would have 10 different variations of the very same organizational process, but each of them has it. It’s a specific version or specific capabilities of the process. You need to train engineers in emergent design refactory techniques and design patterns and then it works as well. iI’s a very complex thing and it’s undermanned and you cannot underestimate the complexity of mixing lifecycles. even if they’re only agile lifecycles. So you should evaluate if even possible to mix lifecycles.

So though, I heard that a lot of times now that people start off creating their own lifecycle, which they called best of breed and I really cannot put as much emphasis on that. iI’s really underestimated how complex this could be and how those things work together. I really have a great respect for people coming up with lifecycle models. The process because it is much more complex as you could think of in the first one. Don’t fool yourself: if you’re a manager, you can’t mix waterfall with agile to achieve higher outcomes, higher customer value in a shorter time and keep in the same time the projects, fixed time, fixed budget and fix functionality. This is silver bullet, which will not work, as I just heard last month at the conference. And it’s really something that worried me and change value theory from lifecycles and it is really a risk based approach while the whole, in order to avoid this sign variability, this is something that you shouldn’t do because nobody in these days can say what will change in the future and how things could look like.

So I have come to the end of the presentation. Do we have questions?
Myriam Sanie: Yes. Thank you. Peter. I very much want to thank you for providing us with a great set of perspectives on how we can integrate multiple life cycles into a coherent strategy for delivery. So one clarification question that comes from Ben and I kind of had the same question at him when you were talking about decoupling the release from the development cadence, he asks, you indicated that there were two definitions of done. Was there one for Dev and one for release?

Peter Pedross: Yes, but what definition of done? In agile there is a definition of done for a story, but of course in SAFe, it is usual that you have a definintion of done for a team increment, but you have also definition of done for a system increment; you have a defintion of done for a solution increment; and you have a definition of done for release management., of course. And these can be different depending on the solution. And this is the part of the solution centric approach. As you can imagine, if you have a business critical solution to be built which puts your company in danger of going down and the definition of done will be quite different. And verification, validation and documentation will be done quite differently than if you build with the same lifecycles. An application which is not business critical and only only used internally and there are the difference and this can be very elegantly steered, can be steered with these definitions of done. Some companies they have even the code definition of done for capabilities, features and even epics, for example, in an epic definition of done, you will see here that the benefit hypothesis has been validated and the return on investment of the epic will be validated.

I’m hope that answers the questions. Are there other questions?
Myriam Sanie: Yes. Marcia asks: in our organization, we’ve been told we can’t do agile, and I’ve heard this many times, because we’re in a regulated environment. What kind of message could she bring back to her leadership to say, no, this is something that we definitely should do?
Peter Pedross: I couldn’t disagree more with that. This is not true. I mean, agile in regulated environments goes along very well. But of course, as I said, in these four pillars, you need to have a defined process. You need to have those activities in place, roles in place, you need also to show that the processes are complying to the various regulated reference models. For example, you map them to automotive SPICE and you can show them how you do that and then you, build instanciation, so you show that you build your own versions for each and this is what you see in the regulated environment as well. In our experience we have large companies which build cockpits in an agile manner. and they are in a regulated environment and it works very well. You just have to fulfill that you have an established QMS, that you train the people on doing that, that you provide an easy to use QMS, as I said in the last slide, and then it definitely can be done that you have agile in regulated environments, This is one of the key things which we have in Applied SAFe.

Myriam Sanie: Okay, great. Ashish asks they have a lot of hardware in their company and they’re really reluctant on embracing agile. I know that you’ve seen this done in a for a hardware. Any recommendations?

Peter Pedross: At the medical device company, there was a really funny experience. We developed like a blot testing instrument and they were for the big hospitals, where they can do 1000 blood tests in the same machine in one row. And, and what, what we developed was a shaking system and we have to control the electronic blood examples. They need to be shaken. And we had the problem that not the problem it was, it turned out that the hardest thing to change was at the end of the software and the fastest way to change in that prototype parts where the mechanics. So they were much faster than we were. And for them agile was really cool because then they changed, they built a new system and then within one week, two weeks, they had the new prototype running and sometimes we were lagging behind with our software. In my experience it can work very well. If you are big machines then we are not development but we are talking about manufacturing. For development, hardware isn’t that much of an issue as we have seen so far.

Myriam Sanie: Drew asks and actually makes a comment on the compliance a slide and he said that he has an interesting situation where his development teams are doing agile, but team feeling quality management are in waterfall. Is that something that you’ve seen before and a half?

Peter Pedross That happens a lot. It’s that agile is like a grassroots movement, and that teams are just eager to use agile work in an agile manner and that they start up building a lot of teams and there is momentum going, and as long as there are not too many people doing startup building a lot of teams and there’s a momentum going on and as long as there are not too many people doing that and management, CIOs, usually can then just keep it underneath the radar, and they don’t bother about it that much. But as soon as there is a certain percentage of people doing agile, we can run into issues and the quality management system gets involved as well. But I would say to them, to them specifically, you’re not alone and there are extremely good papers defined. For example, there is a paper from the CMMI Institute, which describes mapping Scrum to CMMI and it’s a very good document, and there is an extremely good document from Advancement of Medical Instruments, and it’s called TER45, and this is a paper which describes how you can reach FDA Chapter 11 requirements, design controls, etc. in agile. So that has been proven. And I also have had a presentation at the 2014 CMMI World Conference and it was a clear understanding that agile can fulfill CMMI Maturity 5. And there’s also the Software Engineering Institute in Pittsburgh. They have a very wonderful document about how to reach agile in regulated environments.

Myriam Sanie: Thank you Peter for a great presentation. We’d also like to thank you for taking the time to join us today and we trust you found the session of value. We always appreciate the time you take to be with us and we hope you have a wonderful rest of your day.