Archives

Its not what you wear. Its how you wear it.

Photo by country_boy_shane

I have to thank Tavi Scandiff-Pirvu for coining this expression as it relates to regulated software development. As long as you use industry standard methods, the FDA allows you to determine the rules that you are going to follow. If you want to have 15 exhaustive steps in order to build each piece of functionality the FDA will say, “Go do it. Just document each step as you go.” If you can reach the same quality in only 7 steps the FDA will say, “Go do it. Just document each step as you go. The FDA isn’t going to test your software in detail. They are going to test your process to ensure that you did what you said you were going to do. This may appear that the FDA is interested in the product but only the process! But, the FDA also wants to see (via documentation) that you built the product features you claimed you had.

The criminally minded will see an opportunity to claim they did more than they actually did via documentation, but in reality do less work. However, there is a natural equilibrium via the market. If you cut steps you will likely pay for it in your product via poor quality and sales. In the end the product has to work. Also, experience shows that it generally takes just as much time to design, create the documentation, necessary traceability and tracking support as to do the actual work. Inefficient? Slightly, but we are trying to sustain human life – not make a quick buck. Its not just about the money. Finally, a big picture analysis shows that it is cheaper for everyone to document what you did rather than pay somebody from the FDA to be a part of your project on a daily basis.

Don’t cut corners, or change your process, once you define it just to save time and money!

My final thought is that in order to do good process design (the 7 step version vs the 15 step version) and thorough documentation you will need to know your organization and team well. You will also need to know the product well so that you don’t design a seemingly efficient process that is blind to the needs of the market the product will be launched in.

Sorry kids. Nobody ever said it was going to be easy.

Lets be honest: Checklists aren’t the most exciting topic to blog about. However, in the context of regulation they become interesting. Everybody loves checklists and hates them at the same time. It’s really easy to make them and just as easy to forget to use them. Later on, after the emergency and/or reason they were created has subsided, using the checklists becomes a ceremony – something that must be done rather than a helpful tool. Checklist also may foster an anti-change mentality and allow people to cruise through their jobs without think about them. This is why we all hate them.

Photo By: adesigna

All feelings about checklist aside: If each detail of your project’s history is going to be scrutinized, checklists are essential. On a regulated project their are a lot of steps to follow. It’s hard to remember each step of each procedure followed. Its really easy to finish delivering a feature then forget to check the software verification report in to your document management system. Once this occurs it looks like you didn’t test the feature before checking it in. Worse, you moved on to the next step of features and never turned in the verification report ever. 9 months later an auditor finds it and you have to doubly prove you did the testing and that you didn’t miss any other steps someplace else. Nobody wants to be in a position where they are on the defense. Often a missed step means all of the testing and tracking is nullified.

There are number of things you can do to ensure you have good lists and they get used often.

• Make them short – A 10 page checklist is not going to be used properly or use up time at the cost of efficiency. Train your staff. Don’t rely on process to get quality work.
• Have less steps – Can you tighten up your process and simplify it?
• Create checklist by role rather than at stage gates – The list will be shorter and highly focused on what matters to the person doing the work.
• Have the team members create their own checklists – They can identify the handful of tasks that are at risk of getting missed. That’s your checklist!
• Review checklists often for new procedures and question why each step exists often.

Finally, keep in mind that whatever you put on the checklist becomes part of your project documentaiton history. Thus, you must do every item on the list every time you run through a procedure. Think carefuly before adding things to a checklist.

Next up: Functional Testing vs Technical Testing

The FDA states that a medical device is a product that is used for medical purposes in patients, in diagnosis, therapy, or surgery. As opposed to a pharmaceuticals, who use the body’s metabolism, medical devices act mechanically or chemically. The FDA’s role in this is to assure the safety and effectiveness of devices. Keep this in mind while going through the process (they are not just to make your life hard).

Photo By: birlewphotography

From a software developer’s perspective, there are three classes of medical devices the FDA regulates. You should know what kind of product/device you are making very early on – before you start planning the work. Their are legends of companies that have outsourced development only to find that their partner had yet to take a device to the point where the FDA would audit it. An even worse scenario: they had done the work with an offshore partner who didn’t fully understand FDA requirements and couldn’t prove traceability nor pass an audit. Whatever cost effectiveness a company offers, make sure its not going to be at the expense of doing the project twice.

Class I

Class I devices are not intended to be used for supporting life. As such, they have the least regulatory controls. Product development efforts lend themselves well to utilizing Agile practices. Do some research before you start development though. About 74% of devices are exempt from pre-market notification in the first place. Those that aren’t, might fit into an existing device panel. Often a few pages of documentation will suffice to pass pre-market approval for Class I devices. To find out more go to the FDA’s classification database.

Class II

For Class II devices, the FDA recognizes that general commercial quality control and manufacturing practices alone may not be sufficient to assure safety. However, they state that “existing methods” are in place to prove safety. You will still have to prove this to the FDA. Simply put: If you follow a process, and document it, you will be able to prove the device you are creating is safe. Rely heavily on documenting the history of the project well. The project will be characterized by significant documentation and process compared to a “normal” Agile project. Because Agile is quite new in the FDA space, you will probably need a seasoned compliance officer with FDA experience. Plan to get audited. This doesn’t mean that utilizing Agile practices is difficult or shouldn’t be done. In fact, because so much time is spent on each feature of the software, I would argue that efficiency and managing waste become critical issues. Attacking risk and focus on delivering the highest value features first is key here. The team just can’t be sloppy with process or documentation for this type of device.

Class III

Class III devices are new or are used to sustain life. The team can’t rely on existing methods to prove to the FDA that the device is safe and labeled correctly. Time to market will play a part, but software development isn’t likely to be on the critical path of product development. The raw science and research are likely to take up most of the product lifecycle. Is agile right for R&D? That’s a topic better covered in another blog post.

Given the wide range the FDA has in place, the life of your product development team will be greatly affected by the classification of the device you are creating. In my experience, working on Class I and Class II devices often feel like working on a “normal” Agile project – assuming your Agile process incorporates enough controls to document the process itself.

Next Up: Keeping Track with Checklists

Photo Credit: LucaDeravignone.com

We have all heard that developing software utilizing Agile principles yields high quality, working software in customers’ hands quickly. It is widely believed that utilizing Agile practices leads to better, cheaper software than waterfall methods in most instances. However, those who write software that must be reviewed by the FDA know that, at first look, the FDA regulations run counter to this approach. They lend themselves well to a heavyweight waterfall process with big design upfront and heavyweight documentation. How can you gain the benefit of optimizations such as minimal documentation, a lot of verbal communication, rapid feedback loops, collective code ownership, rapidly pivoting the product based on customer development, reduced waste and increases speed of development?

Can you get the benefits of agile in an FDA regulated environment?  Yes. We are doing it right now. I’m going to be talking about how over the next few weeks.

Next up: A Brief Discussion of Methodology

(Creative Commons Photo By http://www.flickr.com/photos/meddygarnet/)

There was a post over at the Garlicsim Blog that I found simple but powerful. The idea of it is that, ‘the toy will win.’

photo credit: Jeremy Levine Design

It’s important to have a common vision and shared values in a company like Pathfinder. We often talk internally about what we value.

A frequent topic is valuing things that are designed as opposed to merely built. The obvious example is the iPad vs. the Android tablets emerging now. A more concrete, less virtual, example is a house. You may have experienced one where the whole and its parts were purposely designed, as evident in the durable choice of materials, comfortable spatial dimensions, a sensible floor plan, appealing surface treatments and manicured surroundings. Both the inside and outside are made beautifully with a timeless style. Then you notice the thoughtful features like large windows situated on the south and west sides to help utilize the sun’s heat in winter, or trees and overhang roofs to help keep the internal climate cool from the summer sun, or air circulating effectively such that the fireplace actually warms the house as opposed to being a static ornament. What makes these desired outcomes remarkable is the architect’s attention to detail and thinking through how each part of the house will be utilized.

At Pathfinder, we recognize, appreciate and strive for good design. We incorporate it into every app we make. Because of this, our apps aren’t just a flat list of features that our clients pay us to implement, but are fully viable products, designed like a house we would enjoy living in and cherishing its sense of craft, from the inside out and vice versa.

In Reflections on Management: How to Manage Your Software Projects, Your Teams, Your Boss, and Yourself Watts Humphrey presents a number of essays discussing how to manage software projects, teams, bosses and yourself. It’s a short read even though it’s 240 pages. From Watts’ bio it’s clear he has a lot of experience with large software projects. He was at IBM for 27 years and through his time with SEI he helped define what would become CMMI.

The book encompasses 8 essays that can stand alone or can be read together as a book. They start out discussing projects in general and move to a more personal career perspective. The first thought I had on reading the first essay was this isn’t a book about Agile software development. I found this unusual given how mainstream Agile software development has become and that IBM claims they are using Agile practices on enterprise projects. I don’t mean this as criticism or a flaw with this book in any way. It’s actually the main asset of this book from my perspective. The book has a lot of advice I have come across before, but it’s presented in a slightly different way than one typically sees. There are sections titled, “When you can’t plan accurately, plan often.”, “Make two kinds of plan: Period and Product”, and “Teams can perform better than individuals”. Translated into Agile speak he is talking about adaptive planning, release planning vs iteration planning and focusing on team interactions over process. This is what I like about the book.

When I’m coaching experienced software people on Agile software development, I often find them saying, “Most of this is what I already do.” They are right. Most Agile practices aren’t new. They are good engineering practices that successful software teams have been doing for years. XP, lean, whatever you call them, can be defined as collections of best practices following common principles. Agile is usually an easy sell for developers. Unfortunately for managers who come from a large organization that manages via command and control (which is most corporations), Agile principles and practices feel significantly alien. They seem to give too much control to those who have little experience with it. Most resistance from managers sounds like, “if I didn’t drive/manage these folks, they wouldn’t be productive”. Having been a manger in a few large organizations in my past, sadly, I can say this is actually true. It’s not the individuals’ fault. It’s the managers.  Command and control doesn’t give the individuals the proper background as to why they are being asked to do things. Look at it this way: If I give you a stack of work and say, “this will help to bottom line.”, you will do it. But, if I say, “I’m trusting you to figure this out as it will help us with the strategic initiative the CEO was talking about in the quarterly meeting. If you do this you will be helping our main strategic initiative this year and possibly get noticed/get a promotion/justify a raise, etc…”, you are going to rock it. In large organizations the doers are rarely involved in decision making and thus have very little context as to what business related problems they are solving.  Agile management turns that on it’s head and only presents features to doers with the business value the solution will achieve. For those acclimated to command and control management: How do you get them to shift their mental paradigm to having the doers be part of the solution process?

The book presents good management and good engineering practices. It happens to be the case these are good Agile management principles too – without all of the Agile terminology. This book will present good practices in a non-threatening way so that an Agile manager and non-agile manager can find common ground. This book goes a long to to answering, “What is agile” without confusing and scaring people away with jargon and religious fervor over the “best” way to do things.

If you are a manager at a large organization, I can say this book will give you some helpful ideas what to try next. If you are in a large organization and want to learn a little bit about Agile principles and practices: This book will help – although I don’t think its the intent of the book. If you are a developer trying to get your management to consider utilizing Agile practices: After utilizing the practices and principles in this book, when you present Agile management practices to your manager they might say, “I’m already doing that.”

In Making it Big in Software, Sam Lightstone has the ambitious task of giving you “all the information you need to jumpstart your software career: the best ways to get hired, move up, and blaze your way to the top!”. It’s an ambitious claim.

In Succeeding with Agile, Mike Cohn gives organizations a handbook for how to succeed using Agile practices and principals. If you are picking up this book, keep in mind that he assumes you have some experience with Agile before you begin. He starts the book by presenting some agile adoption patterns then discusses how and why those patterns are resisted by individuals within the organization. Next he spends a number of chapters explaining new roles and how existing ones change in an organization after agile practices are adopted. I particularly like when he describes a practice, or role, in detail; then steps back to discuss how it will affect each role in an organization and how to overcome resistance. The remainder of the book covers additional topics about agile adoption that aren’t large enough to cover a chapter themselves. By the time you get to chapter 20 he is discussing “Human Resources, Facilities, and the PMO.”  I especially liked the end, “You’re not done yet.” – these practices are always evolving and growing.

I think this is a great reference and guide.  However, my only real disappointment with the book is that it makes agile adoption seem very complex and scary.  If you think about it, you have to be a pretty large organization before “facilities” is powerful enough to get in the way of adopting business practices. Having read a number of Mike Cohn’s previous titles I feel he is now writing for large organizations only. Of course, as larger organizations are beginning to take Agile seriously this kind of book is necessary.  Thus, my guess is that this book will be quoted in many conference rooms in the future.

Conclusion

This is another book that I wish had been written 5 years ago since it would have saved me time explaining the “big picture” in coaching situations. If you have been building software using agile practices for some time already I would not suggest this book to you. However, if you are in the middle of, or trying to refine the practices you are already using, this is a thorough book that goes into the right amount of depth.

photo credit: victoriapeckham

We have reached the most critical point on a project I’m working on. After a few months we think we know enough about the domain and application to build a product road map that will take us to the first public release. The proof of concept is complete. The design team has created a remarkable, genera changing product. Additionally, the system is designed around real users we have been able to talk to and get feedback from. We have put together an unbelievably good development team and built a backlog of stories with estimates. We have been here before. Putting together a design and backlog of stories is something we have done countless times…

The easy part is over. Now the hard part begins.

Our research and user feedback tells us we have multiple potential customer groups we can build the system for. On one hand this is great news. We have a number of potential markets to choose from. On the other, we don’t have an infinite amount of time and money to build it for all of these groups. We have to commit and go all in with one group. Right now, these are just some of the questions we are asking ourselves now:

• What customer group do we value the most?
• What features do they value the most?
• How expensive is it to build the ultimate product for each group?
• What is the minimum viable product we can build for each group?
• Which group is most likely to give feedback and partner with us to help refine our product?
• How much feedback is this group likely to give you?
• Are we missing some market window by passing on one group v.s. another?

This is a critical point in the product’s design. Whichever user group we choose will be our customers. Or another way of saying it: They will be our ONLY customers. Other customer groups aren’t likely to be interested because we aren’t building any features for them yet.

When designing a product do you consider what customer groups you are including and excluding? Are you going to be happy with that choice for the foreseeable future?