On May 20th, BeanStock Ventures brought together a panel of medical device software experts, including Jama Software VP of Customer Success, Clay Moore, to bridge the gaps between modern software development and regulatory requirements.
The topic: Agile development.The panel explored if Agile could maintain its adaptive nature and still being complaint under guidance provided by TIR45, a recognized consensus standard by the FDA.
During the webinar, the panel de-mystifies the idea that Agile development lacks the proper controls for producing safe and effective software and that the regulation is burdensome. They cover a range of exciting topics along the way.
The panel explores key issues about Agile and TIR45, including:
How the Agile Manifesto is trying to encourage us to find the proper balance – not get rid of the discipline and documentation that we need, but to find a better balance between that and developing useful working products.
How the development of a foundation of requirements is the single most important design control activity because requirements which form the design input establish the basis for performing tasks and validation of design.
HowTIR45 helps address common misconceptions about applying Agile at scale with multipleteams, and the need for documentation.
The panel also offers insights to topical Agile questions like:
How does one balance employing Agile methodology alongside predicting project timing accuracy?
“Perhaps predictability isn’t the right word. A better word might be adaptability, that we can respond to changes in a healthy way that still meets the business needs to be predictable.”
-Kelly Weyrauch, Owner, Agile Quality Systems
Does Agile help you tame change?
“Don’t try to tame change. Embrace it as a natural thing of doing product development in today’s rapidly changing world. And Agile provides mechanisms to be in control of those changes.”
– Kelly Weyrauch, Owner, Agile Quality Systems
What’s the right level of regulatory burden?
“It is generally not the regulations that bring the burden. It’s an organization’s interpretation of them. And nearly every case when I see an organization saying they have a burdensome process, it’s because they did it to themselves. They defined their process, they defined the documentation requirements, they defined the sequencing of things and the rules behind it, in a way that’s burdensome.”
– Kelly Weyrauch, Owner, Agile Quality Systems
So much more was covered in this informative session. To see what you missed, head over and watch the on-demand webinar now.
In 2001, gathered together in Snowbird, Utah, a group of 17 like-minded software developers brainstormed ways to quickly build software and get it into the hands of end-users. Out of this meeting the Agile Manifesto was born.
The iterative and incremental methodology of Agile has generally been accepted as a modern approach to software development and has high adoption rates across many industries. However, with fluidity and responsiveness to change at the forefront of Agile’s methodology, many organizations believe that Agile is not compatible with highly regulated industries. Lack of planning and documentation, they wrongly believe, are reasons why Agile cannot work for those building products under regulatory compliance.
The truth is that using Agile for product development within regulated industries is actually true to the Agile Manifesto. Here’s why:
Agile is a Set of Values, Not a Set of Rules
The full Agile Manifesto is a succinct and comprehensive overview of the framework’s principles, and the gist is quite simple. Agile is a methodology that encourages teams to iterate; to communicate with stakeholders, customers and suppliers; to not go crazy with documentation; and to be good human beings at work. Pretty simple, right?
So why do many organizations in regulated industries believe that Agile is not feasible?
While dealing with audit requirements and regulatory compliance, the idea of fluidity and “responding to change over following a plan” may have those in regulated industries cringing. But where in the Agile Manifesto does it say that planning and documenting have no place in your software development process? It doesn’t.
The truth is, adopting Agile values just means you are agreeing to open communication, iterating and focusing on delivering a product. Values are just one part of the product development process – organizations in highly regulated industries can adopt Agile values but still select a stricter framework and strategy to adhere to regulatory standards and document their processes.
And while documentation is not discouraged in Agile, teams are encouraged to view working software as a better indicator that the product meets requirements rather than reams of documentation.
Why Choose Agile for Regulated Industries?
Waterfall has traditionally been a popular choice for highly regulated industries. And yet, the number of organizations adopting Agile now due to very low success rates with Waterfall is rising. With fixed requirements and rigidity as the basis for Waterfall processes, there’s very little room for change and flexibility as requirements evolve.
On the other hand, teams who have adopted an Agile methodology are highly focused on creating products that meet end-users’ needs. And Agile gives them the flexibility to be both iterative and fluid.
Agile methodologies also allow for (and encourage) communication between customers, stakeholders and suppliers. You’ll be able to see in real time what’s working and what’s not and, in turn, keep tabs on what your customers want. By constantly reexamining customer needs and wants, Agile teams are more likely to deliver a product that meets users’ expectations. This, simply put, can be your competitive advantage.
Agile not only makes good business sense but may also help your employees feel happier and more fulfilled at work. Adopting the Agile methodology empowers your engineering and product development teams to change as they need and to use their professional judgement. It allows them to have open communication, to know that what they’re building is useful, and to feel that they are being respected and heard.
Leveraging Jama Connect™ for Agile Documentation
When adopting Agile in highly regulated industries, it’s important that you work closely with auditors — internal or external — to clearly communicate your documentation processes. This is where Jama Connect™ comes in.
Jama Connect is your single source of truth when it comes to complex product development. It allows you to document and communicate your requirements and what you’re setting out to build, and gives you a record of who, what and why things changed along the way. Plus, if you decide to make a change or switch directions, everything is fully reversible.
Real-time collaboration within Jama Connect gives you a platform to discuss change by connecting comments, decisions and reasoning throughout the project. With closer communication (in accordance with Agile methodology), teams experience increased productivity, a shorter design process and critical context for improved decision-making.
Jama Connect provides your team with valuable information to help them decide when and how to make changes.
Is Agile Right for Your Team?
While Agile is compatible with all industries — even those with strict regulatory standards — it all comes down to choosing a methodology that is right for your team. A good place to start is by identifying what values are most important to you and your organization and examining your processes to understand what you want to achieve.
Download our whitepaper, Agile for the Enterprise, to learn more about successfully implementing Agile in regulated and governed industries.
Companies turn to Agile for different reasons.
Heightened efficiency, quicker time to market and risk reduction are all compelling benefits. That’s provided teams can actually stick with the discipline required to make the methodology work for them.
Either way, organizations shouldn’t substitute Agile as a product strategy, according to author and consultant Greg Cohen. Although that hasn’t stopped some from trying.
“You can be so responsive with Agile, you can get away without a strategy in the way you couldn’t in the Waterfall world,” Cohen says.
While Agile as a development methodology can give you a distinct edge in many areas, it’s woefully inadequate as a standalone strategy for market success.
A team may think it can rapidly develop and release a product, for instance, leaving strategic decisions like plans for rollout, marketing, distribution and partnerships until it’s available to the general public. Unfortunately, that’s not a path to profit.
We recently chatted with Cohen, who runs Agile Excellence, and he expanded on this key distinction.
Jama Software: You’ve said before Agile is not a substitute for product strategy. Could you elaborate a little bit on that?
Greg Cohen: If you think about what Agile is, it’s absolutely a superior process for development and working in an uncertain and dynamic environment. And without a doubt a high performing Agile team is a competitive advantage.
So in that sense, a superior process can be part of a bigger strategy. Agile lets you learn, out develop, out innovate your competition — if you can use this process better than your competitors.
But even knowing that, do you know how many times the word ”strategy” shows up in the Agile Manifesto or The Scrum Guide?
JS: Zero.
GC: Right, exactly zero times. And, in that sense, Agile isn’t a strategy. Its creators didn’t consider it that way at all.
And that’s why I wrote this new book that came out in September, Strategy Excellence for Product Managers. Because what I saw was teams were losing the hard skills of product strategy and just sort of relying on Agile flexibility to react to the market. And no longer leading it.
But product strategy is about analysis. It’s a deep analytic, intellectual exercise. And there are five elements in it:
Your customers and their unmet needs
What’s going on in the market – is it growing or shrinking?
What’s your competition doing and what advantages do they have over you versus you over them?
Technology trends – how quickly is it being adopted and how fast is the cost curve dropping on any given technology
And, ultimately, what is your business strategy because product strategy needs to feed into the business.
As the other thing to realize is what I’ll call the instantiated product: what’s coming out of development? It’s only a small part of an overall product strategy.
So product managers need to concern themselves with what we call the “whole product,” which is this set of services that surrounds the product and turns it into a solution.
Because customers buy solutions to their problems. They don’t buy products.
And product managers, therefore, have a lot of what I call leavers to pull to influence the success of a product.
There’s what’s coming out of development, the feature set, but there’s also things to consider, such as:
How is it priced?
How do we promote it in the marketplace?
What are our distribution channels?
What’s the buyer experience before you’re even using the product?
How do we onboard our customers?
How do we train them?
How do we support them and what experience do we give there?
And even bigger things like partner ecosystems, which turn our instantiated product into a bigger solution and fit to solve a customer need.
You have to get all of that right to be successful. So in that sense, Agile addresses the development side. Certainly, Agile-thinking can permeate into larger decisions about how the company structures, does governance and organizes, but it is not a product strategy and no one should confuse the two.
Being one of the people that participated in the creation of the Agile Manifesto, I find myself very disappointed by the reaction of engineers to the question “Are you practicing Agile?” Their shoulders drop. They start to slowly shake their heads. They mumble; they grumble. They tell me agile is horrible. I ask why. Reasons I hear most often are:
We’re being micromanaged
The pressure is constantly on, these two-week deliveries are too short
All they care about is the date
We only have time for cr**py code, we can’t do it right!
None of those management behaviors are part of Agile (read the Agile Manifesto and its related principles for yourself). Unfortunately, the dysfunction the authors of the Agile Manifesto were rebelling against are alive and well today in most places that claim to be Agile.
Too many supposedly Agile shops are missing a lot. They are not even doing plain old Scrum. If they were, programmers would be better off, for example by:
Self-organizing teams manage themselves
Choosing your work lets you follow your interest (sometime you have to take less desirable work)
Committing to how much can be done in an iteration
Updating each other in the stand up. (It’s not a manager update, though they participate.)
Talking responsibility for design and other technical decisions (being professionals)
Facilitate continuous improvement by doing meaningful retrospectives (being honest with yourself)
The motions of Scrum can help, but they are not enough.
Engineers, programmers, developers! We need to build trust. When we ask for three months to deliver, what happens after 2.5 months? We give the bad news that we’ll need an extra month. Bad news late is the worst kind of bad news. Your trust takes a hit. Then it happens again as you near the new deadline. Your reputation is weakened further. It looks like you are really busy now! You claim to be done and then the bugs start rolling in. You fix the bugs and unknowingly break previously working features your customer relies on. Your trust and reputation is in the trash.
Can we get out of this mess?
With Agile, the cadence of delivery is changed, so must your practices change. Kent Beck told me long ago (paraphrasing): “You’ll never be able to figure it all out up-front. You’ll never be able to stop changes even with a signed requirements document and contract defined penalties. Things will change. That’s the world. If you can’t beat ’em, join ’em. Get good at dealing with change.”
Agile 2016
As it turns out, Agile as practiced is dominated with management in 2016. Most the people that were involved with the Agile Manifesto were programmers, doing what they could to make the world better for programmers and the people that need programs.
Programmers, you have a professional responsibility to improve how you work. We (programmers) better get our act together; we’re just a few more software caused problems away from having the lawyers and government in our business. We better learn to be professional, or some lawyer or government bureaucrat will tell us what professional is. Agile might not be the whole answer, but it does advance the state of the art. It introduces the two week cycle and we can and should use that cycle for continuous improvement. Serious technical improvement, not lip service.
Managers, Scrum masters, and POs do you encourage your team to learn the technical practices of Agile? Do you even know what they are and why they are important? Here are two key areas you cannot afford to ignore if you want your team be more successful and make your customers happier:
These are only a start. But they are foundational.
Agile 2017?
That is up to you.
About the Author: James Grenning trains, coaches and consults worldwide. James’ mission is to bring modern technical and management practices to to product development teams, especially embedded systems development team. He is the author of Test-Driven Development for Embedded C. He is a co-author of CppUTest, a popular unit test harness for embedded C and C++. He invented Planning Poker, an estimating technique used around the world, and participated in the creation of the Manifesto for Agile Software Development.
This is the final post in a series examining the changes that have occurred since the Agile Manifesto was published and the implications they have on how we might consider the Manifesto today. Read the first post here and download the full ebook, “A Modern Take on the Agile Manifesto.”
In my earlier posts in this series, I discussed the need to review the Agile Manifesto in light of how the world (and how we work) has changed. I’d like to suggest some recommendations to ensure that product development is optimized to give organizations the best chance of success and customer satisfaction:
Pause and Rethink
Decouple the manifesto from Agile – take a moment to consider the manifesto through the lens of your own surroundings and look your own processes.
Continue to shift the understanding of failure – Look at how you’re releasing information and reacting to the release of that information. If you’re providing some kind of working software, it’s important to understand how you’re reacting to that. What are you doing as an organization to react to that information?
Evaluate your current communication modes – Are you an organization that loves to have meetings? Do you love to talk on IM or email? It may be worth actually recording some data on this and do some research and looking at the results – number of emails and reply-alls. You may find that decisions are being made in those vacuums and people are being left out because they weren’t even aware of a conversation that was happening.
Track metrics – If you do not have metrics, then it’s an emotional game deciding which direction to go in. One risk you run with metrics is misinterpreting the data so be sure to debate then negotiate what the metrics mean.
Think of Agile from an organization perspective – The more we can spread the idea the more it will mature.
Communicate
Find ways to constantly provide visibility – Into what you’re working on – even if it’s in its early draft stages. Sharing early and often is a good thing.
Find ways to allow communication and opinions to flow freely – There can be a fear that the noise level will hinder progress but I have not found that to be the case. I think there are ways to allow information to flow, and if it is found to be overwhelming, you can always work backward and filter it down to the relevancy of it. Having the wealth of information is a wonderful starting point. Your customers could be interacting with you through hundreds of mediums. It’s not valid to say you wish they would not interact with you but more valid to distill the information down to its relevancy.
Identify where decisions are made and captured – Decisions are happening everywhere and they are what cause your product or project to drift – going away from the initial path to the objective for a number of reasons. This will continue to become increasingly important.
Constantly ask if people understand what they are doing and why – There is an opportunity from a company perspective to empower and motivate by enabling people at every level to understand what they are doing and why. It drives creativity, innovation and success.
Evolve
Open up the dialog about culture – If you think this is not your role than think again. If you’re involved in the development and delivery of products you have a perspective and a voice.
Embrace process – Focus on making the process more efficient and understandable. Process gives us guidelines to collaborate more creatively and effectively.
Continue to communicate – Content and data is incredibly valuable if it’s made available in the right place. Having a ton of information is a great starting point, the next thing is figuring out how to utilize it.
Start with too much information then work your way back – Find the balance. In early stages of a product this can be especially true. Having more information will help you eventually develop parameters.
This is the seventh post in a series examining the changes that have occurred since the Agile Manifesto was published and the implications they have on how we might consider the Manifesto today. Find the first post here.
In 2001 the notion was that documentation should be replaced by working software. Of course, back then ‘software’ was a simpler concept. Certainly some was very complex, but overall, software products have grown greatly in complexity. The mindset at the time often was to document everything upfront, then go build, the result was that teams built the wrong thing.
Alistair Cockburn, signer of the Manifesto, has spoken about the word “comprehensive” and the decision to use it. According to Cockburn, this software term was highly debated. The creators didn’t want people to think that documentation in and of itself was unnecessary because they did believe it was important. The intent was to call out exhaustive documentation as overkill.
Today we have more complex software. We also have realities of Minimum Viable Product (MVP) and continuous delivery. The idea of working software is much more of a reality. This does not change the importance of documentation. What does change is the idea of the word ‘document.’ A white board, sticky notes, wiki, or collaboration software, these are all documentation. This is a critical and necessary aspect of the process. The ability to respond to change, to interact, in fact everything the Agile Manifesto believes in relates to communication and collaboration around something – the ideas, stories, epics, and decisions written and made everyday.
This is the fourth post in a series examining the changes that have occurred since the Agile Manifesto was published and the implications they have on how we might consider the Manifesto today. Find the first post here.
In the previous two posts in this series I discussed that the world has changed and software is now everywhere. The third reason for reviewing the Agile manifesto is simply that complexity has increased, both at the product and company level. Building products used to be simpler as hardware products could only handle so many lines of code, and web applications only had to worry about a couple of browsers and monitor sizes, and there were fewer programing frameworks.
In the modern product delivery survey conducted with Forrester, it was found that 55% of companies had over 100 products and 87% of companies had multiple teams working on projects. 70% of companies stated that they release products quarterly or more frequently. 61% of projects had at least four different teams involved, while only 4% of stakeholders were co-located in close proximity. 23% of products now consist of both hardware and software elements.
Today, products are more complex by their very nature, often performing multiple tasks simultaneously, and generally in a smaller form factor. Hardware contains a lot more software; software products need to consider many more devices and situations; and open source has provided the development community with many more libraries, frameworks and languages from which to choose. The range of products available is wider and product development has become more complex. A greater number of platforms must be supported – in 2001 Firefox and Chrome did not exist yet, now there are many browsers, as well as many different devices and platforms on which to browse. That’s not to say there was no complexity back in 2001, but there have been significant added layers of complexity since then.
Many products now have a much greater ‘ecosystem,’ in that they operate in conjunction with other products to enhance functionality. For example, the success of Apple’s iPad was around its ecosystem, that is, the applications that it enables and which enable it with greater functionality. Nest’s vision was not just around home thermostat but more around the broader ecosystem of home control which, bigger picture, was what Google was interested in when they acquired Nest.
When we look at the complexity of companies, technology has progressed so much that we now have the ability to communicate across distributed teams in many ways that were unavailable in 2001, enabling geographically dispersed teams to work together more efficiently, but which can also amplify the organizational challenges of product delivery. There is less a need for everyone to be in the same room, and many organizations have product teams both here in the United States and overseas.
This is the third post in a series examining the changes that have occurred since the Agile Manifesto was published and the implications they have on how we might consider the Manifesto today. Find the first post here.
Today, software is everywhere. It’s in everything we do. We as consumers interact and buy software more than ever, often without even knowing it. In late 2013, Jama partnered with Forrester Research on a ‘modern product delivery’ survey that found that 23% of products now contain software in some form. ‘Disruptive’ technology, that is, innovations that create and markets and value networks, and which over time ‘disrupt’ existing established markets, is increasingly pervasive. For example, Amazon changed the book selling – and everything selling industry – with software. Airbnb is disrupting the Hotel industry. A new generation of tech savvy consumers is helping to drive social adoption and they see disruptive technology as a positive thing.
Established industries are also evolving to adapt software to improve performance. The automotive market, for example, used virtually no software back in 2001. Now we have software working all over our vehicles, from sensors and cameras to navigation to infotainment systems to diagnostics. In 2001, cars had a minimal amount of code in them. A new car now has about 100 million lines of code. What’s more, it is expected that more than 150 million connected cars will be on America’s highways and byways by 2020. We have already seen examples of software being used ‘on the fly’ in remote product recalls. In March 2014, automotive manufacturer Tesla addressed a known fire risk in its cars in part by providing a software update to existing vehicles. This helped mitigate the risk without owners needing to visit dealerships or service centers. Cars are also beginning to connect to each other. The U.S. Department of Transportation is working on a system that has the potential to reduce accidents as a result of an intelligent connected car network.
In the financial industry, it’s becoming less and less important for consumers to have face to face interactions at their bank because of mobile banking, deposits using your camera phone, apps that allow you to budget and transfer money. This has banks deeply concerned. They were not prepared to become a software company. Now they have no choice.
