Advice for Developers and Designers Working Together

From my talk at the University of Chicago Booth School of Business:

Excellent advice on getting developers, designers and managers to work together. It's featured here in our [UrbanBound's] latest blog! hub.am/XeZ6hq

Customer Development for "Product You"

As a manager I've always found it hard to get honest feedback from employees and my management. In larger companies the feedback culture in management often boils down to: positive feedback leads to good reviews - which leads to expectations of paying higher bonus. Employees will give their managers good reviews even in anonymous 360 reviews.

The solution

LinkedIn's endorsement feature can a be used to get good feedback from people. It will tell you directly what you're bad, but it will tell you which are good at.

Here is how it works 

 

If you want to know if people generally think you are good at something
Look at how many people endorse you for that skill.  If you have lots of endorsements for other skills, but none for the the skill you are watching. Guess what? People are telling you you don't have it.

If you have a skill that you don't use often but you're wondering if you're any good at it
Make sure its on your profile. If you get a number of endorsements, people think you have that skill.
Maybe its time to hone that skill to perfection?

If you don't know if you have a skill, but want to test if you do
Go ahead and throw it up on your profile. People can always ignore it. If you get some endorsements there is some potential there. Maybe its time to start training.


I have almost 700 people in my network on LinkedIn. I'm getting a good sense of what people know me for. I also see where I need to do some personal marketing in order to let the world know I have a skill. The good news is that I am not surprised by what I'm being endorsed for.

Note: There are a few more steps you will want to do in order to fully run customer development on yourself. Customer development is not a term a coined. I discovered it via Steve Blank in his book The Four Steps to the Epiphany. I highly recommend you check it out.

What Is A Product Showcase?

I couldn't find a simple description of a product showcase today so I wrote a quick one myself

The showcase is an important part of product development. In it the product development team shows newly developed features to the company's stakeholders before releasing them to customers. It promotes early feedback (before the cost of change is too high), facilitates communication between roles in organizations and ensures the correct product is being built.

An update to principled leadership

Photo credit: raphaelchekroun

One my most popular posts of all time is one I put up in 2009 about Principled Leadership. I still get traffic from this post and once got a very aggressive job solicitation based on the principals outlined in the post. Recently I came across a quote that nearly sums up the whole list in one sentence:

Smart leaders understand it’s not just enough to pursue, but pursuit must be intentional, focused, consistent, aggressive, and unyielding.

*I'm afraid I don't know exactly where this came from so, if you are the owner, please let me know so I can link back to you.

Shallow Copy in Ruby

I often wonder why some organizations only consider candidates who have computer science or computer engineering degrees. In the real world I have seen many great developers who have come from diverse backgrounds. However, I had an event recently that made me really happy I have a degree in computer engineering. It made me understand why the favoritism exists for computer science credentialed developers. I had an issue with an email template in Ruby on Rails that without a good mental model of compilers and, specifically, compiler optimization would likely have taken a long time to identify and fix. Here is what happened:

in a database somewhere...

UPDATE app_configs SET affiliate_template = 'Welcome to UrbanBound #[FirstName], '

def send_email_to_todays_movers

  Mover.each do |m| 
    @boiler_plate_email = AppConfig.find_by_config_name('affiliate_template').value
    [business logic goes here] 
    prep_mover m, @boiler_plate_email
  end 
end

def prep_mover
   [business logic goes here]
   @movers_name = Mover.find_by_id(m.id)
   send_welcome_email @movers_name, @boiler_plate_email
end

def send_welcome_email (first_name, boiler_plate)
   boiler_plate['#[FirstName]'] = first_name
   ......
end

*If this is good code architecture or not I'll leave for another post. We do most initial development of features as an MVP at UrbanBound. Its usually not worth optimizing code the first time we are testing a feature out. That being said I have a strict rule of using TDD and keeping 95% code coverage on models, helpers and controllers. Generally speaking, no business logic is allowed in the views.


The first time I ran this code (via rspec - I'm not this guy) the outgoing email message had the correct first name for the first mover. However, the others all had the same first name as mover #1. It didn't make sense to me at all. The boilerplate email template was changed in the send_welcome_email method but we refreshed it each time a mover was processed. Then I thought about my days doing C/C++ and how compilers work. Maybe the Ruby interpreter couldn't see three levels deep into the execution tree to see the boilerplate was updated. Perhaps it just did a shallow copy of the boilerplate after the first execution and was effectively sending a memory location of the boilerplate. Never updating it after the initial read from the database. After some experimentation I found that I was indeed correct. The compiler was performing an optimization that made the code faster, but didn't produce the intended action the programmer gave it. This is the trade off compiler builders always make.  Back in graduate school I could get my compiler to generate code that ran 2x-3x faster than the benchmark compilers, however after running millions of test data sets against it I noticed errors in 1 or 2 of them. This may be fine if I was playing in media, such as an mp3, but not good for computations that affected people's life and safety.

It turns out the solution is simple. Explicitly tell Ruby that you want a copy. Here is the code:

  Mover.each do |m| 

    @boiler_plate_email = AppConfig.find_by_config_name('affiliate_template').value.dup

    [business logic goes here]

    prep_mover m, @boiler_plate_email

  end

I found another great description of the problem [here]

From the maker's perspective...

I came across this article via LinkedIn. It reminds me of the Maker Schedule, Manager Schedule discussion except its from a maker perspective. Given that I have been doing a significant amount of development in Ruby on Rails for UrbanBound for the past 3 months, I'm following a maker's schedule again. Being my own boss makes things simpler, however I think its important for makers to understand how to be productive and articulate to their management how they can be best managed.


If this seems a bit counter intuitive to you. I can tell you that good managers do know how to manage. However, given all of the pressures around managing a business, its easy to fall into the trap of thinking about management objectives over the needs of the people who getting the work done.

A healthy reminder:


7 Things Highly Productive People Do

Call It Like It Is - Save Time and Money by Filtering Out Non-Users in Your Application's Design

At UrbanBound we are  necessarily obsessed with who our users are - and who they aren't. An application designed for baby boomers utilizes very different design principals than one designed for a younger audience. If we try to design for everybody (the lowest common denominator) we just aren't going to be compelling enough to anybody. We keep a visual reminder posted of who we are, and who we deliberately aren't, build for. This way we don't waste time and limited resources on people who aren't likely to work with us.

Why I hate the Internet sometimes

 Watch my site get slow. Watch me download the logs to make sure nothing happened. Thanks for wasting my time script kiddies.

Why car companies need to do usability testing

Overall I love my Toyota Prius. Under the hood, it is an engineering marvel. Prius' have been around for 10 years and still sell like hotcakes.  I honestly don't understand why Ford hasn't made a competing product by now.

I have come to realize that I pay attention to design more than the average person. I hate it when simple design mistakes ruin an overall well designed product. The interior of my Prius has some obvious problems that could have easily been fixed had they asked the right questions.


Separation of Concerns
Is there any reason they needed to put the door lock/unlock button between the buttons that operate the windows?

 

The buttons feel different - therefore its not likely that I'm going to press the wrong button. However, nearly every time I want to use one one of the buttons I have to take my eyes off the road and look at the buttons to choose the correct one or I have to feel each one to get the correct one. This simply violates the principal that you shouldn't make your users think necessarily.

Positive Actions vs Negative Actions

-and-

Direct Users To The Most Common Action

To me, Toyota completely confuses button shape and action. Its been nearly 8 months and I still have to stop and think about which is the correct button. I occasionally make the wrong choice and send a caller to voicemail rather than picking up the phone. Take a look at the phone answer and hangup buttons:

The button to hang up the phone (the top one) is raised. I consider this the negative action. The button to answer the phone (bottom) is sunken in. This bothers me for two reasons:

#1 If I'm driving and the phone rings I'm being interrupted.  Thus, I'm not 100% focused on the phone yet. The easiest button to find is the raised button. This should be the button I hit to answer, but Toyota made this the hangup button. Maddening.

#2 When I'm ending a call the sunken button makes sense. No matter what mnemonic I go through the raised button doesn't work for ending a call/conversation.

Because I'm thinking about what the right button should be I sometimes make the wrong choice because I'm thinking too hard about doing the opposite of what comes naturally.

*Note: They make all Toyota Prius' for the whole world in Japan. The above concerns might be personal issue or an issue of how British/Americans view the world. I don't know if Toyota makes all of their cars the exact same for all geographies either. 

Looking Back at My Most Popular Posts

Anybody who has worked with me knows that I'm a fan of analytics. If you are selling soap or software development services, I strongly believe you should be capturing metrics on how people use and interact with your product. As such, I have Google Analytics on my blog. I have learned quite a few things about my content over the past few years.

#1 Short blog posts are the most popular.

#2 However, the longer multi-part ones engage users more

#3 Good content draws people in. Of the people who stay on my blog for more than 10 minutes - which is a long time in the web -, half come in through the top 5 posts.

The top 5 posts are:
Boarding Pass - You're doing it wrong
How to Interview and Hire a Good Project Manager
Effective vs Efficient Teams
Principled Leadership
Maker's Schedule, Manager's Schedule

...not in the top 5, but one of my favorite posts...
Systematic Amateurism

Patterns of traffic

Usage:

• 10% of traffic comes to the site and reads the blog in depth. They stay for 600 or more seconds. These people are truly finding the value in the content. I'm pretty happy this is so high.
• 30% of traffic reads the very short posts and sometimes shares them with other people via twitter or email.
• The other 60% of visitors bounce out immediately. This is actually pretty low compared to what I have seem on other sites.

Traffic Sources (non-bounced i.e. the other 40% of visitors):

• 20% of traffic comes from searching Google for my name. I assume these are people whom I have met at meetups or have heard about me. If this was higher I would be a bit disappointed. I want people to come to the blog in order to get valuable content. For me, its not only about personal marketing. 
• 75% of the traffic comes from people looking for a specifics topics. For example, "Lean Software Development Techniques"
• 5% of traffic has no disernable pattern. For example, "dominator influencer supporter critical cd"
  

Conclusion

• No more book reviews. They are time consuming for me to write, have a very high bounce rate and get very little traffic
• Most of the medium sized blog posts (4-8 paragraphs) are not valuable to people. This tells me I need to put a quick post together or cover a topic in depth. This is good news as well. I find quick posts enjoyable and the longer ones I really dig into and think about for quite some time which is also enjoyable.

Jakob Nielsen's Kindle Fire Usability Findings

I don't like to re-post, but I highly recommend reading this. Tablets are, finally, not going to go away and will only increase in usage.

Jakob Nielsen does a great job of discussing the usability and design of 7-inch tablets. Then he talks about the future of 7-inch tablets based on the market and design choices required to ensure their future.

http://www.useit.com/alertbox/kindle-fire-usability.html

Review: Individuals and Interactions an agile guide

In Individuals and Interactions an agile guide, Ken Howard and Barry Rogers give us a set of tools for managing individuals on agile projects. They acknowledge that "There have been countless books on the subject of human behavior and communication. Psychologists, sociologists, organizational behavior experts, and others have conducted studies, published journal articles, taught courses, and granted degrees in this subject area." Since the philosophical science has been covered in detail by many many others, this book focuses on specific tools you can use for individuals and interactions on agile software projects. It jumps right into actionable techniques without much exposition. It assumes you are fully in agreement with running projects utilizing agile project management practices. Fair warning: The book might feel quite one sided for some if you come from a heavy command and control background or don't agree with agile principals. You might get a bit frustrated.

In the first few pages the book discusses what a group of people behaving as a team looks like. How a "team" of individuals working alone isn't as good as a team working together.  How productivity increases once a team stops focusing on process, but on results. Next the book brings up the concept of the DISC behavior model. I really liked the quick explanation of DISC as "a behavioral fingerprint." For those unfamiliar with DISC it segments people into 4 categories: D—Dominator, I—Influencer, S—Supporter, and C—Critical Thinker. I generally hate to label people, but I find myself using DISC often when thinking about how to work with people professionally and personally. Its a useful tool.

After a detailed section on team dynamics the book moves to communication. Agile projects can succeed or fail based on the quality of communication of the team. I found a section about body language particularly interesting. Surprisingly, body language has never been included in any manager training I have been through. On Agile teams a project manager pays a lot of attention to the nuances of how people talk and work together. Body language tells a lot about the conversation. Its big tool to fail to have it in your tool box. I'm not a particularly empathetic person, but I notice a lot when it comes to my teams. The reason is that I read a book about body language when I first got in the workplace and feel that I have been at an advantage ever since. Finally, the book moves on to the highest form of speech: collaborative interaction. Its probably a blog post in itself so I suggest you learn more about it from reading the book.

Next in the book is a section about people's motivators. It goes into more detail than the simple adage: Some people follow a craft for the money, others make money to follow a craft. The book ends with a focus on people's strengths. My experience is that many people look to change and "improve" individuals vs directing them toward what they are good at and will enjoy.

The final part of the book is filled with a few workshops that are useful for those who want to facilitate a group into cohesion. I worry that they might be hard to get through in a very staunch environment. Of course, I haven't seen too many staunch organizations successfully do Agile anyway. Your milage my vary.

The final part of the book has a personal DISC test you can take. This is useful because, in my 5 minutes of research on Google, I couldn't find a free one on the web. Again your mileage my vary.

Overall I think this a great book for those who are doing agile, but only have a perfunctory understanding the mechanical processes. This book will round out your understanding and have to understand the why of it. If you have been successfully using agile principals and practices for a number of years, you are likely to find something useful in this book too.

Its short, pick it up. You won't be disappointed.

Review: Leading Lean Software Development

I am reviewing books I have read in the past for an upcoming coaching gig. I realized I hadn't posted this review on my blog yet! This is from over a year ago, but its still relevant as I work with more and more customers who are now becoming interested in Lean software development. This is still one of the better "agile" books I have read in the past couple of years. Here is my review:

In Leading Lean Software Development, Mary and Tom Poppendieck present a handbook for how to run a software development group, top to bottom. I intended for this to be a simple review of concepts known to me for years, but the book offered much more. The book’s jacket describes it better than I can: They “show software leaders and team members exactly how to drive high-value change throughout a software organization—and make it stick.”  If you are completely new to agile and lean you the book might move a little fast for you.  If this is the case, I suggest you spend some quick time getting agile and lean 101 elsewhere first.

If you walk away with one concept after reading this book it should be to believe that success comes from people. The best companies focus on developing problem solving skills and local decision making. These companies favor adaptability over efficiency.  These companies make money to survive rather than simply surviving to make money.

The book starts out by defining the concept of frames, “the unspoken mental constructs that shape our perspectives and control our behavior in ways we rarely notice.”  A useful way to look at software development. I was happy to see their description of Agile as evolutionary rather than revolutionary. This is why when you explain the set of Agile practices to those with extensive experience they usually nod their heads and say they are already doing them. I have been telling people that Agile is a collection of best practices that good software shops have been using for years. Now I have a reference to support this.

Software craftsmen should read chapter 2 about technical excellence. The chapter goes through each engineering practices, explains it such that a non-practitioner can understand and gives examples. After they are done they should make their manager’s read it, then their managers.

Conclusion

I wish this book had been written 5 years ago. It would have saved me considerable effort and time trying to define what a well run software organization looks like. Your mileage my vary, but I will say that I intend to keep this on my bookshelf right next to Managing The Professional Service Firm.

Six Reasons Why EA Should NOT be Assigned to the IT Department

I have always disliked working with the "big architecture" people. It was only in the last 5 years that I came to realize why.  Enterprise Architects are often software developers who have reached the pinacle of programming greatness. They can solve massive problems and are truly amazing software developers. However, they often lack business accumen. As such, their solutions don't consider the most important part of the solution - the business' goals:


EA is short for Enterprise Architecture:

1. EA ≠ IT Architecture
2. True EA leads to redistribution of authority, which is beyond CIO jurisdiction.
3. EA value proposition (i.e. standardization vs. innovation) is solely business realizable.
4. The primary goal of EA is to build coherent enterprises, not better IT systems.
5. Synthesis takes precedence over analysis.
6. EA failure is an organization failure, not an IT failure.

I came across this post on LinkedIn and felt I needed to share. It was posted by a person named Pallab S who is an Evangelist [Enterprise Architecture Practice] at National University of Singapore | Institute of Systems Science.

Agile In Regulated Software - Partnering

This may be generic advice, but it might not be a familiar concept for those in IT working within a large organization doing validated software:

Photo By: JD Hancock

Once you adopt the practices described in my previous blogs about regulated software, you will find that you aren’t working alone anymore. The tight feedback cycles allow you to regularly check-in with the business and involve them in building the software. Once this happens, priorities and features will change. Early on they will change often. Don’t discourage this as its a good sign things are moving in the right direction. The people talking to your customers are directly involved in building features your customers will use. This is exactly what you want because it be likely that you will produce a better product now. Now that you have left your IT bubble you must partner with your stakeholders rather than simply delivering to them on a regular basis. How do you effectively partner with the business and marketing? Here are the difficulties you will likely face:

• Goals are different
• The phases and corporate dialect are different
• Time frames of when decisions are made is different
• Required documentation will be different and address different goals
• Stakeholders will feel comfortable giving verbal requirements, but you must to document them, get them formally approved and finally build them into working software

How do you partner with the business and still meet your commitments? Follow the practices I presented earlier and stick to the following principals:

• Consistent focus on activities that add business value
• Build trusted partnerships
• Constant customer engagement
• Continual process and practice improvement
• Be collaborative and transparent
• Work together: No heroes, lone wolves, or cowboys
• Pay attention to the team and adapt as needed

Agile in Regulated Software - Sweat the Details

Very few people in the software development community have issues with maintaining good attention to the details. However, I bet those who live in the regulated software community view the “normal” software world as quite sloppy. Attention to detail is a matter of life and death for a medical device. Because of this, the entire software community does a good job maintaining checks and balances. I have three suggestions that will make a tremendous difference when you start a regulated project or when you finally get near to releasing your medical device.

Photo by: myguerrilla

#1 Plan to get audited

It is a good bet you are going to get audited sooner or later. Its even possible to get a product out into the market only to have it get audited a second time. An FDA auditor will keep asking “why do you think that works?” type questions and continue to drill down until they find something or are satisfied there is nothing to find. If they find something you are going to get a warning letter and start the expensive process of FDA remediation. Getting past this will cost you a significant amount of resources and likely delay new product development. Usually just in time for your competitors to catch up. Keep good records.

#2 Do Test Driven Development (TDD) Well

By well I mean do all of the normal activities that are part of TDD … and do one more thing. Create self documenting code that also lends itself to traceability directly back to product requirements. Imagine telling an auditor that you can prove that you tested every path of the code EVERY time you checked your code in…thousands of times.  All of these tests can be directly linked back to product requirements. That would make an audit pretty easy.

#3 Create a Traceability Matrix

This may seem obvious. However, I know of many, successful, software shops that have stopped doing this. Ask a developer with 1-2 years of experience why they would need a traceability matrix and you will know what I mean. If you are planing to get audited and want to show that all of your requirements have been tested thousands of times, you need a traceability matrix.

Next up: Partnering

Agile in Regulated Software - Its not what you wear. Its how you wear it.

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 seemly 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.

Next up: Sweat the details

Agile in Regulated Software - Functional Testing vs Technical Testing

Testing is a crucial part of all software development. If you don't believe this you are likely just starting your career or haven't had to support an application in production with users.  It becomes doubly important in a regulated environment. This is because testing for regulated software serves multiple purposes. There is the usual software product development reasons to consider (i.e. professional integrity and no one wants a bug in production). But it is also because the FDA, in particular, wants to make sure you are performing validation and verification of the software. Verification (Was the product built right?) Validation (Was the right product built?)

While I acknowledge there are a number of useful and important ways to describe software testing techniques, I strive to keep things simple, and understandable, by the whole team. To that end, I split testing into two tracts: Functional and Technical.Functional is about bring business value to the stakeholders - the validation part. On an Agile project we are testing the acceptance criteria of each story. This validates we have realized the benefit to the business and end users. If some thing cannot be tested by an end user, it doesn't exist or have significant value. This is of course untrue. However, to simplify things and keep the team laser focused on only working on tasks that provide business benefit I start with this ideal. All other testing activities are testing Technical requirements. Or, verifying that the software is correct. Some examples of these technical requirements are things like performance criteria, common libraries to the backend and data retention rules. Those who do testing for a living are looking at the screen sideways by now I suspect. I realize that these things must be done correctly or the system will not realize business value to an end user. Both ate needed. That's why the FDA requires proof of verification and validation.

The common flow of testing in an Agile project is to create acceptance criteria for each story then do regression testing after each iteration:

On the other hand, tradition testing documents and verifies each step before it is performed. The goal is for planning to be exhaustive and cover all possible scenarios.

Traditional testing is expensive and often makes validation hard to do. On the other hand, the common Agile testing approach is going to make documenting verification activities difficult. Once you acknowledge both are needed you can find a way that works. The best tools we've found leverage and extend the automated testing you are already doing. Look at the software testing as having two "tracks".
#1 Manual Functional Testing of acceptance criteria. All of the speed and simplicity of user stories. An efficient communication mechanism for stakeholders.
#2 Test everything else via automated tools. Ensures all gets tested. In our case we use unit testing and 100% code coverage.
Here is a graphic of how we can document that we are testing against pre-approved requirements - both functional (validation) and technical (verification).

Next up: Its not what you wear. Its how you wear it.

Agile in Regulated Software - Checklists

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

Agile in Regulated Software - Have Some Class

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